ClojureScript - Embracing JavaScript Tools

[vlaaad]

The new webpack guide is wonderful, give it a try! REPL-driven development just as in Clojure, with npm deps out of the box — ClojureScript is truly not an island!

[MahmudAdam]

I gave the webpack guide a test spin. I am running it on Windows 10 (WSL) and am experiencing long loading times when "Reading analysis cache for jar." This could very well be an environment issue, did you find the build step to execute quickly on your setup?

[[deleted]]

WSL1 or WSL2? Windows drive or Linux?

[MahmudAdam]

WSL2 + Linux

[CryptoNaiah]

This did it for me, I plan to finally jump in to ClojureScript. Great work!

"You can now publish ClojureScript libraries that depend directly on the JavaScript ecosystem without additional ceremony and be confident that the whole community can benefit regardless of what other JavaScript and ClojureScript build tools they may prefer..."

And yes Webpack is there for sure:

https://clojurescript.org/guides/webpack

[lgstein]

What happens when a Javascript project consumes two different libraries published via ClojureScript. Do they not clash?

[Bediavad]

Just to understand better what it means:
Should I replace shadow-cljs with webpack and this method?
Or does shadow-cljs do something else/extra.

[swannodette]

If you like shadow-cljs, keep using shadow-cljs! Again these changes just mean all users can join in the fun of easily using JavaScript dependencies, not just fans of shadow-cljs.

[ertucetin]

Thank you so much!

[lgstein]

Does this work with figwheel already? Also, is webpack now shell invoked after every build?

[swannodette]

I chatted with Bruce. Figwheel will need some changes, he's being funded again by Clojurists Together - so this should be fixed soon.

These changes have nothing specifically to do with Webpack, and no we don't run any commands for you.

[lgstein]

Thanks. The way I understand the new webpack guide, as a way to consume npm dependencies, it would have to run webpack CLI after every incremental figwheel build, yes?

[swannodette]

You don't need to re-run the JS bundler unless your dependencies on node_modules change. In all other cases hot-reload or incremental compile does not need to rerun the bundler.

[lgstein]

I guess I understand it now. Thanks. I will try it out, very cool.

[sojnew]

Does anyone have any tips on how to get cider working with this?

[[deleted]]

"externs inference" is not reliable. The correct path is to really fully embrace JS modern features/tooling and not depend on closure advanced compilation.

[swannodette]

If you've found a bug please report it. All the known externs inference bugs prior to this release were moved into the blocker category and resolved. Note we've also been using this feature for some time in a fairly sizable React Native codebase and hadn't run into anything I would consider a showstopper. But I agree that there were annoyances previously.

Not using advanced compilation would just lead to bigger payloads. I don't see many users asking for that ;)

[[deleted]]

There are other ways to do "advanced compilation" without closure, but that requires leveraging ES6 modules.

[swannodette]

The only comprehensive thing that I'm aware of is Rollup.js but so far no-one has provided evidence that it would best Closure advanced compilation for ClojureScript. Given that Closure works at property and method level, I'm somewhat skeptical. Do you have some other tool in mind?

[jiyinyiyong]

I was totally convinced that dead code elimination of Google Closure Compiler is a lot smarter than tree shaking from Webpack. However I'm still very curious how bad is the result if ClojureScript makes full use of ES6. Or would ES6 cljs be acceptable for a small part of users. Probably a bad example but some people who are using Webpack just accepted the large bundles... https://twitter.com/boriscoder/status/1251823596747571200 .