I am the author of a library published on npm. In its package manifest file, an engines field contains the current LTS versions of the tools: [email protected] and npm 8.x.x since I use those versions for development and want all contributors to use the same version.

However, the library's distribution files are compiled into platform agnostic ES5 Javascript and can run with much lower versions of Node and npm. I am concerned that those consuming the package will get false warnings while installing the package when they work on older projects with lower versions of Node.

Which Node version should I specify in the package.json engines field? Is there another approach to solving this issue?

CodePudding user response：

Is npm package "engines" field intended for consumers of a package or developers?

engines field is used to check the specified node or npm version when installing the library, so, it is intended for consumers.

engines field is used when you use a relatively new runtime API or feature. If your code doesn't use a new API or feature, you can omit the engines field.

Note that it is used for only runtime APIs and features. Even if your code has an ESNEXT feature that doesn't supported, your user can use a transpiler to run the code. Or for example, if you used the new native fetch api in node 18, your user could install a fetch polyfill for node, like the node-fetch polyfill and still use your library.

These days the engines field is only for edge cases, where you will know you need it, when you need it.

There is even a Google Groups chat created by the founder of the NPM, Isaac Schlueter, to remove the engines field back in 2012. https://groups.google.com/g/nodejs/c/_ZggTOJQ2Rk