David Nolen is asking for adventurous minded volunteers to help test drive a new way of integrating ClojureScript with various JS bundlers:
these changes are beneficial regardless of whether you use ClojureScript, Figwheel, Shadow etc.
It means you can publish ClojureScript libraries that depend on NPM, i.e idiomatic wrappers for cool libs / ui components etc.
It’s also a path to migrate off CLJSJS which requires a lot of manual effort from the community to mirror popular packages
Just tried it out. I was getting Uncaught SyntaxError: Cannot use import statement outside a module.
I checked out/index.js and out/main.js and they were identical. So I knew something screwy on my end with webpack. I tried on another machine for a sanity check and it worked. Same webpack version according to lock files. Checked node version and the machine where it didn’t work and it iss running Node v10 (10.16.0). On the machine where it did work, it is running node v12 (12.13.1).
Cleaning out the out folder, changing node to v13 (13.9.0) and running the steps again – it works. Not sure if there is a minimum node version requirement or if it’s entirely the machine’s environment but thought this might be useful.
I’m running Node 10.16.0 and I wrote the guide using that. So something is wrong but I don’t think it’s Node version related.
You’re right. I ended up blowing away my node installation, reinstalling and redoing the steps with v10.16.0 on the machine that had the error and it worked. Sigh, sorry about that.
While I think it’s quite a nice feature, is it another(but official) implementation for :target :npm-module from shadow-cljs? And what are the differences BTW?
Can’t really compare the two since they have different goals.
:npm-module is about integrating CLJS into an existing JS project while allowing to keep the JS toolchain as-is.
The new CLJS bundle support is just about getting npm dependencies into CLJS builds, so it is a simplified version of what shadow-cljs provides built upon existing JS tools like webpack.I wrote about why shadow-cljs doesn’t do that but it is nonetheless useful to have over regular CLJSJS.
Making it easy to use node_modules is really only one part of the goal. Clearly this has become a problem for users - it’s nice that tools like shadow-cljs address this, but the last yearly Clojure survey shows that having something in ClojureScript itself is important.
The other part which is just as significant is that you can now publish libraries that depend on node_modules instead of CLJSJS and expect that anybody can get your dependency and build it - regardless of which build tool they prefer - cljsbuild, Figwheel, shadow-cljs or just ClojureScript. In some sense this also about ease of use, but at the ecosystem level rather than an application one.
Thanks for this, I believe both of these goals will have a large impact. As a library author, it was not easy figuring out how to publish with a dependency on node_modules, I ended up just copying the approach of other similar libs hoping it would work.
But if I understand this correctly, this introduces a bit of a breaking change. Libraries published with this config will require the latest CLJS compiler. If we don’t make sure to handle this, errors in apps might be subtle and hard to understand.
It’s not a breaking change, it’s a new feature. That means libraries declare a dependency on a specific ClojureScript version as with all new features. No special handling is required - most users are using some dependency tool.
Oh. I thought that:
Just writing this to clarify why I said what I said. I’m assuming I’m wrong on one or both of those points.
This still not a breaking change. This is just a dependency conflict and your dependency tool can help with that.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.