Use more precise supported Node.js version ranges

[ericcornelissen]

Package(s)

@webmangler/benchmarking (v0.1.1), @webmangler/language-css (v0.1.31), @webmangler/language-html (v0.1.27), @webmangler/language-js (v0.1.29), @webmangler/language-utils (v0.1.28), @webmangler/mangler-css-classes (v0.1.24), @webmangler/mangler-css-variables (v0.1.24), @webmangler/mangler-html-attributes (v0.1.24), @webmangler/mangler-html-ids (v0.1.23), @webmangler/mangler-utils (v0.1.29), @webmangler/testing (v0.1.7), @webmangler/types (v0.1.27)

Description

Most packages (except @webmangler/core (v0.1.28) and @webmangler/cli (v0.1.11)) currently specify the open-ended version range >=12.16.0 as supported Node.js engines, example:

webmangler/packages/language-css/package.json

Lines 34 to 36 in 8e32df2

	"engines": {
	"node": ">=12.16.0"
	}

This should be changed to be more precise so that the supported Node.js engines are accurate and can reasonably be supported.

Progress

• @webmangler/benchmarking
• @webmangler/cli
• @webmangler/core
• @webmangler/language-css
• @webmangler/language-html
• @webmangler/language-js
• @webmangler/language-utils
• @webmangler/mangler-css-classes
• @webmangler/mangler-css-variables
• @webmangler/mangler-html-attributes
• @webmangler/mangler-html-ids
• @webmangler/mangler-utils
• @webmangler/testing (Drop explicit support for Sinon v13 and v14 #445)
• @webmangler/types

Motivation

Using an open version range (like >=12.16.0) implicitly means any future Node.js version is supported, including non-LTS releases of Node.js. Supporting non-LTS release is not necessarily desirable, and supporting all future versions of Node.js is not really possible.

Proposal

Like the core and cli, adopt a supported version range that is a conjunction of LTS releases, optionally with support for non-LTS releases on request.

When a new LTS release of Node.js is available, support will have to be added manually and a release created in order to officially provide support for the new Node.js version.

Alternatives

• Keep using open-ended version ranges.

  Not desirable per the main description.

• Use open-ended version ranges for the latest LTS, in (optional) conjunction with older releases.

  While not entirely unreasonable, I personally don't see much value in providing immediate support for a new LTS release at the risk of not actually being compatible with that new version.

Notes

• Relates to Add support for Node.js v20 #440
• As this concerns many packages, individual package labels won't be applied to this issue.