Clojurians Log v2

I do see in mvn repo, the description: > The Google Closure Library is a collection of JavaScript code designed for use with the Google Closure JavaScript Compiler. This non-official distribution was prepared by the ClojureScript team at http://clojure.org/ I am curious where is this “prepared by the ClojureScript team” at?

The 0726fdeb part looks like a short Git hash. https://github.com/google/closure-library/commit/0726fdeb

Perhaps part of my answer would be to look https://github.com/clojure/clojurescript/commit/715cdc07dbb1d595af91ea12affb6faf0b615d4b and try to track back to the artifact updates there.

Oh, so I overlooked that the short hash is there

Doesn’t https://github.com/google/closure-library/commit/0726fdeb seem like a fairly arbitrary commit from the library - not something they tagged as a release etc?

Might be the latest version available at the time it was prepared as a jar, dunno.

Although that CLJS commit says "GCL snapshot is from December."

Interesting. I’m trying to understand this update process

Also, it’s notable that this is from 2021 - pretty old

Maybe I am not looking at latest cljs though

https://github.com/google/closure-library/commit/0726fdeb I think so

I recently had a tricky google closure issue to debug & was trying to track down the impl and realized it was weird to find the cljs version being used - and then I came to realize it seemed like the cljs version is pretty old. The code that I was interested in, in particular, has changed quite in “modern closure” versions.

Not sure how relevant it is, but FWIW I believe shadow-cljs uses one of the latest GCL versions, maybe with some tweaks, and things work just fine, with very rare exceptions.

Yeah, I thought shadow may be trying to stay more in sync. I have been considering trying it out to see if I like the experience more. I’ve been more of a traditionalist (minimalist?) up to this point and worried about something like shadow that is doing things different than core.

I appreciate the feedback

the closure library didn't use to have "releases" and even nowadays its more like "whatever HEAD was on date X"

I think CLJS master was updated to the closure lib version shadow already uses, or might be in some branch. it is pending though.

nothing much relevant changes in the closure lib, mostly bugfixes in code we don't use 😛

unless you are somehow using goog.ui and stuff

Interesting. The latest cljs master and 1.11 tag I see seems to be on a 2021 closure version

I thought at one point you mentioned the “debug loader” going away from closure? I thought that may have a pretty big impact on cljs repl none optimizations?

I was wanting to track that past conversation but have lost it

I noticed when testing in jsdom recently that the :none optimization style cljs currently uses doesn’t work in jsdom at all due to the dynamic document.write(“<script>…”) usages

yes, there was a commit suggesting they were to remove it. nothing has happened there yet though.

Ah ok, thanks for the info.

these are the package.json docs: https://docs.npmjs.com/cli/v9/configuring-npm/package-json#main

oh you mean that some dependencies use that key instead of the officially documented one?

lots of packages ship with both, using module for newer esm and usually main for the transpiled commonjs variants

but there are some that only use module with no fallbacks

I see no docs on "module" but I do see this: https://nodejs.org/api/packages.html#exports

not a lot of packages use exports yet. there are also some differences in how webpack and node handle that, so thats a bit annoying

> Prior to the introduction of support for ES modules in Node.js, it was a common pattern for package authors to include both CommonJS and ES module JavaScript sources in their package, with package.json "main" specifying the CommonJS entry point and package.json "module" specifying the ES module entry point. This enabled Node.js to run the CommonJS entry point while build tools such as bundlers used the ES module entry point, since Node.js ignored (and still ignores) the top-level "module" field.

@borkdude yes I think this is one of those things that magically works even though you’re not supposed to it that way?

(this text came from Dual CommonJS/ES module packages in the link above)

so it seems that top level module fields isn't an npm thing but a tooling convention (webpack etc?)

right but we look at that stuff for resolution

one question would be whether considering module for Node would cause problems - I’m thinking it might

so maybe we need to check that nothing else is available etc.

node also has "type":"module" which also makes it behave differently

pretty big mess overall

and to make it more complicated:

// package.json
{
  "exports": {
    "import": "./index-module.js",
    "require": "./index-require.cjs"
  },
  "type": "module"
} 

thats not even the fun part, gets real fun with wildcards and other nested things

I have attempted to implement it several times now and always get fed up. no one even bothered to define a proper standard, so every tool does something slightly different. I'm now waiting till things settle and there is one "winner"

So many bad ideas let’s just put ‘‘em all in!

indeed

I am running into several libs lately that are using “package exports”.

And I’ve had issues in CLJS with a :bundle target in that CLJS doesn’t understand “package exports” indexing. So I have to do a :require to the “real module file” that CLJS does find. Then I have to configure webpack to ignore it’s “package exports” built-in resolution.

Example: recent versions of react-select. I have to do this in webpack:

resolve: {
    alias: {
      "react-select/creatable/dist/react-select-creatable.cjs":
      path.resolve(__dirname,
                   "node_modules/react-select/creatable/dist/react-select-creatable.cjs.js")
    }
  }

we could add that, the code is a bit ugly - would be good refactor the resolution stuff a bit so it more understandable

+ tests to show what it’s supposed to do

If I don’t do this, webpack v5+ will not allow me to access this file. It “enforces” package exports.

well I might start on this refactor tweak because I need this for work anyhow

perhaps one result is that this code will be easier to adjust in a sensible way

That sounds like it could be pretty nice. I was reading the current impl recently a bit.

I think lifting it to a helper namespace and breaking everything apart is a good start - w/ some comments

Why does CLJS have to parse package.json btw? Shouldn't node/JS tooling just to the right thing when you emit a require() or import()?

It used be like that that - if you did something wrong fails at runtime of course

When I did the bundle support stuff might as well validate reusing that work

Oh but also you have to know to emit JS require - and that means you have to know which node modules exist

I had this thought at one point too. “Could cljs just assume anything it didn’t know in a :require should be a JS require?” But I could see how that’d be leading to bad runtime errors. Eg a typo in a require (maybe intended as a cljs ns) would lead to a weird later failure from a bundler that may be misleading. I didn’t know if there was other reasons for cljs to check JS dep referenced existed though (for a target like bundle).

the main thing is that semantics of the ns form is that we check early whether a namespace exists or not

so this maintains that expectation

Makes sense to me

the default shadow-cljs uses for most things is :ecmascript-2020

only exception is the :react-native target since the hermes engine (now the default I guess) only supports es5 (no const support used in goog.* stuff)

I see, CLJS took a PR that defaults :es-next

but some of these tests set lang in

but GCL itself appears to be :es-2017 at a minimum

lang-in is always set to the highest (so :es-next) in shadow, there doesn't seem to be a downside to setting it too high

and the compiler figures it out anyways when compiling

yeah that’s what I’m doing now

thanks!