search

bloomberg / stricli

Build complex CLIs with type safety and no dependencies
https://bloomberg.github.io/stricli
Apache License 2.0
647 stars 7 forks source link

Check if @types/node is in sync with latest node version in the tutorial #30

Open ayyrickay opened 2 days ago

ayyrickay commented 2 days ago

Is your feature request related to a problem? Please describe. Using the latest version of Node, I tried installing the dependencies for the tutorial and understandably got the following error, because node types is behind the current version of node:

npm error code ETARGET
npm error notarget No matching version found for @types/node@23.x.
npm error notarget In most cases you or one of your dependencies are requesting
npm error notarget a package version that doesn't exist.
npm error A complete log of this run can be found in:

Describe the solution you'd like Changing the version of @types/node isn't particularly hard, but it's a bit annoying. It looks the tutorial installation tracks to the current version of node, but it would be great if it could be aware that node and node types can fall out of sync.

If there's a way to pull the latest node types and compare it to the installed version of node, that might provide sufficient information to handle this edge case. Something like:

node version <= node types latest ? use node version : use node types

Describe alternatives you've considered Just using the latest node types won't work, since I assume most developers aren't using the latest version. You really just need to see that case where the node types are behind the latest node version.

molisani commented 1 day ago

This is a case of Stricli trying to be too clever and getting bit ☹️. I always assumed that @types/node tracked Node major versions pretty closely, but that doesn't seem to be the case. For Node 22 it was released 24-Apr-2024 and the matching @types/node@22 wasn't released until 28-Jul-2024.

We definitely don't want the types to break right out of the gate for a new project, even if it's using a brand-new Node version, so this should definitely be fixed. I think your proposed solution is probably the most straightforward, but I'd prefer to not add a dependency on the user's npm registry if at all possible.