There are three ordinary ways to keep a repo's Node.js versions honest: read the files yourself during review, turn on engine-strict so an install under the wrong runtime fails, and look at what npm ls reports. Each answers a real question. None of them compares your Dockerfile, your workflow and your .nvmrc to each other, which is the question this checker is for.
| Question | Where to answer it |
|---|---|
Is the Node.js running this install inside engines.node? | engine-strict (an npm configuration setting). It checks the runtime doing the install, and nothing else. |
Do my installed dependencies declare an engines field this runtime does not meet? | npm ls and the install warnings. This checker does not read node_modules at all. |
Can the Node.js my Dockerfile or CI uses ever satisfy engines.node? | This checker. The runtime never meets the range until something runs under it. |
Do .nvmrc, the Dockerfile and CI name the same major? | This checker, or a careful read of every file. |
| Is anything pinned past its end-of-life date? | This checker, against a dated table. Reading the files tells you the number, not whether it is still supported. |
| Is anything uploaded? | Neither. This checker runs in your browser or reads local files only. |
Only for the Node.js that is running the install, and only as a warning unless engine-strict is turned on. It never looks at the version your Dockerfile or CI workflow will use, so a pin that can never satisfy engines.node is invisible until someone happens to run an install under that exact runtime.
It lists the dependency tree installed in node_modules, and it can report packages whose own engines field does not match the running Node.js. It does not read .nvmrc, the Dockerfile or any workflow file, and it cannot tell you that two of your own files name different majors.
For a small repo where all the versions sit in one or two files, reading them takes seconds and is perfectly adequate. It stops being reliable with a monorepo, several Dockerfiles, a workflow matrix that references matrix.node, and a range such as ^20.5 || >=22 that you have to evaluate in your head against a bare 20.
No. Keep engine-strict if you want installs to fail on an unsupported runtime, and keep reading the files in review. This tool covers the part neither does, which is comparing every declared version to every other one, and to a dated end-of-life table, in a single pass.