Motivation ("The Why")

When packages do not specify a minimum supported Node version, some people may assume that the package supports any version of Node--or at least the ones that their currently-installed version does not error out on.

This can lead to semver hazards--a maintainer may inadvertently use a JavaScript builtin (as old as Array#map or as new as Object.hasOwn) or a Node standard library feature that is not supported across all versions of Node. This could be seen as a breaking change, and hence semver-major, but it is very hard for the maintainer to notice.

In order to use features that are not supported across all releases of Node in a semver-compatible way, authors must include the "engines" field in their package.json. Currently, however, few do so--probably because it is not included by default.

Example

See current semver hazard examples:

• v6.5.2 has a breaking change indutny/elliptic#314
• v4.7.1 broke node <= 6 dequelabs/axe-core#4127

How

Current Behaviour

npm init does not currently specify any minimum supported Node version.

Desired Behaviour

npm init should specify a reasonably recent Node version as the minimum supported one in the "engines" field, for some definition of "reasonably recent". The exact timeframe can be bikeshed over, but here are some ideas:

• The version of Node released some number of years ago (this can be longer than the EOL timeframe, since people are sometimes slow to upgrade Node--but do we want to encourage that?)
• The earliest LTS non-EOL version of Node
• The latest LTS EOL version of Node

Unanswered Questions / Further Work?

• Does npm currently provide a warning when you depend on a package whose minimum Node version is higher than the one you specify? Could it?
• Since the engines field consists of machine-readable semver, should the NPM registry require an engines bump to require a new major version number?
• Other runtimes, like bun and deno, now exist as well. An argument could be made that since those engines are likewise not mentioned in package.json, all of their versions must be supported. While their Node compatibility is still work-in-progress and not officially stable (AFAIK), there may come a time when they do reach parity with Node.
  • Should maintainers be required to keep up-to-date with all third-party runtimes and e.g. include "bun" and "deno" fields within "engines"? I see this as untenable, both because it is a lot to ask of maintainers and because npm would need an "official" list of all third-party runtimes.
  • They are the ones implementing APIs that Node is responsible for designing, so should it be their responsibility to map Node versions to the corresponding versions of their own runtimes?
  • ECMAScript features are another matter entirely. Third-party runtimes could support different subsets of new ECMAScript features from Node. Should they, again, be asked to map Node versions onto versions of their own runtime? Should a cross-runtime "JS support level" field be designed?