chore(ci): add a release-please configuration

[boneskull]

This adds configuration for releasing with the release-please action.

The way it works, in a nutshell:

• a commit with a conventional commits-valid message gets merged into main
• the action runs and creates one PR per package, with a new release ready to go, including updates to various CHANGELOGs, etc.
• another commit is merged
• the action either updates its existing PRs or creates new ones
• once a release PR is merged, the github release happens automatically
• the npm publish must be run manually by a human

[boneskull]

Current dependencies on/for this PR:

• main
  • PR chore: replace yarn with npm #629
    • PR fix(lavamoat): allow prefixed builtins #653
    • PR chore: normalize test config #643
      • PR feat(core): add a schema for policy files #620
    • PR chore: add commit hooks #632
    • PR chore: reconfigure lerna for releases #631
    • PR chore(ci): add a release-please configuration #630 👈
    • PR chore: consolidate eslint config #627
      • PR chore(deps): remove @metamask/eslint-config-nodejs #639
      • PR feat(allow-scripts): generate & ship typescript declarations #617

This comment was auto-generated by Graphite.

[boneskull]

Here's an example (not a monorepo): of a PR it would create: boneskull/midnight-smoker#238

And here's an example of what happens after you merge (with automatic publish to npm, which I manually configured): https://github.com/boneskull/midnight-smoker/actions/runs/5651165831/job/15308801239

Here's a GitHub Release it created and the associated update in the package's CHANGELOG.md

[boneskull]

FWIW, for now, once you get over the configuration hump, release-please is pretty nice. It remains to be seen how well it works on a monorepo, but it was designed with that in mind.

[boneskull]

note: I think we may need lerna after all here to publish manually. something like lerna publish from-package

this is done

[boneskull]

This PR now targets the "fiddle with Lerna" PR, as it's built on that foundation.

[leotm]

does this mean e.g. for a lavamoat-core core update

since 4 other pkgs depend on it

• ref: https://github.com/LavaMoat/LavaMoat/blob/main/RELEASE.md#release-dependency
• prev bumps: core/version 14.2.0 #610

we'll create 4 new separate-pull-requests to update them?
or these will be included in the original PR?

ref: https://lerna.js.org/docs/features/version-and-publish#from-package

[boneskull]

@leotm I'm not sure I understand the context of asking this in the lerna config

release-please is configured to create separate pull requests for each public workspace (package). we are in control of how or when those get merged, and are also in control of how or when those get finally published. but they all must be published at once!

so when we merge a change to lavamoat-core, a PR is created for that. once that PR is merged, then PRs will be created for each of the packages which depend on the new version of lavamoat-core. it would be a mistake to merge and publish those before publishing the new version of lavamoat-core since they will not exist in the registry. because lerna is configured to publish everything that needs publishing, we avoid this problem. so publishing in any other way besides this is just asking for trouble.

This may be why the default behavior of release-please is to not create separate pull requests, because it may become confusing. if it turns out we don't like separate PRs, I propose we simply...disable this behavior. 😄

cc @naugtur @legobeat @weizman just so you see this

[leotm]

some comments no blockers 👍