This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-29
Channels
- # aws (1)
- # beginners (78)
- # boot (27)
- # cider (16)
- # clara (15)
- # cljs-dev (84)
- # cljsjs (13)
- # cljsrn (19)
- # clojure (65)
- # clojure-france (10)
- # clojure-italy (8)
- # clojure-russia (35)
- # clojure-spec (34)
- # clojure-uk (124)
- # clojurescript (50)
- # clojutre (3)
- # core-async (16)
- # data-science (18)
- # datascript (1)
- # datomic (9)
- # emacs (2)
- # flambo (3)
- # fulcro (55)
- # graphql (3)
- # hoplon (4)
- # jobs (2)
- # juxt (21)
- # keechma (6)
- # lumo (73)
- # off-topic (4)
- # om (10)
- # onyx (5)
- # parinfer (1)
- # pedestal (3)
- # re-frame (60)
- # reagent (19)
- # specter (24)
@anmonteiro Have I understood the :npm-deps and :install-deps correctly: :npm-deps is used to define the deps for apps and libs (in deps.cljs), but alone doesn't do anything, :npm-deps are installed only when :install-deps is true, and the reason why :install-deps exists is that we don't want to install :npm-deps from deps.cljs without option in the project.
is/was there consideration to make the path where :npm-deps looks for node_modules
configureable?
@kommen I don't know about that, but: :npm-deps
is only about installing Node packages, Node modules indexing is separate to that, and works even without :npm-deps
yes, that is exactly my problem: from the same codebase we compile 2 apps: one for the browser and for nodejs. and some of our dependencies are not compatible with the Closure commonjs processing, so we can’t use node_modules for the browser target. but the for nodejs target we now would need to use :npm-deps. so the nodejs target needs node_modules there, where the browser target shouldn’t find them
Hmm yeah, that will be problematic
You can remove the node_modules before building the browser version as a workaround
@kommen I believe it should be possible to get the isolation you want if your browser build doesn’t actually require anything from node_modules
this way the nses bringing in non-browser node deps is only part of one specific build
Perhaps the browser nses require some of the same libs as used by node build? E.g. node uses react from node_modules and browser uses react from foreign-lib
@juhoteperi exactly
@juhoteperi that doesn’t seem to agree with what @kommen said at 8:09am
we have one react library in the browser which Closure doesn’t like which relies on react comming from a foreign-lib. but for the nodejs reagent want to load react from node_modules
@kommen oh, are you trying to abstract away React usage regardless of whether React comes from foreign-lib or node_modules?
Reagent (alpha) does that
@juhoteperi yes, I’m on that alpha. but to have this working with nodejs target I need node_modules where ClojureScript tries to index them, right?
which then, as far as I understand, breaks for the browser build, because ClojureScript sees react in node_modules and uses it, but then the not-closure-compatible react-component can’t work
@juhoteperi what was your plan for supporting that in Reagent? Maven classifier?
on another front, as a heads up, since 1.9.908 the Closure compiler crashes when turning on :infer-externs
when compiling our project with optimizations. I filed an issue here: https://github.com/google/closure-compiler/issues/2629
other folks have run into the same issue: https://clojurians.slack.com/archives/C03S1L9DN/p1503306193000033
@dnolen Reagent alpha uses foreign-libs, IF node_modules dir doesn't exist
No need for maven classifier or anything
@juhoteperi right but that seems suboptimal given @kommen report and future similar ones
this is why I suggested managing this via the classpath long ago rather than attempting any detection in lib
I think it would make sense to provide option to either disable node module indexing completely, or provide option to set Node Module indexing working directory
I'm open to other other solutions (which is why Reagent is still alpha) but I don't yet understand what the other solutions would be
@dnolen doing this via classpath makes it hard to have parallel node & browser builds in the same JVM, which is a drawback to that approach.
@kommen @juhoteperi is using multiple node_modules dirs standard?
@dnolen I tried downgrading Closure, but I think compiling then failed due to api incompatibilities
@kommen sounds like this problem needs a lot more information before anybody is going to even start thinking about looking at it
I would file a corresponding issue in ClojureScript - but the same caveat applies - more information please
I think there are cases where Node projects have multiple node_module dirs, or at least multiple package.json, e.g this mono repo using Lerna: https://github.com/material-components/material-components-web/tree/master/packages/mdc-base, each package has own package.json
I think a Node project could also have sub dirs for browser and node targets, and then use shared code from third folder
and browser and node targets would have their own package.json and node_modules
@juhoteperi I’m asking something different
Yeah I don't know about that
Haven't seen it, and I'm not sure if npm provides configuration for that
Is there a different approach, where #?(:cljs/node (node_modules-blah) :cljs/browser (stuff))
is done?
@juhoteperi there's an env variable for it.
@juhoteperi then option to disable node_modules
processing seems the least boxing-in way to go
I think Closure has option to set root dirs for Node dependency resolution
@juhoteperi resolution is separate from :module-roots
pretty sure and we already have an option for that
@dnolen I know, tried to find out more information, but I’m not yet familiar in neither affected areas in both compilers. just wanted to track the issue somewhere in case other people run into the issue
Okay, I was wondering if Closure option defaults to .
and is hardcoded to look under ./node_modules
, or if it defaults to node_modules
It is the first, so it can't be changed to look at other folders
@kommen there’s might be an easy way to repro - just make a dummy JS project with the extern file we generate
@juhoteperi hrm yeah that I’m not really aware of
ah, I see what you mean. I only tried to create a repro case from scratch with no success
@kommen well, I suspect there isn’t going to be an easy answer for your problem anytime soon - too many different things to consider
just load it two different ways - you don’t need :npm-deps
really for what you are doing anyway
@juhoteperi could checking for the node modules directory also be problematic if I'm running a simultaneous unrelated build with node, and don't want reagent to use it at all? E.g. I'm doing postcss on one terminal. And boot dev in the other
@dominicm Depends on if you have node_modules
dir present on the working dir
@juhoteperi yep, for postcss. This seems like a common enough scenario that could also happen. Would it be possible to switch on a compiler constant perhaps?
(`goog`‘s appears to run significantly faster—sometimes 2×—, at least without :advanced
involved)