This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-10
Channels
- # aleph (4)
- # beginners (32)
- # cider (12)
- # cljs-dev (56)
- # cljsrn (7)
- # clojars (3)
- # clojure (165)
- # clojure-dev (33)
- # clojure-germany (1)
- # clojure-italy (27)
- # clojure-russia (7)
- # clojure-spec (24)
- # clojure-uk (62)
- # clojurescript (37)
- # core-async (7)
- # core-matrix (1)
- # cursive (9)
- # data-science (8)
- # datomic (8)
- # duct (4)
- # events (1)
- # figwheel (7)
- # flambo (3)
- # fulcro (43)
- # hoplon (25)
- # jobs-discuss (8)
- # lein-figwheel (4)
- # luminus (2)
- # off-topic (35)
- # om (8)
- # om-next (3)
- # onyx (30)
- # pedestal (62)
- # portkey (2)
- # protorepl (2)
- # re-frame (40)
- # reagent (9)
- # shadow-cljs (123)
- # specter (30)
- # sql (22)
- # testing (1)
- # uncomplicate (40)
- # unrepl (3)
- # vim (13)
- # yada (5)
some feedback from using the new JS-deps stuff in the wild: while very cool to be able to bring things in from npm, I’m finding it difficult to know where my JS deps come from. If I put a :foreign-lib
in deps.clj
that maps some namespaces to a javascript file, I don’t know whether this will be overridden by something in node_modules
, or another foreign dep from cljsjs (which I include to provide externs). This leads to scenarios where sometimes I can “fix” my build by running npm uninstall <the-lib>
, which feels wrong.
It’s possible that I have been using :foreign-libs
badly all along, but I thought I was getting the hang of this.
you should always know what’s in your dep graph, we’re not going to magically solve that probelm
It might also make sense (be possible) to have a warning if foreign-libs depend on node modules (or other way around), as mixing two probably doesn't work
To me it is a bit of 'magic' that a foreign lib which previously did one thing will do another if there happens to be something in node_modules with a particular name. There does not appear to be explicit configuration of where these deps come from?
foreign libs didn't previously expose libs with the same name as node modules use
and the foreign lib doesn't change, it is the require in Cljs code which works differently, refering to node module instead of foreign lib
but yeah, this is a bit magical
I don’t actually understand what problem you are trying to describe since you aren’t really giving it a name
classpath, and node_modules and the later is generally less disciplined as result of users
I think reporting clashes would be very helpful. Indicating when they occur, and which source is overriding the others.
I would expect a deps.clj
file that I manually enter into a project to take precedence over ‘ambient’ deps in node_modules
@dnolen i have been including cljsjs.react
just for externs, and then using deps.clj
to specify other files, then finding that the cljsjs stuff is what’s being included
you’re also talking about a problem specific to cljsjs.react
and libs that make a similar sets of choices
was just trying to collect more information do understand what you perceived the problem to be
if I have (ns ... (:require [react]))
, and in deps.clj
a foreign lib with a react
global-export, and cljsjs.react
included for externs purposes, in what order is react
resolved?
probably the only thing we should do is warn and respect classpath (and other explicit) stuff
or at least it seems that way at the moment - can’t spend anymore cycles on this at the moment though
@mhuebert also I’m thinking using cljsjs.react
only for externs is probably just not going to work if the cljsjs.react
can be configured to consume react
from different places
adding a knob for that also doesn’t seem like a particularly good idea to me at the moment
using cljsjs
just for externs is recommended here: https://anmonteiro.com/2017/03/requiring-node-js-modules-from-clojurescript-namespaces/#this-does-not-obviate-the-need-for-externs
so the decision of cljsjs.react
to offer a react
global-export is questionable - better to be cljsjs.react
? then it would not collide with react
in node_modules (https://github.com/cljsjs/packages/blob/master/react/build.boot#L60)
current behaviour seems to do the equivalent of adding all node_modules package names, without any kind of prefix, into the ‘classpath’, and override whatever you might have manually specified in your own deps.clj
file. this is a lot of names, which can change without any intent on the user, as transitive deps of anything you npm install
get added there.
I guess this is similar to how transitive deps of a clojure dependency are also added to the classpath. a bit worse because most node stuff isn’t namespaced
cljsjs/react
and React node_modules must provide same name, so libraries (Reagent, Om) can be used with both
@juhoteperi that makes sense. I guess it’s this automatic resolution that is confusing me.
Is there a way to explicitly say, “`react` should come from node_modules” or “`react` is here in this file I am supplying myself” or “`react` is supplied as the global variable React
“?
I thought one could do that via deps.cljs/:foreign-libs, but it is overridden by node_modules. The resolution order is exactly the opposite of what I would expect. It’s currently 1. node_modules, 2. project.clj :dependencies
, 3. the deps.cljs
in my own project