Clojurians
#cljs-dev
<
2017-03-12
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

anmonteiro00:03:11

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

anmonteiro00:03:04

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

anmonteiro00:03:46

> assuming the tooling is in place

anmonteiro00:03:09

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

anmonteiro00:03:32

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

anmonteiro00:03:59

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

anmonteiro00:03:26

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

anmonteiro00:03:23

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

shaun-mahood00:03:36

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

shaun-mahood00:03:41

@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?

thheller08:03:19

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

thheller08:03:10

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

thheller08:03:24

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

thheller08:03:10

@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)

thheller08:03:08

IMHO of course, YMMV

juhoteperi09:03:08

I don't like calling npm either

juhoteperi09:03:39

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

juhoteperi09:03:56

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

juhoteperi10:03:09

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

juhoteperi10:03:35

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

juhoteperi10:03:06

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

anmonteiro16:03:23

@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

anmonteiro16:03:58

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

juhoteperi16:03:02

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

juhoteperi16:03:22

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

anmonteiro16:03:35

@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

thheller17:03:34

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

thheller17:03:33

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

thheller17:03:57

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

anmonteiro17:03:55

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

anmonteiro17:03:11

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

thheller17:03:32

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

thheller17:03:01

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

thheller17:03:34

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

thheller17:03:43

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

thheller17:03:37

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

thheller17:03:31

That is up to whatever tool you are using. The tool may decline to build, informing you do add the deps to your package.json or do it automatically like you are doing now.

dnolen19:03:08

@thheller expressing your concerns is 100% OK

dnolen19:03:47

but I do not share any of your concerns

dnolen19:03:04

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

dnolen19:03:49

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 :slightly_smiling_face:

thheller19:03:47

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

dnolen19:03:58

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

dnolen19:03:28

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

dnolen19:03:48

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

dnolen19:03:42

and people requesting more features will just be out of luck

dnolen19:03:03

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

thheller19:03:22

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

dnolen19:03:24

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

thheller19:03:37

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

thheller19:03:01

just a side note why npm scares me so much

dspiteself20:03:54

@favila the minimal case for our issue