Draft: Partial deprecation of Cljsjs

[Deraen]

Drafting a notice for "partial" deprecation of Cljsjs:

I'm thinking Cljsjs is starting to get mostly unnecessary now, with better options for consuming JS modules available.

TLDR

The most common packages like React will continue to be maintained in Cljsjs. But there are better alternatives for using JS libraries.

Why does Cljsjs exist

• To allow easy use of JS libraries from Cljs -> No longer needed
• To ensure there is only single copy of the JS library in classpath -> Still relevant, in some cases

Why isn't Cljsjs perfect

• Centralized repository needs maintainers to review and merge PRs
• Outdated tooling, open issues with tooling

Better solutions

Using a JS library from a application project

Use shadow-cljs or ClojureScript with Webpack to directly consume npm packages. You always get access to up-to-date versions.

Using a random JS library from a Cljs library

Depending on your library, you could just require that the consumers of your library use shadow-cljs or webpack to provide requires JS libraries. If you need to ensure users can use the library with foreign-libraries, you could package the JS library yourself as a JAR, same as what cljsjs does, but you can do this yourself using Leiningen or clj.

Compared to Cljsjs, you need to create a bit of tooling yourself, but you are free to update the JS library yourself.

Using a common JS library from a Cljs library

If the JS library you are using is likely to be used by multiple Cljs libraries, using Cljsjs is useful as this ensures only one copy of the JS library is included in the build.

E.g. If multiple Cljs libraries used their own React JAR packages, multiple copies of React would get loaded.

[Folcon]

I'd like to pipe up and say that at least from my perspective the below statement is not always true =)...

• To allow easy use of JS libraries from Cljs -> No longer needed

From my perspective the process of adding even one npm lib to a project can be incredibly hit and miss and I try to set aside at least a few days to ensure that it's working. Thankfully once it's running then it's usually possible to just leave it be.

Contrast that with any clojure/script lib which is basically copy deps, read the docs to work out how to use it...

This may be a minority opinion, but I don't believe that requiring all cljs devs to also maintain a detailed understanding in every javascript tool that's the new way to make things run in order to use npm libs is a great thing?

cljsjs at the very least provides a fairly consistent level of approachability to npm libraries. Sure they may be a tad out of date, but that can be tackled.

With regards to my build process, I'm using figwheel / webpack. So perhaps things are much better on the shadow-cljs side of things?

[yesudeep]

cljsjs works wonderfully with Bazel by default. I'm not sure this would be a good idea. npm can be unreliable. things break randomly.

Here's an example using Bazel: https://github.com/yesudeep/rules_clojure/blob/clojurescript-support/examples/setup/default/BUILD.bazel#L28

[Deraen]

Deprecation notice has been added to the readme: https://github.com/cljsjs/packages/commit/aa849fb6123faae80af77783b5ac74f0efd93a14