search

MetaMask / metamask-module-template

A simple template repository for starting new modules in the latest MetaMask fashion.
26 stars 23 forks source link

Use latest LTS release for development #222

Closed Gudahtt closed 11 months ago

Gudahtt commented 11 months ago

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

MajorLift commented 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')
Mrtenz commented 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')

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.

Gudahtt commented 11 months ago

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.