Don't run prepublish on npm install --production. #4461

Closed
wants to merge 1 commit into
from

6 participants

@timoxley
npm member
  • npm install usually installs devDependencies+regular deps
  • npm install --production only installs non-devDependencies
  • npm install always runs prepublish scripts
  • prepublish scripts often rely on dev dependencies
  • Problem: npm install --production will try invoke missing devDependencies

This pull request prevents prepublish scripts from running when the --production flag is present.

Seems to make sense to me.

Although…
People tend to flip out when things change though so it may not be worth rocking the boat.

I wonder if "breaking" behaviour changes such as this should obey semver conventions, you could consider npm's command line it's api i.e. when will npm hit 2.x?

@domenic domenic and 1 other commented on an outdated diff Jan 10, 2014
test/tap/install-prepublish/package.json
@@ -0,0 +1,4 @@
+{ "name":"install-prepublish",
+ "version":"1.2.5",
+ "scripts": {"prepublish":"node -e 'process.kill(process.pid,\"SIGSEGV\")'"}}
@domenic
npm member
domenic added a line comment Jan 10, 2014

Maybe just log something the console instead of using a Unix-only thing? I know you copied this from another test, but that test was specifically about lifecycle signals.

@timoxley
npm member
timoxley added a line comment Jan 10, 2014

sure thing, that makes more sense.

@timoxley
npm member
timoxley added a line comment Jan 10, 2014

Fixed, rebased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@timoxley timoxley Don't run prepublish on npm install --production.
* npm install usually installs dev+regular deps
* npm install --production only installs dev deps
* npm install always runs prepublish
* prepublish scripts often rely on dev dependencies
* npm install --production will try invoke missing dependencies
de8f345
@domenic
npm member

LGTM, would like another maintainer to sign off first, e.g. @robertkowalski

@rlidwka

I'd say that this behaviour simply doesn't make sense. All right, I understand the need of 'prepublish' in dev mode (although it's a WAT from the first glance, and multiple issues confirm that). But when people accept that and learn to live with it, they will discover than in production mode it doesn't in fact happen. For this simple feature two WTFs is just too much.

I wonder if "breaking" behaviour changes such as this should obey semver conventions, you could consider npm's command line it's api i.e. when will npm hit 2.x?

Nobody cares about semver anyway, look how npm@1.3.19 broke stuff that supposed to be at least minor. :)

@robertkowalski
npm member

Uhm, really unsure about this PR. I like it, but this will break some weird deployment configurations I think, especially for people that do not publish their packages first and e.g. install them from git repositories during deployment?

@timoxley
npm member

@robertkowalski that's a point, is there a current strategy for introducing potentially breaking changes in npm? Perhaps such a change (and any other npm behaviour changes) only lived in npm on the unstable branch of node? Might be a good pattern to adopt so people get a chance to upgrade and npm has a diplomatic strategy for evolving beyond breaking changes.

@domenic
npm member

Sounds like we'll need @isaacs to make a decision here.

@jonathanong jonathanong referenced this pull request in reworkcss/rework Mar 17, 2014
Closed

Travis builds failing on make command #149

@isaacs
npm member

I think there's good intention here, and I was kinda sold on it at first, but it's just too eyebrow-raising. Having --production do different stuff entirely seems overly weird.

@isaacs isaacs closed this Apr 15, 2014
@othiym23 othiym23 added the lifecycle label Sep 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment