Closed Gudahtt closed 11 months ago
How should we handle the engines.node
field in package.json (currently ">=16.0.0") and the corresponding entry in constraints.pro?
% The package must specify a minimum Node version of 16.
gen_enforced_field(WorkspaceCwd, 'engines.node', '>=16.0.0')
How should we handle the
engines.node
field in package.json (currently ">=16.0.0") and the corresponding entry in constraints.pro?% The package must specify a minimum Node version of 16. gen_enforced_field(WorkspaceCwd, 'engines.node', '>=16.0.0')
The .nvmrc
file is only used for development. The development Node.js version doesn't have to be the minimum Node.js version we support, as long as the minimum Node.js version is tested properly in CI.
The engines
field specifies the range of compatible Node.js versions, whereas the .nvmrc
file is for the recommended version for contributors to use.
Previously we had kept nvmrc
pointed at the minimum compatible version, but this PR is an intentional departure from that. It's fairly common in other libraries to use a higher .nvmrc
than minimum already. My thinking was that we can rely upon CI to highlight version-specific incompatibilities, as CI should test at least one version of each supported major Node.js version.
We now use the LTS release for development rather than a fixed version. This makes it clear that we expect libraries to be updated to be compatible with the latest LTS release, and reduces the frequency of README/nvmrc updates needed.
Examples
No examples yet