This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-11
Channels
- # announcements (4)
- # babashka (50)
- # beginners (45)
- # cider (12)
- # clara (1)
- # clj-commons (6)
- # clj-kondo (3)
- # cljdoc (3)
- # cljs-dev (44)
- # clojure (19)
- # clojure-europe (15)
- # clojure-france (1)
- # clojure-nl (13)
- # clojure-portugal (4)
- # clojure-uk (6)
- # clojurescript (3)
- # conjure (3)
- # cryogen (10)
- # datomic (23)
- # emacs (9)
- # fulcro (12)
- # graalvm (1)
- # graphql (2)
- # introduce-yourself (2)
- # jobs (4)
- # jobs-discuss (9)
- # lsp (2)
- # pathom (3)
- # polylith (23)
- # portal (1)
- # reagent (14)
- # releases (4)
- # remote-jobs (3)
- # shadow-cljs (1)
- # sql (8)
- # tools-build (7)
- # tools-deps (10)
- # xtdb (7)
I've been using target bundle today with optimizations whitespace (as this will be run through karma test runner). It seems like :bundle
has a nodejs-like regression of CLJS-101. I haven't gone source diving into clojurescript yet, but my guess would be that the nodejs bootstrap needs to be used for the bundle whitespace case.
or that is, it's not supported with node.js - and it might be the case it shouldn't be supported for :bundle
for similar reasons
That sounds right. By explicitly not supported under node.js, do you mean that it produces an error, or is it "it may work, but we don't try to make it work. Use at your own risk".
Just to clarify @dnolen, which optimizations are supported for :bundle
?
the only optimizations we ever spend any time on are :none
and :advanced
both require a lot of effort
https://clojurescript.org/reference/compiler-options#optimizations should this be updated to mention the unsupported combinations (right now only bootstrapped cljs is mentioned)
the first step before changing anything - is just reporting that it doesn't work - second step is why it doesn't work
I don't remember at the moment why it cannot work - but I'm in the middle of other stuff so not going to unload for this
there are lot of weird things about how things are loaded which cannot work in that context
The bugs I noticed were google modules(? goog.provide, etc.) being loaded completely out of order.
and all these different environments, and leverage Google Closure debug loader and all the various module formats
:advanced
is a crazy amount of work for a different set of reasons, but everything gets erased
so it not surprising dep order issues arise in Node.js - and it's possible that :bundle
is a variant
heh, I almost forgot that the first issue is that :process-shim
is incompatible too!
The combination of problems is that :process-shim
generates something like process.env.NODE_ENV=...
, then webpack sees process.env.NODE_ENV
and replaces it with "development"
and you get "development"=...
which isn't valid JavaScript...
I'm not sure if other tools are more sophisticated though.
I've opened https://clojure.atlassian.net/browse/CLJS-3329 regarding the whitespace/bundle issue.
@alexmiller need a Google Closure Library release when you get a chance - it is building right now
B) We now specially handle goog.module
so that in theory it should always work, regardless of whether declared legacy or not
on a more positive note - it seems Google itself have soured on ES6 support some what - I guess they are coming to the realization that it's not a great fit for the compilation model
goog.module
as preparation for ES6 support seems like a whole lot of wasted time and complexity
ES6 modules also looks like something that should probably have been avoided if they don't actually need it beyond maybe consuming a useful library here or there
I thought ES6 was specifically designed for static analysis & ergo compilation. I'm surprised that it's not a good fit. I'd love to read a deep dive on this!
ok, these are now available: org.clojure/google-closure-library 0.0-20211011-0726fdeb org.clojure/google-closure-library-third-party 0.0-20211011-0726fdeb