Yarn: Proposal: Save flag --ignore-engines to yarn.lock

[frank-dspeed]

Do you want to request a _feature_ or report a _bug_?
feature
What is the current behavior?
don't saving --ignore-engines
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
if --ignore-engines gets used onetime as flag it stays in yarn.lock and gets used on remove and add actions as default flag.
Please mention your node.js, yarn and operating system version.

[hutson]

@frank-dspeed what would be the value of saving --ignore-engines to a project's yarn.lock file be?

As a project maintainer, my project is very specific about the version of Node it supports. If users of yarn were to blanket ignore Node compatibly, I can only assume it will increase support load as people use incompatible versions of node, and not realize it.

[frank-dspeed]

@hbetts in a perfect world your right but as i sayed befor the Warning gets raised one time then the user will use --ignore-engines and so set that with having totally in mind what he does.

[email protected]:
  version "0.14.0"
  options "--ignore-engines"
  dependencies:
    babel-plugin-transform-inline-imports-commonjs "^1.0.0"
    babel-runtime "^6.0.0"
    bytes "^2.4.0"

the options fild gets only added to the packages that raised befor --ignore-engines warnings.

thats it.

[ghost]

@frank-dspeed thank you for the explanation.

My understanding of your proposal is that the option would only be applied to those packages you specifically installed with the flag. That seems reasonable. In those cases, I knowingly added those deps after ignore their engines constraint.

Also linking this issue to #1102

[frank-dspeed]

@hbetts this is really a blocking issue because some one who has one single package with ignore engines needed wants to install any other package he needs to add ignore engines again.

so it blocks all actions after that with a not needed warning and that.

[frank-dspeed]

@hbetts do you think that needs rfc or is that the expected behavior I think it should be expected that this gets saved and reused as all else it results in something that I would call a bug

[hutson]

@frank-dspeed while not being part of the Yarn team, I would say this issue provides a great opportunity to contribute an RFC.

An RFC will help capture the scenarios you've outlined here, and get buy-in from the community to make this change happen.

[frank-dspeed]

@hbetts its not importent for me to make that happen i already have a own yarn wrapper that does all right i only contribute that information back so that my frinds here can investigate if they like because thats a blocking issue for many yarn users they can't use any command without that flag

[benjie]

This sounds like a good solution to me. There's only one package in our build that has "incompatible" engines (where they've stated Node 6 rather than Node >= 6) and now we have to --ignore-engines on every install action. This is irritating, but worse: it reduces the usefulness of the engines check because we now blanket-ignore engines.

Specifically overriding the check on a per-package basis would allow us to maintain the utility of the check whilst also being able to opt into installing individual "false-incompatible" packages.

[vith]

I am in the same situation as @benjie

But it gets worse: there are other tools that run yarn and don't provide a way to pass extra args to yarn.

As a trivial example, ava --init can't be used.

I am definitely for some kind of persistence. The only reservation I have about persisting it in yarn.lock is that it may not be desired to share the ignore state to another environment where it's unnecessary.

Maybe it would be better to store it in ./node_modules/ alongside or within .yarn_integrity? That might have its own issues as the whole ./node_modules/ folder may be getting blown away as a matter of course.

I hesitate to suggest a new dotfile in the project root...

[benjie]

I definitely think the --ignore-engines flag should be checked into version control and shared between all users of the project - do you have an example @vith of when you'd want a per-package ---ignore-engines to apply locally but not, say, on production?

[frank-dspeed]

@benjie ignore engines need to happen on per package base no matter production dev it stays the same package greetings.

[frank-dspeed]

@vith to make your suggestion complet we shoukd add simply a ignoreEngines: register point in the log where we simply do

ignoreEngines: { nodeVersion: [package, package, package]}

then this is also per node version

[vith]

I was thinking along the lines that having each developer on a project set the persistent ignore for their own environment would be better so that if there was a real problem they'd each have more of a chance to realize it's due to the engine version that some other package tried to warn them about. Could also raise the chances that one of them makes a pull request to correct the engine range upstream ;)

But a sufficiently granular ignore set and a warning printed whenever it's effective would probably be fine too.

What about having the ignore be specific to the resolved dependency version? Upgrading the dependency seems like a good time to be forced to reconsider the potential issue you've been ignoring--and upstream's changes may have just turned a false incompatibility into a real incompatibility.

If it's also specific to your local engine version it could reduce the utility of sharing it. Maybe defaulting to a semver "compatible with" engine range would be OK?

But if a different developer bumps the dep version from an environment where there was no need to ignore, would the existing ignore be lost? If you were depending on it for production deployment that might be a problem.

[frank-dspeed]

@vith i agree so we should store ignore engine flag by node, package + version string in yarn.lock file

but i think then we are fine :+1:

alternate is .ignoreengines file or .yarnignore file

[gsklee]

@bestander close

Forcing developers to pass the --ignore-engines flag explicitly is by design; see this comment.