Fork me on GitHub
#cljs-dev
<
2021-10-20
>
borkdude07:10:03

Can you or someone else make some prose as to what changed and why users should change something? I feel like Iā€™m missing some details. E.g. what does becoming a module mean. I checked the JIRA issue but it has no description.

thheller07:10:50

the closure library has different types of source formats. the old legacy goog.provide/goog.require system which CLJS uses where everything lives in the same shared global scope

thheller07:10:23

then the newer goog.module which is more like ESM or commonjs. meaning those files need to be rewritten before they can be loaded in the runtime (eg. browser)

thheller07:10:45

there is a legacy goog.module variant that still exported the global name so it just worked with the "old" style

thheller07:10:14

but newer goog.module no longer export that global name and need to be accessed in a different way, which creates this new problem

thheller07:10:41

the closure library has started moving more and more stuff to goog.module and recently also some without the legacy "bridge"

thheller07:10:47

technically goog.object is one of those legacy modules, so it would work with the old style but David wants to rip the band-aid off faster. not sure I agree with that but it likely needs to happen at some point so best to get it over with quickly šŸ˜›

borkdude09:10:56

@thheller So this is like ES modules where each CLJS namespace has to have its own reference to the imported module, rather than a global one? Are CLJS namespaces compiled as goog modules as well?

borkdude09:10:31

Or it is sufficient for one CLJS namespace to require goog.object to make it available to all (which you should not do, but technically I mean)

borkdude09:10:42

So I have this code in clj-kondo:

(when cljs?
                          ;; see 
                          (one-of ns* ["js" "goog" "cljs.core"
                                       "Math" "String" "goog.object" "goog.string"
                                       "goog.array"])))
I will remove goog.object , goog.string and goog.arrayfrom this. From then on, not requiring these modules will result in "Unresolved namespace: ... Are you missing a require?".

borkdude09:10:15

OK, committed this: https://github.com/clj-kondo/clj-kondo/commit/67b9d106bd4344f32e4de30c4beba56ebbcea30f Can do new release when new CLJS is about to be released.

borkdude09:10:19

Note: I also included goog.string, but I don't see a mention of that in this issue.

thheller15:10:50

@borkdude yes, somewhat like ES modules where each ns has a local reference. CLJS is not gonna use goog.module. any namespace should always require everything it uses, no exceptions and regardless of CLJS or JS. definitely good to remove those special cases you had there

dnolen18:10:07

@borkdude goog.string has not bee converted to module, nor goog.Integer

borkdude18:10:53

but wouldn't it be better if goog.string was required before use as well?

thheller18:10:31

yes, always. shouldn't depend on other namespaces having required it before

dnolen18:10:08

@borkdude in general for Closure namespaces yes - but I didn't want to spend a ton of time on a more less transitional thing

dnolen18:10:19

various libraries are most definitely going to break just from goog.object

dnolen18:10:32

that should be enough trouble for people to just stop the pattern

dnolen18:10:52

note this whole problem isn't really true for Closure-style JS in general

dnolen18:10:57

because that's what we generate

dnolen18:10:16

it's only a problem w/ Google Closure Library because they just change stuff whenever they feel like it

borkdude18:10:35

I never had a special case around goog.Integer in clj-kondo and nobody has complained about this. When I search for goog.Integer on http://grep.app I found 0 references

dnolen18:10:11

anything in GCL w/ the exception of base.js could be converted at any time

dnolen18:10:19

this is not about "correctness"

dnolen18:10:30

it's about prevent future breaking from GCL whims

šŸ‘ 1
borkdude18:10:39

Got it. Ah I see goog.math.Integer, makes sense. Yeah, no special case either, just require it before use and clj-kondo will be happy.

borkdude18:10:09

This is going to be released today in #lsp so those users including those using #calva will be seeing this change soon.

1