looks like the closure-library maintenance mode “announcement” has been made: https://github.com/google/closure-library

The worrying part for me isnt closure-library itself being frozen in August 2024, but this following line that seems to be a major breaking change for ClojureScript: > We are committed to retaining the core functionality in Closure Compiler, while dropping its dependency on Closure Library. This includes Closure dependency management (goog.module, goog.require, etc), reflection (goog.reflect.object, goog.reflect.objectProperty), defines (goog.define), and a few others.

guess thats a good excuse to start working on some alternate emitters for the cljs compiler

@hifumi123 I think it may be possible to misread that statement, I think they are talking about preserving those things

Like I said, internally they use tsickle, which compiles ES6/TypeScript into Closure namespaces

For third-party libraries, we use either tsickle (if it's otherwise compatible with Closure) or else we bundle the minified library with a security-vetted loader (when property renaming would cause problems).  This isn't a great long-term solution, though, since it pushes goog.module into a weird position where it only exists in generated code.

We do still have a handful of other cross-compilers that we intend not to break, including J2CL (plus kotlin) and emscripten.  Many of these (IIUC) tend to compile their own standard runtime libraries into Closure JS, rather than relying on Closure Library.  I don't know if it's an option for ClojureScript to compile more of the JVM into JS (though it tends to be a lot more bloated, unfortunately).  With increased external TypeScript adoption these days, we're hoping to see a more general trend toward better static typing that would also be more robust to property renaming, and even when that's not the case, shifting toward smaller dependencies makes it a lot less likely that you'll need a significant amount of dead code removal.

this was the last email communication I had w/ Steve Hicks, they intend not to break people who target Clojure JS

So Closure compatible code is fine, it's just the "standard library" like goog.object that is going away? It seems like the most common things could become cljs.object etc? and maintained as part of CLJS proper?

right first step would be to eliminate the various usage of Closure helpers in cljs.core - base, object, string, array, long, etc.

for stuff like browser REPL less important for the obvious reasons, a custom/native loader is probably not a bad idea but again there’s a not a pressing timeline

I have been thinking about tsickle for a long time now, with mass adoption of ES6 and TypeScript, I think it’s worth thinking about integrating w/ it for the advanced pipeline.

I think I misunderstand something. So GCC will stop using GCL. Why would it preclude CLJS from keeping on using GCL? If it doesn't, why not just keep using GCL?

Haven’t said we’re going to stop using GCL, we should continue to use it, offer it

but that’s really not in conflict w/ dropping it from cljs.core - and paving a smooth GCL-less for people who want that

but also I think it’s time seriously assess tsickle, I can’t say I love all the complexity that bundlers bring

if for a variety of projects you could just run advanced and skip dealing w/ JS bundlers that’s a win

the biggest question in my mind is about goog.module. Are they going to recommend we migrate to ES modules? My assumption is it's relatively easy to refactor usage of GCL in functions, however the alternatives to goog.module - at this moment, ES modules - present problems for REPL driven development and hot reloading because they use closures instead of global namespaces (I know you all know this).

people have solved the hot reloading problem at the bundler level. I don't know that GCC is going to add such affordances

ah I see that's what dnolen meant by > I think it may be possible to misread that statement, I think they are talking about preserving those things

@lilactown I think implication is that internally goog.module is not a thing

but I think there’s probably no push to get rid of it because of users that depend on it