Fork me on GitHub
#cljs-dev
<
2021-10-11
>
dominicm16:10:48

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.

dnolen16:10:34

@dominicm it's explicitly not supported

dnolen16:10:08

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

dominicm18:10:02

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?

dnolen18:10:55

the only optimizations we ever spend any time on are :none and :advanced both require a lot of effort

dominicm18:10:09

https://clojurescript.org/reference/compiler-options#optimizations should this be updated to mention the unsupported combinations (right now only bootstrapped cljs is mentioned)

dominicm18:10:24

There's a :debug?!

dnolen18:10:57

the first step before changing anything - is just reporting that it doesn't work - second step is why it doesn't work

dnolen18:10:13

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

dnolen18:10:33

third step is a compiler failure for the combination

dnolen18:10:36

last step is updating the docs

dnolen18:10:30

for some context :whitespace is a strange one

dnolen18:10:43

there are lot of weird things about how things are loaded which cannot work in that context

dominicm18:10:47

OK, I will create a jira ticket with a reproduction, and we can go from there.

dnolen18:10:07

:none is a crazy amount of work because that's about REPLs

dominicm18:10:21

The bugs I noticed were google modules(? goog.provide, etc.) being loaded completely out of order.

dnolen18:10:26

and all these different environments, and leverage Google Closure debug loader and all the various module formats

dnolen18:10:09

:advanced is a crazy amount of work for a different set of reasons, but everything gets erased

dnolen18:10:16

there is no dynamic loading, REPLs cannot work

dnolen18:10:26

:simple is just a variation of :advanced

dnolen18:10:34

but :whitespace is a strange one

dnolen18:10:08

so it not surprising dep order issues arise in Node.js - and it's possible that :bundle is a variant

dominicm18:10:47

heh, I almost forgot that the first issue is that :process-shim is incompatible too!

dnolen19:10:48

right - tho - that sounds easy - just a error - we have checks for stuff like that

dominicm19:10:12

It might only be incompatible with webpack.

dominicm19:10:33

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.

dominicm19:10:11

I've opened https://clojure.atlassian.net/browse/CLJS-3329 regarding the whitespace/bundle issue.

dnolen20:10:49

thanks for all of the above

dnolen20:10:17

@alexmiller need a Google Closure Library release when you get a chance - it is building right now

dnolen20:10:53

zeroing on eliminating the latest round of chaos around Google Closure

dnolen20:10:10

A) ClojureScript now generates the missing deps.js file

dnolen20:10:08

B) We now specially handle goog.module so that in theory it should always work, regardless of whether declared legacy or not

dnolen20:10:38

end result is that we can bump to latest GCL which is now a year out of date

dnolen20:10:11

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

dnolen20:10:16

I guess it took them a while to figure that out

dnolen20:10:57

goog.module as preparation for ES6 support seems like a whole lot of wasted time and complexity

dnolen20:10:40

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

dominicm20:10:35

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!

1
dnolen20:10:36

@dominicm probably at the module level - but Closure is far more powerful than that

alexmiller21:10:34

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