You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
Activity
arcanis commentedon Feb 27, 2024
It can be configured:
All configuration settings are set through the environment.
GeoffreyBooth commentedon Feb 27, 2024
It should be configurable in
package.json, like engines strict is. I can't control what environment variables my teammates have set.arcanis commentedon Feb 27, 2024
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 commentedon Feb 27, 2024
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.