cljs-dev 2026-08-06

While trying to help someone in #C053AK3F9 I noticed that the quick start example is incredibly slow to compile and every step report an OOM if the command line has both --compile and --repl. The stack trace is about printing a deeply nested collection. Debugging landed me on https://github.com/clojure/clojurescript/blob/10fdfa2f3631009d538eb143439f62657df3ea71/src/main/clojure/cljs/closure.clj#L3128. Speculating: maybe due to :compiler-env, which is a huge atom. But no clue why it works just fine without --repl.

Interesting, I've done that before since it's in the Quick Start, I don't recall serious memory problems before?

So you're altering the Quick Start by adding --repl to each command?

The user whom I was trying to help is also seeing the same issue: https://clojurians.slack.com/archives/C03S1L9DN/p1785993307864569 Yes, the full command is clj -M --main cljs.main --watch src --port 9999 --compile hello-world.core --repl.

I remember hitting this exact thing last year too. I tried to make a minimal repro using the cljs compiler api instead of the CLI but couldn't figure it out and forgot about it until now

So, for other clojurestar dialects, I just put out https://github.com/johnmn3/clinj It's like WINE, but "Clinj Is Not Java" - in the sense that clinj provides a shim layer for cljc->java->cljc, allowing you to source-transform clojure-clj into clojure-star compatible cljc. Currently, clinj also targets CLJS. But a lot of clojure-star dialects will probably end up internalizing the clinj spec internally. Then, the clinj-as-a-lib will mostly be useful as a tool for cljs, outside of being the reference impl for other dialects to vendor in. So, right now, clinj will allow you to run the tools.deps family of utils, from their original source, on node using cljc on cljs. Anyway, that's all well and fine... But, one day, CLJS could choose to internalize some clinj standard too, such that it could consume clj files too, like the tools.deps stuff, without source code tranformation. That sounds super complicated and I'm not ready to submit any formal proposals on the idea in the near term. But the whole idea does open up some new opportunities CLJS and friends, to normalize more of the clojure source ecosystem under common interfaces. Something to chew on.

hmmm... mapping clinj/jdk to the goog closure sdk, so as to attempt to maximally build out the JDK shim for CLJS over goog... might be interesting, hmm