Cljc.java-time will drop all npm/foreign-lib dependencies

Hello, this is a heads up that I am planning to drop the npm/foreign-lib dependencies (npm library ‘js-joda’ & related) from https://github.com/henryw374/cljc.java-time and would like to hear any feedback anyone has at this point.

Doing this should mean that other Clojure(Script) libraries which make any use of dates and times could now depend on cljc.java-time library because:

  1. There will be no transitive dependency headaches for users (ie excluding foreign-libs if you have a :bundle cljs build etc)
  2. End users will benefit from dead code elimination: If they are not using part of a library that uses cljc.java-time, then nothing of cljc.java-time library will be included in an advanced optimization cljs build.

IOW, cljc libraries that need to use dates (even if dates are not the main focus of that library) can depend on cljc.java-time and get a banana without a gorilla holding on to it.

… and being cross-platform and using java.time on the jvm, I hope cljc.java-time could become the de-facto platform time library for Clojure and Clojurescript.

Of course https://github.com/juxt/tick and any other end-user-focused date-time libraries that depend on cljc.java-time will benefit

How will this work?

I am creating a custom build of the js-joda source that results in a single js file that does a goog.provide() - ie something cljs compiler treats as native.

In order for the jsjoda addon libs (timezone & locales) to work they will also need custom builds.

I am assuming here that no one is using any js libraries that are using jsjoda - but if you are please shout. If people are then I could provide an option to use cljc.java-time with npm dependency instead.

The downside for me is that each release of jsjoda that people want will need a new release of this custom build. However, since jsjoda just replicates java.time and that is stable, I don’t expect that many releases.

There is a new platform library for JS in the works, ‘proposal-temporal’, but I decided it is best to focus on the custom-jsjoda approach for now since:

  1. it may be years before proposal temporal is fully ready
  2. jsjoda lib is still openly considering deferring to proposal-temporal method/objects when it is ready - ie jsjoda does the mapping to java.time so cljc.java-time doesn’t have to

I am not sure how long until the new version of cljc.java-time will be ready, but weeks rather than months hopefully.

FYI I have gratefully received some funding from Clojurists Together for this work.

Why is the library called java-time ? Perhaps simply cljc.time is better right ?

it’s called that because it has the same api as java.time, just with namespaces instead of classes and functions instead of methods

I just wanted to pull this out and say it made me laugh out loud (and my wife also thought it was a pretty funny image!). Thank you for brightening up my Friday!

As for the changes, they sound good. We are still using clojure.java-time at work but I have been considering switching to cljc.java-time since it is closer to plain ol’ interop in structure and we already use direct interop with Java Time in a lot of places so it would be less jarring to use (than clojure.java-time).

1 Like