Open trivikr opened 15 hours ago
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?
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?
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.
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
.
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.
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 https://github.com/openjs-foundation/package-metadata-interoperability-collab-space/pull/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:
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