strict engines check is inconsistent with npm

[adanilev]

Do you want to request a feature or report a bug?

• bug (feature?)

What is the current behavior?

• Versions of node specified in the engines field in package.json are strictly enforced
• npm behaviour is different, they allow the packages to be installed
• This has resulted in non-breaking changes for npm users being breaking changes for yarn users. See: package.json engines, yarn, and semver rules hapijs/hapi#3859
• Workaround is to use ignore engines in .yarnrc or use yarn --ignore-engines

If the current behavior is a bug, please provide the steps to reproduce.

• Clone this repo: https://github.com/adanilev/test-engine-checks
• Run yarn and observe output
• Run npm i and observe output
• See the engines section in boom's package.json

What is the expected behavior?

• That yarn applies the same level of strictness as npm by default. Perhaps add an option for strict checks and give a warning by default?

Please mention your node.js, yarn and operating system version.

• macOS 10.13.6
• yarn 1.9.4
• npm 6.4.1
• node v8.10.0

[arcanis]

This behavior has been in Yarn since its inception (and was actually sold as an improvement over npm). I'm not convinced changing it now would be a good idea.

[pward123]

My hope is that most package authors would accurately set the engines field based on the node calls they're making or at least update the minor semver for an engines change. However, some authors only CI test with the latest patch of each major revision of node and don't want to update semver for what is essentially a toolchain change.

Yarn users currently have the options of toss an error on any mismatch or completely ignore all engine values. It would be nice if we had a middle ground here. Either the ability to ignore engines for a specific module or change engine errors to warnings.

[pward123]

Just to clarify, in my own case, I am currently working through some CI challenges that prevent me from properly using yarn.lock. Once I get these CI challenges resolved, I don't expect this issue to be a problem.

We already use fixed version numbers in our package.json, but these issues are bleeding in from nested dependencies.

I've tried using the resolutions feature to work around this, but I have dependencies using different major versions of the same package which causes problems.

[pward123]

Looks like the soft option was already discussed and discarded here yarnpkg/rfcs#69 (comment)

[rally25rs]

This is by design. Use --ignore-engines to ignore the engines check.