An example of this is vinyl-fs, which means npm install -g gulp (to pick a higher profile dependant) will fail if you are using a non-release version of node.

Is there at least a command line flag to force engineStrict to be false, overriding the package.json?

--force will do that.. but I'm not sure what else it does.

This issue may be a duplicate of #6104, albeit from a less documentation centric perspective.

--no-engine-strict should do override a "engineStrict":"true" clause, although I'm confirming with @isaacs that it will override per-package configuration. If it doesn't work that way, it probably should. You're still going to get the warnings on prerelease versions, though, for the exact reasons that @rmg mentions. I think those warnings are appropriate, given that nightlies have no particular guarantees around fitness for purpose.

--no-engine-strict does not work with [email protected] AFAICT:

$ ~/Downloads/iojs-v1.0.3-nightly2015011850177fb13c-darwin-x64/bin/npm install --no-engine-strict [email protected]
npm ERR! Darwin 14.0.0
npm ERR! argv "/Users/ryan/Downloads/iojs-v1.0.3-nightly2015011850177fb13c-darwin-x64/bin/iojs" "/Users/ryan/Downloads/iojs-v1.0.3-nightly2015011850177fb13c-darwin-x64/bin/npm" "install" "--no-engine-strict" "[email protected]"
npm ERR! node v1.0.3-nightly2015011850177fb13c
npm ERR! npm  v2.2.0
npm ERR! code ENOTSUP

npm ERR! notsup Unsupported
npm ERR! notsup Not compatible with your version of node/npm: [email protected]
npm ERR! notsup Required: {"node":">= 0.10"}
npm ERR! notsup Actual:   {"npm":"2.2.0","node":"1.0.3-nightly2015011850177fb13c"}

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/ryan/tmp/npm-debug.log

As an aside, when the strictness of the engine dependency changes you end up with the engine dep failure completely masked by the created version range mismatch:

$ ~/Downloads/iojs-v1.0.3-nightly2015011850177fb13c-darwin-x64/bin/npm install --no-engine-strict vinyl-fs@^0.3.0
npm ERR! Darwin 14.0.0
npm ERR! argv "/Users/ryan/Downloads/iojs-v1.0.3-nightly2015011850177fb13c-darwin-x64/bin/iojs" "/Users/ryan/Downloads/iojs-v1.0.3-nightly2015011850177fb13c-darwin-x64/bin/npm" "install" "--no-engine-strict" "vinyl-fs@^0.3.0"
npm ERR! node v1.0.3-nightly2015011850177fb13c
npm ERR! npm  v2.2.0
npm ERR! code ETARGET

npm ERR! notarget No compatible version found: vinyl-fs@'>=0.3.0 <0.4.0'
npm ERR! notarget Valid install targets:
npm ERR! notarget ["0.0.1","0.0.2","0.1.0"]
npm ERR! notarget
npm ERR! notarget This is most likely not a problem with npm itself.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/ryan/tmp/npm-debug.log

What @othiym23 said would be true if engineStrict were a config value, and not a package.json field.

--no-engines-strict is not a thing, unfortunately.

Correction! --engine-strict IS a thing. It's a different thing from the engineStrict package.json field, though, and that is super confusing, so I'm not sure the best approach here.

My apologies to @othiym23, who was unfairly maligned just now.

After some in-air discussion, we've decided the best solution to this problem is to remove support for engineStrict from package.json. Control over whether to enforce the engines field belongs in the hands of package consumers, not producers. This is a breaking change (even though in your case, @rmg, it's an _un_breaking change), so we'll see if we can get it into npm@3. So a few weeks until you have a beta to play with?

@othiym23 I hadn't considered removing engineStrict an option. As a middle ground, would it make sense to instead change it to use a less strict form of semver? Could be done by stripping any prerelease and buildmeta components from node's version before doing the comparison.

Would still be breaking, but might be less breaking, as it would enforce >= 0.10 the way people use it while still preserving current behaviour for the other prefixes/ranges.

@rmg, that would just introduce yet another semver variation. Its complex enough, having a second flavour seems not an improvement.

@rmg what @sam-github said. I don't really think people have really had time to absorb the changes in semver@4 around prerelease versions, and it would be unhelpful (IMO) to muddy the waters even more.

@sam-github you're right, I take it back. Removing engineStrict is better than breaking the version comparison.

A use-at-your-own-risk workaround is npm config set node-version <x.y.z>.

Happily, as of npm@3 engineStrict is no longer honored in package.json and so these engine restrictions are now warnings. I'm closing this as resolved.