Fork me on GitHub

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 šŸ˜›


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


OK, committed this: 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 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

šŸ‘ 1

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.