Skip to content

Add devEngines parameter to package.json #2721

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

sm17p
Copy link

@sm17p sm17p commented Jun 16, 2025

Description

The devEngines field is now supported by npm and corepack.

The goal is to streamline dev and CI/CD in accordance to openjs-foundation/package-metadata-interoperability-collab-space#27


Open to discussion

Maybe, once the below mentioned issues and PRs are resolved the project can migrate away from .nvmrc

Version Manager & CI/CD devEngines acceptance tracking:

  1. NVM - Add devEngines.runtime support for detecting the runtime environment nvm-sh/nvm#3595
  2. FNM - feat: support devEngines.runtime filed in package.json Schniz/fnm#1433
  3. Volta - Add support for the devEngines field volta-cli/volta#2050
  4. Github Action Node - feat(node-version-file): support parsing devEngines field actions/setup-node#1283

This is a part of maitaining interoperability in the future in
accordance to openjs-foundation/package-metadata-interoperability-collab-space#27, with the goal to streamline 
dev and CI/CD enviroments.
Copy link
Member

@Keavon Keavon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What benefit does this provide? I'm wary of any unsolicited changes to our dev tooling and CI, especially when it's working fine currently.

@sm17p
Copy link
Author

sm17p commented Jun 16, 2025

Firstly, this resolves the confusion of which version of npm to choose from for development.

Secondly, this won't break anything per se, the devEngines field is a way to define the runtime and package manager for developing a project. It actually acts as safegaurd, synonymous to what .nvmrc or shell.nix tries to accomplish.

Eventually, contributors will be relying on these fields to auto setup their environment once it gets adopted in the ecosystem.

@Keavon
Copy link
Member

Keavon commented Jun 18, 2025

I would prefer to wait a few years before this becomes an actual standard. From what I can tell, this is bleeding-edge, speculative, and not even implemented yet. Graphite's dev environment prescribes specific tools and doesn't intentionally support using yarn/pnpm/etc. anyways. Feel free to bring this up again once this becomes a widely adopted standard and including this solves an actively encountered pain point. Thanks.

@Keavon Keavon closed this Jun 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants