Implement devEngines proposal from Package Metadata Interoperability Collab Space

[trivikr]

Is your feature request related to a problem? Please describe.

The Package Metadata Interoperability Collab Space has a consensus on devEngines proposal, and it was merged in openjs-foundation/package-metadata-interoperability-collab-space#27

https://github.com/npm/cli/releases/tag/v10.9.0 has an initial implementation of this spec, as the following is an example user experience:

$ test-devEngines> npm -v
10.9.0

$ test-devEngines> echo '{ "devEngines": { "packageManager": { "name": "yarn" } } }' > package.json

$ test-devEngines> npm install
npm error code EBADDEVENGINES
npm error EBADDEVENGINES The developer of this package has specified the following through devEngines
npm error EBADDEVENGINES Invalid engine "packageManager"
npm error EBADDEVENGINES Invalid name "yarn" does not match "npm" for "packageManager"
npm error EBADDEVENGINES {
npm error EBADDEVENGINES   current: { name: 'npm', version: '10.9.0' },
npm error EBADDEVENGINES   required: { name: 'yarn' }
npm error EBADDEVENGINES }

Although npm@10.9.0 implements this, the proposal doesn't explicitly mention whose responsibility it should be at the time of comment.

Describe the solution you'd like

Corepack implements devEngines proposal, so that existing users can continue using corepack.

Describe alternatives you've considered

Request my package manager to implement devEngines, and update my dependencies to that version

[aduh95]

Corepack implements devEngines proposal, so that existing users can continue using corepack.

Can you clarify what you mean by that? How/why would existing users not be able to continue using Corepack with devEngines?

[aduh95]

Corepack implements devEngines proposal, so that existing users can continue using corepack.

Can you clarify what you mean by that? How/why would existing users not be able to continue using Corepack with devEngines?

[trivikr]

Since devEngines is proposed by Package Metadata Interoperability Collab Space and implemented by npm, it appears to be a standard over existing packageManager field for an average developer in JS ecosystem. If that's the case, it means the ecosystem should move towards devEngines over long term.

I see it as CJS and ESM. Node.js adopted CJS module system in 2009 as there was no standard in JS ecosystem. But after ESM was standardized in ES2015, Node.js gradually added support for it and now the ecosystem is slowly moving towards ESM.

Similarly, there was no standard for defining ES files in package.json, and bundlers had adopted non-standard module field. When exports was standardized, the bundlers moved prioritizing it over module.

As a user of corepack in all my JavaScript projects, I expect corepack to also support devEngines and slowly phase out packageManager field. If that doesn't happen, there will be fragmentation in JS ecosystem. It'll be up to end users what they want to choose.

Since there are parallel discussions about removing corepack from Node.js and some unofficial polls indicated users will not install corepack though npm, another stance corepack can take is to move itself in maintenance mode and delegate the work of processing devEngines to individual package managers, like npm did in v10.8.0.

Irrespective of what step corepack takes, it's better to inform it's existing users on what's ahead.

[arcanis]

As a user of corepack in all my JavaScript projects, I expect corepack to also support devEngines and slowly phase out packageManager field

I strongly oppose any attempt to strip packageManager support, now or in the future. Whether Corepack supports devEngine or not I don't mind, but packageManager is already a de-facto standard, and I don't see anything to gain by removing the ability for projects already using it to rely on Corepack.

Similarly, there was no standard for defining ES files in package.json, and bundlers had adopted non-standard module field. When exports was standardized, the bundlers moved prioritizing it over module.

Key word being "prioritized". Support for module was never removed from any bundler because, just like here, it'd be a needless regression. Similarly, Node.js didn't deprecate main after introducing exports.

[trivikr]

Thanks for the response.

but packageManager is already a de-facto standard, and I don't see anything to gain by removing the ability for projects already using it to rely on Corepack.

Can we document this somewhere visible, like in README or corepack docs?

That way existing corepack users can continue to retain packageManager field if they decide to continue using corepack for managing their package managers, and choose to opt-out of specifying devEngines field in those projects.

---

I also prefer the short packageManager field for readability, over the object from devEngines proposal.
I'd also provided link to tens of thousands of package.json files from open source packages which contain packageManager field during the standardization discussions.

[trivikr]

At the time of comment, npm doesn't plan to support onFail=download specification of devEngines proposal.
npm/cli#8004

When corepack plans to implement devEngines, it would be awesome if the package manager version is downloaded automatically retaining the existing behavior.

I've checked with Package Metadata Interoperability Collab Space if they want to revisit onFail=download specification at
openjs-foundation/package-metadata-interoperability-collab-space#33