cljs-dev

thheller 2025-02-07T08:44:29.044519Z

so slight dilemma. google finally added support for parsing JS https://github.com/google/closure-compiler/commit/0b7b37466847f8ea6615533539a68a58227f1563 which has been a major problem and accounts for like 90% of all recently reported shadow-cljs issues (see https://github.com/google/closure-compiler/issues/2731). all this isn't released yet, but I'd be eager to switch to the new release whenever that comes to finally fix all the issues. the problem is that google also moved the closure compiler to java21 minimum. any thoughts on that? maybe fork the whole thing and revert it back down to 11? just make 21 the new minimum required version for CLJS?

๐Ÿ™Œ 1
hadils 2025-02-19T01:03:47.514129Z

21+๐Ÿ’ฏ

mkvlr 2025-02-07T08:51:40.845749Z

Iโ€™d be fine with a 21 minimum. How much work would a fork be?

thheller 2025-02-07T08:57:08.593789Z

the main issue would be figuring out their whole bazel build related stuff. code wise so far I have only seen one trivial change that would be easily undone. long term this would likely become unsustainable though, but could maybe be done for the next release.

mkvlr 2025-02-07T09:09:16.253069Z

maybe Iโ€™d try with bumping to 21 and see how many complaints you get. Then you can still consider a fork later?

thheller 2025-02-07T09:13:59.882769Z

yeah probably. probably won't be any more painful than 8 -> 11 was. most people were fine, some quit ๐Ÿ˜›

mkvlr 2025-02-07T09:17:44.131599Z

right, Iโ€™d support a push towards 21 and maybe core asyncโ€™s upcoming virtual threads support will also help with it

thheller 2025-02-07T09:18:20.692789Z

yeah 21 baseline would be great I guess. many other things I'd move to vthreads in shadow ๐Ÿ˜›

mkvlr 2025-02-07T09:18:35.577039Z

and maintaining a closure fork sounds like a ton of work thatโ€™s not very fun

thheller 2025-02-07T09:19:51.123109Z

yeah, although I've been thinking about it for a while and ripping out all the useless stuff we don't use anyways ๐Ÿ˜› and of course adding some missing stuff or making inaccessible stuff accessible ๐Ÿ˜›

thheller 2025-02-07T09:21:14.558419Z

but them fixing the private stuff is a major win ๐Ÿ™‚

Roman Liutikov 2025-02-07T09:59:04.050459Z

+1 on going forward with 21 The fact that the cause is a one liner stringbuilder change is annoying though

borkdude 2025-02-07T11:51:29.619849Z

21+ ๐Ÿ‘

souenzzo 2025-02-07T16:06:04.501699Z

Note: shadow-cljs isn't required for "production" machines In my company, prod still runs 17 (and we don't control it. It is another team) But the CI/CD can run 21 for cljs builds. So it is not a blocker

2025-02-07T21:47:38.407759Z

I had to do the annoying setup in builds for shadow to use 11+ while other JVM build step stuff (for CLJ) used 8 already. So it was doable at least. 21 wouldnโ€™t be any harder there.

dnolen 2025-02-07T11:45:12.351109Z

I think min. 21 is ok - it's annoying but based on the 2024 Clojure survey results, it's also not completely unreasonable.

๐Ÿ‘ 9
borkdude 2025-02-07T11:53:45.050019Z

there's also a mild push from future core.async towards Java 21+ because virtual threads

dnolen 2025-02-07T13:32:14.755279Z

yeap