Validation failure should be configurable

[GeoffreyBooth]

As a project author, I want to control what happens when the developer uses a package manager that fails validation, either because it’s the wrong package manager or a version that’s outside of the defined range:

• Should it warn, but then proceed
• Should it warn, and then prompt to download the newest supported version, and then try again in that version
• Should it error, and exit (like engines.strict)

Split off from #402.

[arcanis]

It can be configured:

COREPACK_ENABLE_STRICT can be set to 0 to prevent Corepack from throwing error if the package manager does not correspond to the one defined for the current project. This means that if a user is using the package manager specified in the current project, it will use the version specified by the project's packageManager field. But if the user is using other package manager different from the one specified for the current project, it will use the system-wide package manager version.

All configuration settings are set through the environment.

[GeoffreyBooth]

It should be configurable in package.json, like engines strict is. I can't control what environment variables my teammates have set.

[arcanis]

That seems fair, you're welcome to open a PR prototyping this. To be clear, this doesn't have anything to do with removing packageManager, though.

[GeoffreyBooth]

this doesn't have anything to do with removing packageManager, though.

It does unless your implementation involves adding several top-level fields to package.json. I think all Corepack configuration should be scoped under one field.