How to share code?

[sndrs]

To summarise a conversation that happened in chat:

• is there value in installing to package.json from github directly?
  • can target commitish urls tags/releases, commits, banches
• github packages
  • private packages are free
  • need github credential in ~/.npmrc to install anything from github packages
  • @guardian namespace clash with existing npmjs scope

[JamieB-gu]

We're currently taking the first option in liveblog-rendering. I like that this works with the lockfile, so it's locked down to a specific commit, as seen here. It also seems to be able to figure out transitive dependencies (as seen by the TypeScript requirement).

[SiAdcock]

Summary of discussion from CSIWG2:

• currently publish manually to npm
• is it a good fit? our code is mainly internal, not particularly intended for public

Alternatives

• install directly from git e.g. guardian/source#semver:^3.1
  • no npm credentials needed
  • how to handle publishing build step?
    • if we use a release branch that builds/tags, are we just recreating npm?
• github packages
  • private packages are free
  • we all have creds to make it work
  • but creds become required in all applications that install github packages
  • likely namespace clash with existing @guardian npmjs scope
• publish to npm from github as CD
  • should be able to use one credential for all guardian packages in github actions

[SiAdcock]

There's a lot to like about installing directly from GitHub, if it negates the need for a publish step for all our packages. We'd need to think about:

• when does the dist code get generated and where does it live? We can add assets to the release page (example) but how do they get uploaded?
• how do we make pre-releases available? Will every pre-release also get a release page?
• if GitHub goes down, nothing is installable. Edge case, maybe, but let's hope this doesn't happen during an outage incident that forces an emergency rollback 😅 Yarn and NPM at least have caching on the developer's local machine and CI box (I think)

We also lose:

• The ability to look up package / version info using NPM / Yarn's CLI tools
• NPM's security audit
• Useful tools that rely on NPM's CLI such as npm-check-updates. This goes for any custom tools that this group may build to make maintenance of packages easier in general

[JamieB-gu]

but how do they get uploaded

how do we make pre-releases available? Will every pre-release also get a release page?

It looks like there's a GitHub-created action to publish GitHub releases. It includes a prerelease flag.

Useful tools that rely on NPM's CLI

Doesn't this depend on whether the tool specifically makes use of the npm registry? Wouldn't we still use the npm CLI tool for managing these packages?

[SiAdcock]

It looks like there's a GitHub-created action to publish GitHub releases

Useful!

Doesn't this depend on whether the tool specifically makes use of the npm registry? Wouldn't we still use the npm CLI tool for managing these packages?

Yes, it's good to raise this distinction, I got a bit confused by mentioning NPM audit. We can use a subset of NPM's / Yarn's CLI, but not features that rely on the package existing on the NPM registry. For example we wouldn't be able to run the following commands against our packages since they wouldn't be available on the reigstry:

• npm view
• yarn outdated
• yarn upgrade

[JamieB-gu]

I've experimented with depending directly on a GitHub repo in this AR PR.

[JamieB-gu]

It looks like Dependabot supports bumping GitHub repo dependencies as well, which is handy 🙂.

[JamieB-gu]

I've done some further investigation into GitHub dependencies. Turns out you can specify semver ranges - these use the package.json and git tags in the target repository to pick the version. For an example see this PR.