Fork me on GitHub
#cljs-dev
<
2019-04-05
>
mkvlr08:04:08

should it be possible to require cljs.loader from a node target using npm-deps or is https://dev.clojure.org/jira/browse/CLJS-3067 expected?

thheller09:04:01

@mkvlr cljs.loader isn't really usable in node. don't know why compilation fails but otherwise you'd probably get runtime errors

mkvlr09:04:16

@thheller yeah, I don’t want to use it there but my namespaces are used for node and the browser and they require it

thheller09:04:40

hmm yeah that should probably work. not sure why it doesn't

mkvlr09:04:18

or not quite yet, compilation works but then I get a require error

mkvlr09:04:22

will dig deeper…

mkvlr10:04:24

don’t have a clear idea on how to best address this, think I’d some feedback on the approach to take

mkvlr10:04:05

would like to leave another comment on the issue but seems I’m lacking permissions

thheller10:04:58

@mkvlr ping @alexmiller about the permissions. they were locked down due to spam.

👍 4
mkvlr10:04:21

thanks, @U45J3R52L post for me for now

borkdude11:04:20

It seems private calls from cljs.core are not warned about:

$ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "RELEASE"}}}' -m cljs.main -re node
Downloading: org/clojure/clojurescript/maven-metadata.xml from 
ClojureScript 1.10.520
cljs.user=> (maybe-warn 1)
1
nil

mfikes11:04:33

That's odd; seems like qualified access doesn't slip through whatever crack that is.

ClojureScript 1.10.439
cljs.user=> maybe-warn
#object[cljs$core$maybe_warn]
cljs.user=> cljs.core/maybe-warn
WARNING: var: cljs.core/maybe-warn is not public at line 1 <cljs repl>
#object[cljs$core$maybe_warn]

mfikes11:04:49

Probably worth a JIRA

mfikes11:04:47

If I had to guess it is because the core vars have all been referred and, for referred things, private var access catches them at the time they are referred. Probably easy to special-case situations involving cljs.core.

borkdude11:04:37

I’ll file an issue

mkvlr11:04:02

wondering if I could remove the require for node

mfikes11:04:46

Hrm. I'm not familiar with what cljs.loader does internally. Would need to take a deeper look.

mkvlr11:04:07

there’s this special compilation pass in https://github.com/clojure/clojurescript/blob/91be632537f324d114916984b12194e919b7b5b7/src/main/clojure/cljs/closure.clj#L1228 but it throws without modules in module-graph/modules->module-uris

borkdude12:04:28

@mfikes

$ echo '(maybe-warn 1)' > src/foo.cljs
$ deps='{:deps {org.clojure/clojurescript {:mvn/version "1.10.439"}}}'
$ clj -Sdeps "$deps" -m cljs.main -re node -i src/foo.cljs
1

mfikes12:04:24

@borkdude Hrm. I don't understand. Is this illustrating something different? (Or just another way to repro?)

borkdude12:04:41

it’s repro-ing using version 1.10.439

mfikes12:04:51

Cool. Yeah, I did that as well above.

borkdude12:04:09

I thought you showed that it used to work with 439

borkdude12:04:51

now I understand. if you fully qualify it, it works

mfikes12:04:08

Yeah. I think that is the root of the defect. IIRC, when you refer a var, that's the time at which the feature catches the fact that the var you are referring is private. After that, you are free to use it. (I don't recall why this is the case, but I recall it being easier to implement this way.)

mfikes12:04:34

So, since all core vars are implicitly referred, I think this explains it.

mkvlr12:04:04

https://github.com/clojure/clojurescript/commit/a3dd687b273baf5f05f88aaa62245f407ef8623f fixes our use case (requiring cljs.loader in the class path but not in the dependency tree of the node main). But not sure if its the right way.

mkvlr12:04:46

signed the CA and attached the patch on Jira