Repository navigation
Switch to devEngines.packageManager in "When Authoring Packages" #835
Description
Hi, thanks for Corepack! It's been a useful tool to maintain environments across student machines.
In the When Authoring Packages section of the readme, the instructions start with suggesting using a top-level packageManager field of package.json:
Set your package's manager with the
packageManagerfield inpackage.json:{ "packageManager": "yarn@3.2.3+sha224.953c8233f7a92884eee2de69a1b92d1f2ec1655e66d08071ba9a02fa" }
Further down in the readme, there is a subsection devEngines.packageManager, which shifts to describing the devEngines.packageManager field:
devEngines.packageManagerWhen a
devEngines.packageManagerfield is defined, and is an object containing
a"name"field (can also optionally containversionandonFailfields),
Corepack will use it to validate you're using a compatible package manager.
devEngines.packageManager has some level of support in:
- npm v10+ https://docs.npmjs.com/cli/v10/configuring-npm/package-json#devengines
- Yarn via Corepack
- pnpm https://pnpm.io/package_json#devenginespackagemanager
My suggestion is regarding that first starting section of the readme on the top-level packageManager field:
- replace the
packageManagerdocs withdevEngines.packageManagerdocs (without the extra subsection) - and then either:
- drop the
packageManagerdocs - deprioritize the
packageManagerdocs by moving them to the end and describing it as "Legacy" or similar
- drop the
Activity
arcanis commentedon May 14, 2026
No, the
packageManagerfield is the recommended universal field,devEnginesis a separate one that isn't supported by all tooling.Yarn doesn't support the
packageManagerand has no plan to do it (yarn set versionsets thepackageManagerfield and has no special support for whetherdevEnginesis set).karlhorky commentedon May 14, 2026
Ok interesting, can you provide some references from this? Or do you only mean in terms of Corepack, not the wider package manager / interop community?
From my research it seems like the top-level
packageManagerfield was considered legacy / insufficient:npm
package.jsondocs do not mentionpackageManagerat all (probably since npm won't support it)pnpm
package.jsondocs mention "legacy" and hints at moving projects off of it:@GeoffreyBooth wrote about
packageManagerlimitations inpackageManagerfield is too limited #402:@benmccann wrote about lack of ranges in
package-manager-strictenforcement in pnpm 9 is a massive headache pnpm/pnpm#8087:arcanis commentedon May 14, 2026
I wrote Corepack and implemented support for
packageManager. It's widely used in the ecosystem by Corepack and other tools. I think if you search on GH you'll find significantly more hits than fordevEngines.The
devEngineswas designed by the "package maintenance group" whose members notably don't include package manager authors outside of active and former npm collaborators. I'm sure they have the best intentions, but I find their approach of package management differing a bit from what I feel comfortable with.More opportunities for unlocked versions and supply chain attacks didn't seem a great idea to me then and it doesn't seem a great idea now. The
packageManagerfield not supporting ranges is a feature, not a bug.RaffaeleCanale commentedon Jul 1, 2026
For PNPM, it appears it uses the
pnpm-lock.yamlto then pin the exact version of the package manager (including the checksum), making it behave essentially like any locked dependency. Though I admit I haven't researched whether yarn and npm do the same.But, and correct me if I'm wrong, it is not used by the package managers themselves (pnpm, npm, yarn). This for me was the biggest deal breaker. If we lived in a world where every dev and machine was setup with corepack, then
packageManagerwould be perfect. But some CIs provide node images that have pnpm setup without corepack, or devs may choose to install pnpm without corepack. In those cases,packageManagergives a false sense of security (I was a bit disillusioned when I eventually realized our CI was actually not using a pinned package manager version despite having thepackageManagerfield).That's why IMO, I would rather see this being a responsibility of the package managers themselves, not of corepack (which is an optional tool).
But that's just my feedback from a user perspective.