Repository navigation
Implement devEngines proposal from Package Metadata Interoperability Collab Space #567
Description
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-working-group#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
Activity
[-]Is corepack going to implement devEngines proposal?[/-][+]Implement devEngines proposal from Package Metadata Interoperability Collab Space[/+]aduh95 commentedon Oct 8, 2024
Can you clarify what you mean by that? How/why would existing users not be able to continue using Corepack with devEngines?
aduh95 commentedon Oct 8, 2024
trivikr commentedon Oct 8, 2024
Since
devEnginesis proposed by Package Metadata Interoperability Collab Space and implemented by npm, it appears to be a standard over existingpackageManagerfield for an average developer in JS ecosystem. If that's the case, it means the ecosystem should move towardsdevEnginesover 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
modulefield. Whenexportswas standardized, the bundlers moved prioritizing it over module.As a user of corepack in all my JavaScript projects, I expect corepack to also support
devEnginesand slowly phase outpackageManagerfield. 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
devEnginesto 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 commentedon Oct 8, 2024
I strongly oppose any attempt to strip
packageManagersupport, now or in the future. Whether Corepack supportsdevEngineor not I don't mind, butpackageManageris 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.Key word being "prioritized". Support for
modulewas never removed from any bundler because, just like here, it'd be a needless regression. Similarly, Node.js didn't deprecatemainafter introducingexports.trivikr commentedon Oct 8, 2024
Thanks for the response.
Can we document this somewhere visible, like in README or corepack docs?
That way existing corepack users can continue to retain
packageManagerfield 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
packageManagerfield 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
packageManagerfield during the standardization discussions.trivikr commentedon Dec 30, 2024
At the time of comment, npm doesn't plan to support
onFail=downloadspecification ofdevEnginesproposal.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=downloadspecification atopenjs-foundation/package-metadata-interoperability-working-group#33