Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

I help maintain Node.js, including Corepack. We’ve been searching for a way to provide interoperability with npm for Corepack users. npm has said that they won’t support Corepack or its packageManager field, but they’re open to the idea of a similar field, that has some different characteristics that npm considers vital: semver ranges, flexibility on what to do when validation fails, validation for both the package manager and the runtime. This has led to a standardization effort with the OpenJS Foundation to define a new field called devEngines: openjs-foundation/package-metadata-interoperability-working-group#15. npm is in the process of implementing support for it (other than the download sub-field).

Once npm adds support, the plan is to propose support for this field to Corepack, as it would contain all the same information as packageManager. Corepack would probably continue to support packageManager for backward compatibility, but the hope is that if npm, Corepack and other package managers all standardize on support for devEngines, then users could be assured that they can validate the package managers used for their projects.

Describe the solution you'd like

pnpm should also implement devEngines per openjs-foundation/package-metadata-interoperability-working-group#15, or as much of it as makes sense for pnpm (for example, I assume they might follow npm and ignore the download parts).

Describe the drawbacks of your solution

I understand if pnpm wants to wait and see npm go first, to see this actually ship; and then pnpm can copy or share code from npm.

I can’t promise that Corepack will definitely support devEngines, but the field’s whole purpose is to provide a configuration for both npm and Corepack to share so I expect it to happen.

Describe alternatives you've considered

Continue to support packageManager and its downsides, as shown by #8087.