Release Procedure on Projects with Native Code using Optional Dependencies

[CMCDragonkai]

Specification

Several projects use native code now, and native code has to release different binaries for different platforms.

• js-db
• js-quic
• js-mdns

More projects are likely to follow.

However discovered in MatrixAI/js-quic#43 (comment), when doing this, because the optional dependencies are not released, the package-lock.json isn't fully updated.

This means after the CI does its release, upon doing a npm install, the package-lock.json will end up being changed.

A proposed solution is to structure such projects such that:

• Trigger CI to do a release of the binary packages e.g. @matrixai/quic-darwin-arm64
• Then update the version on development e.g. npm version major
• Then release the main package

However such a proposed solution ends up adding a significant delay to the release procedure as the developer has to wait for the CI to finish testing and building the binary packages.

Alternatively we can restructure the CI such that versioning becomes the responsibility of the CI, and instead we can push up special commits that trigger such things. The only issue with this is that versioning results in source code changes, which means the CI has to submit a PR back to the source code.

If we do the proper CI way, then the CI is a "bot" that ends up being capable of recursing changes back to the source code. This may be actually in fact the right way to do this, because we are thinking of having the CI generate docs which may result in pushing back to the source repo with an orphan branch.

This problem is currently not critical as downstream packages are not affected by package-lock.json files.

Additional context

• ci: merge staging to master js-quic#43 (comment)
• Continuous Benchmarking & Profiling TypeScript-Demo-Lib#54

Tasks

1. Figure out how to write a bot for the CI system to do this
2. Integrate the capabilities into MatrixAI-Bot
3. Test automated code PRs from the bot