@shaun-mahood wrt CLJSJS I think this would make it much easier to maintain by just packaging externs and a deps.cljs file

answering your 2nd question, this is about making NPM more like Maven/Clojars, yes, by automatically installing Node.js deps and computing their dependency files

> assuming the tooling is in place

^ this is actually not true, as it doesn't require any changes to tooling 🙂

because everything will go under foreign-libs anyway, and tooling is already prepared to handle that

of course you should have NPM and Node installed when providing a :npm-deps option, but that goes without saying

we also won't require you to have any of those installed if you're never providing the option

in any case, I'm glad you asked. I'm sure others will have the same exact questions, so I'll write a blog post to clarify all this

Wow, better than I thought 🙂 This is going to be fun!

@dnolen: Added a deprecation notice to https://github.com/clojure/clojurescript/wiki/Rationale - do you want to make any tweaks to wording or format before I go through the rest of the pages?

FWIW I think managing npm via CLJS is a bad idea. I voiced my concerns over too much "tooling" creeping into core cljs some time ago although I still seem to be the only one with those concerns

https://groups.google.com/d/msg/clojurescript/xMQuEmQt7oQ/AWT5RZe_nQQJ (disregard that I was talking about REPLs)

npm would be equal to having lein in clojure.core IMHO, not only do we inherit all the headaches npm brings

we also force it onto the user, what if they want to use yarn?

@anmonteiro talking specifically about some of the commits you did recently. it is all very interesting work but could/should probably happen in a library (ie. http://dev.clojure.org/jira/browse/CLJS-1973)

IMHO of course, YMMV

I don't like calling npm either

For Cljsjs I would still like to have all the files in the packages

But instead of foreign libs, I'd like to package files from npm packages

The current implementation messes with the node_modules on current directory, which is quite "un-Boot", though it works

The interesting part of this is that those files are copied to output-dir before running module processing

Or are they? Probably not as Closure gives some warnings about those files before Cljs copies them to output-dir

@thheller this is only about basic module support. We provide a default, easy way for people to manage their node modules. You can use them or not. The different pieces are still there if you want more control over your module build process, e.g. look at cljs.closure/index-node-modules. That's tool agnostic and just needs a node_modules folder with the modules installed

^ @juhoteperi you should also look at this function if you want to package the files too

Packaging the npm files in jars is not the problem, I already have solution to that.

The problem is that Closure node_module resolution only works if the files are found in filesystem.

@thheller also this is only "too much tooling" if you ever decide to use it. You won't need to have Node or NPM installed if you don't use :npm-deps

@anmonteiro that is not true, any dependency I might want to use may expect me to use it

to be fair .. i have nothing against :npm-deps. that is useful information any tool could use.

however shelling out to npm and installing them is where I have issues

That's fair, that an upstream library might use :npm-deps

The NPM problem is a little different. How would you solve it in a way that allows upstream libs to depend on NPM packages?

and to be clear here: I'm not saying that you should not do it, you should totally do all of this. Just in a library

it would allow you too move way faster and experiment as well

if all is stable and "done" we could still have discussions about including it in core

but doing alpha-level experiments with no clear design goals is not something that should happen in core

sure it would be nice to have .. maybe ..

@thheller expressing your concerns is 100% OK

but I do not share any of your concerns

the point about unknowingly picking an npm module via upstream is probably a valid concern - simple enough to put a compiler flag around it either preventing or warning about it

but in general I’m of the opinion if you don’t like this feature, don’t use it. If you want it in 3rd party library go make that and do it better so people use it instead 🙂

@dnolen thats fair. you have to approve all the commits after all.

I agree with overall assessment that dealing with NPM or anything 3rd party JS dep thing is a bit of gamble

but the idea around this feature is to address a pain point for applications developers not library developers

which is why we’re not really going to spend much time around the NPM/Yarn rabbit hole

and people requesting more features will just be out of luck

@juhoteperi the Module resolver is a pluggable thing, but I believe perhaps not fully exposed

yeah, just concerned that we might end up trading one pain point for another

I wonder if we could provide a classpath based thing-y if it was

working with https://github.com/Microsoft/monaco-editor right now .. they sort of use npm but not really ... very confusing

just a side note why npm scares me so much

@favila the minimal case for our issue