Allow symbols to refer to JS libs

[babashka]

Allow symbols to refer to JS libs

[borkdude]

Some info from @thheller:

6m
thheller none of what regular CLJS does in this regard affects how shadow-cljs handles it. in shadow I have the extra restriction that strings are only allowed for JS dependencies
6m
thheller (:require ["clojure.string" :as str]) is valid in CLJS but not shadow-cljs
6m
thheller I feel strongly about strings being only for not-regular-namespace JS code
5m
borkdude I hadn't tried it with shadow.
5m
thheller I'm surprised it doesn't work in CLJS though
5m
borkdude
not-regular-namespace JS
Do you mean: always use strings for JS nss, or do you mean: there's also regular-namespace JS code?
4m
thheller closure-library is regular-namespace JS code technically (well at least some of it) (edited)
4m
borkdude btw, this is the convention that clj-kondo has adopted as well: use strings for JS nss, then static analysis knows what's going on, so that's in line with shadow I guess. goog.* stuff is handled separately
4m
thheller you know goog.provide and goog.require etc
3m
thheller yeah the issue I have with js-deps-via-symbol is that it relies on some wonky detection of whats present in the node_modules folder
3m
borkdude I was about to support (:require [whateverjslib]) in nbb but perhaps I should not?
3m
thheller ie (:require [react]) is valid only if node_modules/react exists but not otherwise
2m
thheller with (:require ["react" :as react]) you at least tell the compiler that you intent to use JS code (and the :js-provider will know how to provide it)
2m
borkdude that's also what nbb is currently suggesting
2m
thheller but js-provider is only a concept in shadow-cljs so I guess that is why I'm biased here
2m
borkdude this makes it easier for nbb to know what to do
1m
thheller that being said .. I'm surprised goog$global.Thing doesn't work in regular CLJS. it should but there is an open ticket specifically about "globals" so maybe thats why it doesn't work
<1m
borkdude I'll stick to the string-subset of requires for JS libs for nbb, in line with shadow, which also works well for clj-kondo.

[borkdude]

Some perspective from dnolen:

5:45 PM
borkdude Continuing on the cljs vs js lib "namespace", are there any heuristics that can be applied whether to detect a cljs namespace vs js lib, beyond just trying to load the js lib, catch and then try the cljs lib? can also first check the classpath for the cljs lib and then try the js lib
This is more a question about how CLJS itself implements it. I can also just go read the source. (edited)
6:20 PM
dnolen @borkdude note that there are significant differences here between what ClojureScript does and what shadow-cljs does
6:20 PM
but what ClojureScript does is index node-modules
6:21 PM
there is no other way detect whether a library is one or the other
6:21 PM
borkdude right, because CLJS is a compiler and you can't just try something at runtime
6:22 PM
(unless you generate that code but that gets messy)
6:22 PM
dnolen this was true always
6:22 PM
long before node_modules
6:22 PM
we indexed Closure Library - you can requires a Closure Library just like a normal CLJ namespace
6:22 PM
nothing to distinguish one kind of require from the other
6:24 PM
borkdude right. in nbb I have the luxury that I can use resolve (on a require created with createRequire) to lookup the JS source first. I just wonder if that would be correct: JS and if that fails, then try CLJS, in that order.
6:26 PM
I guess a conflict is really rare
6:26 PM
dnolen pretty sure that's not the order we use
6:27 PM
I think it's something like
6:27 PM
CLJS, node_modules, Google Closure, classpath JS (edited)
👍
1

6:29 PM
borkdude classpath JS, I can't remember I've ever used that
6:29 PM
dnolen for the case where you're writing Google Closure JS
6:29 PM
transit-js works this way
6:30 PM
again the whole point of the ClojureScript design is "who cares where this stuff comes from?"
6:30 PM
it's just some namespace with something you want to use (edited)
6:30 PM
it's also why we ended up with $
6:31 PM
because all this ESM stuff is nothing we care about
6:31 PM
all JavaScript libraries are simply nested objects
6:31 PM
and we've supported using that pattern since day 1 - that's how Closure works
6:31 PM
borkdude yes, it makes sense, I just have never used it myself, but I can imagine that there's a use case for it (like you've mentioned). this is helpful, thanks
6:32 PM
does the async ESM stuff complicate stuff for CLJS or is it just a matter of setting the right JS language target and it generates import stuff? (edited)
6:33 PM
dnolen we simply don't support dynamic require
6:33 PM
borkdude I mean, e.g. CLJS on deno, loading "namespaces" from web resources
6:34 PM
dnolen what I'm saying is we don't support this thing at all - and are probably unlikely too
6:34 PM
unless Closure does
6:35 PM
it's my opinion that all the JS changes over the years has a net negative
6:35 PM
and the more stuff happens the more likely we're not going to do anything about it
6:35 PM
this is the strategy around :bundle
6:36 PM
somebody else's problem chasing low-value stuff
😆
1

6:36 PM
lilactown yeah. right now CLJS uses google closure's way of bundling and loading modules, which is distinct from async import.
you can use async import to get external JS to load, but that isn't something that involves the compiler in any way. you would just call (js/import ,,,) or whatever
6:36 PM
dnolen exactly it's not our intention to make things impossible
6:37 PM
but my experience w/ interop heavy stuff in Clojure & ClojureScript is it's a losing game
6:37 PM
in that some things are better written in Java and JavaScript (rather than adding features to achieve parity which is always a moving target) (edited)
6:37 PM
borkdude maybe CLJS can add its own module standard to the mix 😆
6:38 PM
(not serious)
6:39 PM
do you still think Closure was (and is) a good decision? (edited)
6:39 PM
dnolen it's still state of the art far as I can tell
6:40 PM
my primary complaint - though it's somewhat of our creation is that Closure doesn't follow a Hickey-esque approach to development
6:40 PM
removals, renaming, signature changes you name it
6:41 PM
I think in the old days Closure development was slower because they were a lot of consumers of the APIs
6:41 PM
but I think we're probably the biggest one now by far
6:42 PM
lilactown it's also hard to go back in time to 8 (?) years ago and think to pick any other solution
6:43 PM
dnolen but more importantly ESM is not a good answer
6:43 PM
lilactown it really was the best at the time, and any solution built on top of other existing tech back would have seen at least as much churn and discrepancies with current bleeding edge tech
6:43 PM
dnolen Google Closure namespaces are effectively late bound environments
6:44 PM
this is what lets the REPL work w/o Clojure Var stuff
6:45 PM
all the Dead Code Elimination stuff works around ESM modules from what I can tell
6:46 PM
anyways, I don't think the calculus has changed at all
6:46 PM
because JS people don't have proper live programming and they're never going to
6:46 PM
lilactown yeah ESM essentially cemented the status quo a lot of other bundlers set w/ using closures as modules rather than object namespaces
6:47 PM
that requires reloading the entire app from the root when any dependency changes
6:47 PM
dnolen not saying that Racket is bad - but that where ESM comes from, people that worked on Racket
6:48 PM
One of the very best ideas that Rich Hickey had (among all the others) is form-at-time compile
6:49 PM
and avoiding modules as compilation unit
6:49 PM
lilactown interesting, didn't know the Racket lineage there
6:51 PM
I guess module-at-time compilation makes some mechanical sense, since pragmas set at the beginning of a module can radically change the way compilation is done. is that how most schemes work?
6:54 PM
dnolen Smalltalk didn't work that way, Lisp didn't work that way
6:55 PM
then you had Self - which continued Smalltalk
6:55 PM
StrongTalk / Self laid the foundation for proving you could optimize all kinds of wild thing at runtime (edited)
6:55 PM
whereas previously people believed you had to do this whole program optimization up front
6:56 PM
Clojure whole idea was that you have runtime optimizing compiler and fast GC - so just focus on the stuff that matters
6:57 PM
ClojureScript was created right at the time that was becoming true for JavaScript - and the design is based on the same principles