NPM packages live update

[jaudiger]

This PR refactors multiple project files to improve maintainability and standardize the implementation of live updates for NPM packages. It introduces a new utility, std.liveUpdateFromNpmPackages, replacing custom implementations of liveUpdate across various packages. Additionally, it consolidates version-matching logic into a shared constant and improves documentation for related utilities.

I took this opportunity to move all the expected live-update fields of a NPM package to extra:

export const project = {
  name: "aws_cdk",
  version: "2.1019.1",
  extra: {
    packageName: "aws-cdk",
  },
};

This is a bit different than the GitHub live update approach where the live-update fields are directly at the project root. But it makes sense here since we're talking about a repository URL.

Another difference between std.liveUpdateFromGithubReleases and std.liveUpdateFromNpmPackages comes from the options interface:

interface LiveUpdateFromGithubReleasesOptions {
  project: { version: string; repository: string };
  matchTag?: RegExp;
}

...

interface LiveUpdateFromNpmPackagesOptions {
  project: { version: string; extra: LiveUpdateFromNpmPackagesExtraOptions };
  matchVersion?: RegExp;
}

We have on one side a matchTag and on the other side a matchVersion, at the end we are talking about version. even when we look at the GitHub version/tag extraction we are using both terminologies:

      # Include GitHub Token if present (for increased rate limits)
      mut gh_headers = []
      if ($env.GITHUB_TOKEN? | default "") != "" {
        $gh_headers ++= [Authorization $'Bearer ($env.GITHUB_TOKEN)']
      }

      let tagName = http get --headers $gh_headers $'https://api.github.com/repos/($env.repoOwner)/($env.repoName)/releases/latest'
        | get tag_name

      let parsedTagName = $tagName | parse --regex $env.matchTag
      if ($parsedTagName | length) == 0 {
        error make { msg: $'Latest release tag ($tagName) did not match regex ($env.matchTag)' }
      }

      let version = $parsedTagName.0.version?
      if $version == null {
        error make { msg: $'Regex ($env.matchTag) did not include version when matching latest release tag ($tagName)' }
      }

      $env.project
        | from json
        | update version $version
        | to json

So, I also updated the name of the constant regex to be DEFAULT_LIVE_UDPATE_REGEX_VERSION_MATCH, but I didn't update the interface LiveUpdateFromGithubReleasesOptions, what do you think @kylewlacy should we uniformize all of that ?

[jaudiger]

Here is a quick run of the new std.liveUpdateFromNpmPackages in a native aarch64 VM 🚀

> brioche run -e liveUpdate -p packages/aws_cdk
Build finished, completed (no new jobs) in 5.99s
Running brioche-run
{
  "name": "aws_cdk",
  "version": "2.1019.1",
  "extra": {
    "packageName": "aws-cdk"
  }
}

[jaudiger]

To be merged after #716, and once the comments in the PR description are addressed

[kylewlacy]

LGTM!

Left some notes that might be good to do as a follow-up. I'm happy to merge as-is since 1) it makes the code better now and 2) I like the idea of testing it end-to-end during the next batch of live updates

[kylewlacy]

...any idea how useful this option will be? I don't think I've ever seen an NPM package that didn't use an x.y.z style version number (unlike git tags, where we already have several packages with weird tag names). I also haven't looked into NPM's rules to see what they allow for versions, I might try and do some research on this as a follow-up....

[jaudiger]

I didn't look neither for the NPM rules related to versioning schema. I was thinking it could be worth it to have it here, since it wasn't that complicated to re-use (since the code was already here from GitHub releases).

[jaudiger]

Well, I just quickly checked. NPM versioning is following the Semantic versioning Schema. So, the version cannot be prepended with v, but metadata could be added after Z

[jaudiger]

There is no need indeed to have the matchVersion field here if SemVer is respected.