Fix update-node-version script for non-existent @types/node version

[koesie10]

The Update Node version workflow is currently failing because a 20.18 version of @types/node does not exist even though VS Code is now using Node 20.18.0. This doesn't really matter for us since we can still use the 20.17 version of @types/node, but the script isn't checking for that.

This adds a check to the script that the version of @types/node we are requesting actually exists. If it doesn't, it will decrement the minor version (e.g. 20.18.0 becomes 20.17.0) and try that version instead. It will use the first existing version for the @types/node package (e.g. 20.17.* in this case).

[aeisenberg]

This looks right to me. Do you have an example of this running somewhere?

[koesie10]

This looks right to me. Do you have an example of this running somewhere?

I just ran the workflow manually which is available here. It created this PR.

[aeisenberg]

Thanks. Looks good.

This issue came about because we want to bump node to v20.18.0, but the latest typings is for v20.17.0. It's not a blocker or anything, but how will we know to upgrade the typings to v20.18.0 when that version finally comes out?

Perhaps there could be a workflow that runs on a schedule and attempts to reconcile any mismatch between the node version and the node typings. Or perhaps being off by a few minor versions is not a big enough deal to worry about.

[koesie10]

Perhaps there could be a workflow that runs on a schedule and attempts to reconcile any mismatch between the node version and the node typings. Or perhaps being off by a few minor versions is not a big enough deal to worry about.

Good point. I've changed this script to always make changes to all fields where the Node version is used (.nvmrc, engines.node, and devDependencies[@types/node]), regardless of what .nvmrc says. This should ensure that when a new version of @types/node is released a PR is created.

[aeisenberg]

Looks good. I have a question, but it is non-blocking.

[aeisenberg]

What's the benefit of using vite-node over ts-node?

[koesie10]

vite-node has better support for mixed ESM/CJS modules, so I switched all other scripts to use vite-node in 85abd9a. I noticed I forgot to update this use, so this just makes it consistent with the other scripts which are defined in package.json.