JavaScript Packing Issues and Best Practices

Hello all, I currently see a few issues surrounding the creation and maintainence of JavaScript packages:

1. The current way of building JS packages (npm install -g .) no longer works with conda build v3.
   • For example, https://github.com/conda-forge/jstz-feedstock/pull/1 produces the following: Error: lib/node_modules/jstz is a symlink to a path that may not exist after the build is completed (../../../work/jstz-2.0.0)
   • This is apparently because of changes to npm (CC @isuruf @minrk)
   • The fix is npm pack; npm install -g pkg-version.tgz
2. Because of (1), all PRs the bot is making against JS packages are broken.
3. The maintainers of most JS packages (@sannykr @cshaley) haven’t been responsive to the bots PRs or gitter (but it hasn’t been that long on gitter).
4. npm seems to install a copy of all dependencies for each package that is installed. Is there any way around this so that we can have real dependency chains on the graph in conda?
5. Related to (4), do we need to use npm to install JS packages at all? If all npm install is doing is shoving some files into a known directory and adding some symlinks, it seems like we could do that with conda-build as well. It is not as though there would be any penalty or collision with npm either, since npm would copy the package again anyway.

Anyway, some feedback, guidance, and discussion would be most welcome! CC @conda-forge/core

[scopatz]

If the original tarball were available as an environment variable

Yeah that would be nice

It’s technically possible (debian tries to do this), but I would strongly discourage any attempt to do this. It’s antithetical to how node and npm work,

Ok, good to know. We should avoid it then.

Like pip+distutils, it’s a dependency solver, build system, arbitrary code execution, config files, etc.

Yeah, so there is no reason to try to duplicate that effort.

I don’t think packaging node libraries with conda makes much sense. Only repackaging applications makes sense to me, because libraries installed globally aren’t importable (dependencies are always local)

This makes sense as a general rule to me as a conda-forge developer. As a conda-forge user it is more frustrating, because now to be able to develop an application I have to be using two package managers: conda and npm. It seems like npm’s model forces us into this mode where we have to use npm.

More precisely, I would like to have an environment.yml file that specifies all of the dependencies for a project so that anyone could execute conda env create -f environment.yml and be up and running. It seems like this may not be possible with JS packages.

[CJ-Wright]

@scopatz the bot has issued 38 PRs updating to the new JS syntax. Edit: (as clarification, that is all the filters picked up)