This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-18
Channels
- # announcements (2)
- # babashka (35)
- # beginners (59)
- # calva (17)
- # cider (3)
- # clerk (7)
- # clj-kondo (21)
- # cljfx (9)
- # cljs-dev (76)
- # clojure (98)
- # clojure-austin (3)
- # clojure-brasil (1)
- # clojure-europe (11)
- # clojure-gamedev (4)
- # clojurescript (14)
- # consulting (7)
- # cursive (6)
- # datascript (4)
- # datomic (12)
- # emacs (18)
- # events (2)
- # graalvm (9)
- # humbleui (3)
- # hyperfiddle (18)
- # jobs (4)
- # missionary (12)
- # nextjournal (2)
- # nrepl (7)
- # off-topic (31)
- # practicalli (2)
- # rdf (6)
- # releases (2)
- # scittle (10)
- # xtdb (9)
How can I relate the org.clojure/google-closure-library version back to the actual closure-library source tag/sha? eg. https://mvnrepository.com/artifact/org.clojure/google-closure-library/0.0-20211011-0726fdeb I don’t see “0.0-20211011-0726fdeb” as a tag or something I can find in https://github.com/google/closure-library I looked at tags they do have that were similar in the date string part, but there was nothing for 20211101 either (some were close such as https://github.com/google/closure-library/tree/v20211107 )
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.
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?
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.
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 😛
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 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.
hrm I guess some Node packages now use the module
key over the main
key to identify the entrypoint?
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
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.
@U04V15CAJ yes I think this is one of those things that magically works even though you’re not supposed to it that way?
so it seems that top level module fields isn't an npm thing but a tooling convention (webpack etc?)
one question would be whether considering module
for Node would cause problems - I’m thinking it might
and to make it more complicated:
// package.json
{
"exports": {
"import": "./index-module.js",
"require": "./index-require.cjs"
},
"type": "module"
}
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"
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")
}
}
so I can use a :require
that CLJS allows.we could add that, the code is a bit ugly - would be good refactor the resolution stuff a bit so it more understandable
If I don’t do this, webpack v5+ will not allow me to access this file. It “enforces” package exports.
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()
?
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
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)