Added support for install --development #4791

wants to merge 2 commits into


None yet
5 participants

davglass commented Feb 27, 2014

This basically installs the packages that npm prune --production would remove.

Use case:

In a CI environment, I need to:

  • install production dependencies
  • analyze them and their size
  • display any warnings or helpful information
  • install the devDependencies
  • run their tests
  • prune --production
  • package for deployment

Now, I could do a --production install, then install without but I actually want to "switch" registries in between these. I only want "production" dependencies installed from a private local registry, but devDependencies can come from anywhere as they will be deleted with a prune. If a production dependency isn't in my local registry, it should 404 but doing a two pass install without scoping it would let it install anyway and then prune wouldn't work as I would expect.

I couldn't get all the tests to run on any of my dev machines from master or this branch, but I did add 7 passing tests for this functionality:

 ./node_modules/.bin/tap ./test/tap/install-development.js ./test/tap/install-production.js 
ok ./test/tap/install-development.js .................... 4/4
ok ./test/tap/install-production.js ..................... 3/3
total ................................................... 7/7

domenic commented Mar 1, 2014

This seems very niche, and adding a --development flag that is different from the --dev flag seems bad. So, I am -1...


davglass commented Mar 1, 2014

Well, --dev does way more than it actually should.

I went with --development to simulate NODE_ENV and it effectively "undoes" what npm prune --production does. That, and there is currently no other way to install prod deps and dev deps separately.

I talked to @isaacs about this today and he mentioned that he would possibly rather just fix --dev to only go one level down.


davglass commented Mar 4, 2014

Ping @isaacs, would you rather do this or have me fix --dev to only do one level down?


isaacs commented Mar 4, 2014

We should definitely not have --dev and --development, since that's confusing, but I'm not happy with what --dev does anyway, and neither are most users. (Though I know that @Raynos and some others like it, so removal isn't trivial or an obvious win.)

Why doesn't this work?

rm -rf node_modules # start fresh
npm install --production --registry=
# analyze etc
npm install # grab missing dev deps
npm test
npm prune --production

davglass commented Mar 4, 2014

The issue here is my whitelist, if a production dep is not in the whitelist it will 404 on the first install. When the second install happens it will install anyway, then prune --production won't remove it since it's already a installed and it's in the tree already.

What if we added a depth to --dev? If it's missing it's assumed it's top level only.


domenic commented Mar 4, 2014

What if we added a depth to --dev? If it's missing it's assumed it's top level only.

This sounds nice to me although I have not thought out how it composes with other uses of --depth etc. throughout the CLI.


davglass commented Mar 5, 2014

I tried simply adding a --depth 1 and it get's pretty hairy.

The other issue with that, is adding --dev still installs the the regular dependencies too. Which defeats the purpose of only installing the devDependencies.

othiym23 self-assigned this Sep 26, 2014


othiym23 commented Sep 26, 2014

I'm +1 on this, and part of the reason I like it is because it allows us to continue deprecating the giant footgun that is npm install --dev.


othiym23 commented Sep 26, 2014

Needs to run top-level lifecycle scripts as well.


othiym23 commented Sep 26, 2014

This needs to happen soonish for @davglass-related reasons.

othiym23 added this to the 2.2.0 milestone Sep 26, 2014

othiym23 added the next-minor label Oct 7, 2014

othiym23 removed this from the 2.2.0 milestone Oct 7, 2014


bengl commented May 19, 2015

How about --only [dependencies|devDependencies|...]?

(Yeah it duplicates --production, but that could be deprecated in the future.)


othiym23 commented Jul 22, 2015

I'm going to go ahead and close this in favor of #9024, which @bengl has helpfully put together for us. I still think getting some version of this landed is a good idea!

othiym23 closed this Jul 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment