Add runtime and package manager checks to package.json

[clicktodev]

Description

Specify that the project requires Node.js version 20 or higher in the package.json file.
This is to discourage the usage of unsupported node releases during development.

The devEngines field aids engineers working on a codebase to all be using the same tooling.

You can specify a devEngines property in your package.json which will run before install, ci, and run commands.

Note: engines and devEngines differ in object shape. They also function very differently. engines is designed to alert the user when a dependency uses a differening npm or node version that the project it's being used in, whereas devEngines is used to alert people interacting with the source code of a project.

example:

> npm install

npm error code EBADDEVENGINES
npm error EBADDEVENGINES The developer of this package has specified the following through devEngines
npm error EBADDEVENGINES Invalid engine "runtime"
npm error EBADDEVENGINES Invalid semver version ">=25" does not match "v24.9.0" for "runtime"
npm error EBADDEVENGINES {
npm error EBADDEVENGINES   current: { name: 'node', version: 'v24.9.0' },
npm error EBADDEVENGINES   required: { name: 'node', version: '>=25' }
npm error EBADDEVENGINES }
npm error A complete log of this run can be found in: /Users/user/.npm/_logs/2025-12-17T11_21_50_617Z-debug-0.log

related #32158

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	355.56 84.51	355.56 84.51	+0 B +0 B
WebGPU	617.29 171.26	617.29 171.26	+0 B +0 B
WebGPU Nodes	615.89 171.01	615.89 171.01	+0 B +0 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	487.73 119.38	487.73 119.38	+0 B +0 B
WebGPU	688.74 187.04	688.74 187.04	+0 B +0 B
WebGPU Nodes	638.58 174.23	638.58 174.23	+0 B +0 B

[donmccurdy]

@clicktodev Thanks for the PR! I think the concerns from #32158 (comment) still apply. Node.js v20 is the oldest maintained release, and it's well understood that developers should not use unmaintained versions. By adding this field we'd presumably need to update it when v20 reaches end-of-life, and so on.

If there were some reason that a particular (active) Node.js version couldn't be used to contribute to three.js, and this was causing confusion/pain for developers, I'd certainly be open to adding a package.json field locking to supported versions. But it sounds like that's not the case, and all active Node.js versions work fine, so I'm not sure we should maintain such a field.