Clojurians Log v2
cljs-dev 2024-05-21
Hello I think that this issue should be re-opened https://clojure.atlassian.net/browse/CLJS-1670 The current differences page does not include any mention to this difference/limitation https://clojurescript.org/about/differences
> Namespaces in ClojureScript are compiled to Google Closure namespaces which are represented as nested JavaScript objects. Importantly this means that namespaces and vars have the potential to clash - however the compiler can detect these problematic cases and will emit a warning when this occurs. First paragraph on https://clojurescript.org/about/differences#_namespaces section.
i was seeking for "conflict" keyword. facepalm
On this feature, the design is incomplete? A patch is welcome? https://clojure.atlassian.net/browse/CLJS-3233
@souenzzo it does mostly work as far as I know as noted by @thheller - I think one design problem is that we’re pretty late in the game - someone might have a single segment namespace called global … I guess we could detect that
the only thing missing from CLJS-3233 is sugar I think
right sorry forgot to clarify js/ is undesirable because it would be something new for the ns form
So the idea is now: global.foo :refer [bar]?
I think globalThis would be less chance of clashing with anything since that is a defined constant in JS environments now
on thought that comes to mind is that we already have the js/ special. we could just transfer (:require [js/some.thing :as x :refer (foo)]). might break some tools and specs so probably not the best idea, but seems nice
yeah or js$some.thing
or globalThis$some.thing , both ok to me
js$some.thing is very short and less likely to cause much trouble
(:require [js/foo.bar :as car]) is pretty awesome. Already solves my problem
how do you mean "already"? it works with the currently released CLJS?
as thheller notes, js/... violates the clojure.spec for the ns form currently, therefore js$ might be the way to go (and $ is already an existing convention in CLJS ns form)
agreed, js$ seems fine. close enough to js/ and it is very unlikely anyone has a js namespace, which we than could also ban/warn about