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.

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

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)

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

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

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

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 😛

thanks!

@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?

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)

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"])))

Perhaps this should also then be updated in CLJS? https://github.com/clojure/clojurescript/blob/514274cab1d1798a1754758502e6fee2ab32103a/src/main/clojure/cljs/analyzer.cljc#L744

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

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

@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

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

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

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

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

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

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

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

because that's what we generate

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

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

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

this is not about "correctness"

it's about prevent future breaking from GCL whims

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.

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