Follow-up with vendors to implement devEngines onFail=download

[trivikr]

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

The devEngines proposal provides the following options for onFail

The onFail field defines what should happen if validation fails:

• ignore: nothing.
• warn: print something and continue.
• error: print something and exit.
• download: remediate the validation failure by downloading the requested tool/version.

At the time of issue creation, only npm has implemented devEngines proposal and they're not planning to implement onFail=download because of security concern, as per npm/cli#8004 (comment)

pnpm, if they implement devEngines proposal, will likely follow npm's implementation as per pnpm/pnpm#8153 (comment)

Other projects, like yarn and corepack, haven't commented on whether they'll adopt devEngines.

It looks like onFail=download is not going to be implemented in the JavaScript ecosystem, assuming implementors follow npm.
I'm an existing user of corepack, and I love how it smoothly manages my package manager version behind the scenes.

Describe the solution you'd like

Follow-up with vendors (npm) to implement devEngines onFail=download in npm/cli#8004

This can include addressing the security concern they're worried about.

• The implementation PR does not have any details of the concern feat: devEngines npm/cli#7766 (comment)
• In corepack, one of the users had requested package manager to be downloaded from npm downloads package managers only from npm by default nodejs/corepack#495

An alternative is to remove onFail=download specification altogether

Describe alternatives you've considered

Explicitly download the devEngines packageManager version in all environments. This will require adding instructions for local environments, and adding explicit installs in CI setup. It's not as smooth as corepack.

Switch back to corepack, and it's packageManager field. Remove devEngines specification from package.json till corepack adds support for it.

[ljharb]

Indeed; I don't personally think download should have been part of it at all, but it was included solely because of corepack's unfortunate design decision to automate installation.

I think that although the DX of auto-installing a package manager is perceived to be better, it's actually much worse for security and education, and it would be far better for users to be instructed how to install the package manager themselves and have them run the command.

[GeoffreyBooth]

The download option was included to provide a way for Corepack to adopt the devEngines field while preserving its current behavior. If it chooses not to do so, then sure I guess we can remove it; but while it's still an open question I think we should wait and see what Corepack wants to do before making any changes.

The whole point of devEngines is to provide a field that all the package managers plus Corepack can standardize on. Last I looked the Corepack side was just waiting on someone to put up a PR to add support.

[jakebailey]

I frequently work on projects with totally different versions of each package manager, and corepack makes that seamless because it's managing those for me. If corepack is gone and devEngines is "the thing", and if package managers are not expected to be helpful and at least switch to the correct versions of themselves via this downloading method, how can I continue to work with more than one version of a package manager without "yet another package manager manager"?

pnpm v10 is able to do this (via manage-package-manager-versions); I don't think the linked comment implies anything about coping npm on this front, given the aforementioned option explicitly continues to make this scenario work.

[trivikr]

I frequently work on projects with totally different versions of each package manager, and corepack makes that seamless because it's managing those for me

I'm in the same boat. I explored devEngines with npm a chance in one of my projects, but noticed it requires me to download the npm version separately in local workspaces and CI which is additional work. I'll mostly switch back to corepack as its seamless.

The best path would be for corepack to support devEngines, which is requested at nodejs/corepack#567

[trivikr]

Closing since specification allows npm to error for onFail=download as called out in npm/cli#8004 (comment)

In the event of onFail: 'download', it would be the responsibility of the tool to determine what and how to download, perhaps by looking in the tool’s associated lockfile for a specific version and integrity hash. It could also be supported on a case-by-case basis, like perhaps Yarn and pnpm could support downloading a satisfactory version while npm would error.