Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

Cannot seem to get npm 5 to not-touch my local modules #18062

Open
1 of 4 tasks
danfuzz opened this issue Aug 3, 2017 · 4 comments
Open
1 of 4 tasks

Cannot seem to get npm 5 to not-touch my local modules #18062

danfuzz opened this issue Aug 3, 2017 · 4 comments

Comments

@danfuzz
Copy link

danfuzz commented Aug 3, 2017

I'm opening this issue because:

  • npm is crashing.
  • npm is producing an incorrect install.
  • npm is doing something I don't understand.
  • Other (see below for feature requests):

What's going wrong?

I have a node_modules directory which is intended to contain a mix of locally-managed modules and modules which get installed via npm.

With npm v4, I named the local modules as filesystem paths and got them copied into node_modules.

With npm v5, I can no longer do that, so I tried just copying them in directly and not mentioning them at all in package.json. Unfortunately, this doesn't work either, because now npm removes the local modules (because they're not mentioned).

I also tried leaving the local modules in the package.json with a version of *, but npm still wants to check the registry for them. I don't want to say --prefer-offline, because with the non-local modules I do want it to check the registry.

I can work around this issue (and probably will), but from my perspective it would be ideal if npm supported this use case, one way or another.

How can the CLI team reproduce the problem?

$ mkdir florp
$ cd florp/
$ echo '{"name":"florp","version":"1.0.0"}' > package.json
$ mkdir -p node_modules/blort
$ echo '{"name":"blort","version":"1.0.0"}' > node_modules/blort/package.json
$ echo 'console.log("hello")' > node_modules/blort/index.js
$ npm install
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN florp@1.0.0 No description
npm WARN florp@1.0.0 No repository field.
npm WARN florp@1.0.0 No license field.

removed 1 package in 0.129s
$ ls # Where is my beautiful blort?
package.json  package-lock.json

supporting information:

What's the feature?

Have an option to make npm install not touch directories under node_modules that weren't installed by it.

Alternatively, have an option to make npm install simply not remove directories under node_modules.

Alternatively, have a way to name module dependencies in package.json that unambiguously means "this is a locally-managed module, so whatever version of it is already in node_modules is a-okay."

What problem is the feature intended to solve?

Using npm install in the face of a node_modules directory which contains a mix of locally-managed and registry-originated modules.

Is the absence of this feature blocking you or your team? If so, how?

Not blocking per se, but certainly making life difficult. I have to script around the issue, and it slows down and complexifies our build / deploy process.

Is this feature similar to an existing feature in another tool?

Not that I'm aware of.

Is this a feature you're prepared to implement, with support from the npm CLI team?

Maybe? I have very little experience with npm's innards.

@danfuzz
Copy link
Author

danfuzz commented Aug 3, 2017

ICYC this is the project I ran into the issue on: https://github.com/danfuzz/bayou

@norfish
Copy link

norfish commented Aug 4, 2017

same issue with you

danfuzz pushed a commit to danfuzz/bayou that referenced this issue Aug 8, 2017
Instead of directly `npm install`ing in the various subproject directories,
we now run it in its own empty directory, and then copy the results into the
subproduct's `node_modules`. This is done to keep npm v5 from messing with our
local modules.

Should npm ever change its behavior / get an option to play nice with
locally-managed modules, we can undo this cruft and go back to just doing
`npm install` more directly. See <npm/npm#18062>.
@danfuzz
Copy link
Author

danfuzz commented Aug 14, 2017

pangolin-has-a-sad

(original image credit: http://palawan-pangolin.blogspot.com/)

@danfuzz
Copy link
Author

danfuzz commented Jan 12, 2018

This is arguably a duplicate of #16853.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants