Full semver support

Motivation

After some feedback on the design from some potential users, it became clear that they need full semver support to consider using this tool.

Concern

If you've read the README, you'll know that I've been against overing full semver support for several reasons:

  1. Higher latency
  2. Additional complexity and more work
  3. Lack of trust in semver conventions

While there's not much I can do about 3, I can address latency by pre-caching and periodically fetching the list of available node versions. The list of node versions is available as a json and csv file at:

I'd like to cache this file locally, and only download it if its missing or the user specifies a version of node which not in the file. Perhaps offer another command to redownload the list of versions (ex: rn update).

Approach

Here's the algorithm to find resolve a NodeVersion parsed out of a package.json into a fully specified semver:

  • Start at index 0, the highest existing version
  • Check the current row to see if it satisfies the semver requirements, if so use that version and stop
  • If the current row is less than the desired semver, error out
  • Move on the next row

Dependencies

Here's the relevant crates to consider using: