Setup release automation

[NullVoxPopuli]

This automation uses: release-plan via this npx boilerplate generator, which is a hybrid of the best parts of release-it and changesets, where:

• changelog entries are managed via labels (this list is a bit hard coded, but is sufficient)
• if a maintainer can merge, they can release
• no maintainer needs to have access to npm, nor push-access to main, they only need to be able to merge PRs

The one-time setup:

• an NPM_TOKEN
• permission for actions to create pull requests
• we'll want to enable "releases" in the settings for this repo
  • an initial git tag pushed (we can checkout the existingly published -- I've determined this to be 0.1.0 for signal-polyfill which was 2024-03-31T19:18:08.630Z, or matching commit: d811fce3c0d67529fe998f7eeaefd357f8369d01 (hopefully -- hard to tell for sure, tbh, but the commit used for publish cannot be newer than the publish timestamp)

Example:

• https://github.com/NullVoxPopuli/signal-utils/tree/main
• Feature PR: https://github.com/NullVoxPopuli/signal-utils/pull/9
  • labeled with enhancement
• that PR then merged
• The release preview workflow opened this PR
  • https://github.com/NullVoxPopuli/signal-utils/pull/8
• that PR is then merged
  • git tag created
  • github release created
  • npm release occurred

[ljharb]

I remain very concerned that a TC39 proposal is publishing a polyfill (that it will seem "official" - but TC39 does not publish official polyfills), and I strongly suggest you extract the package to a separate repo.

[littledan]

@ljharb Developing a polyfill has been very helpful for this proposal. If you want to adopt a rule in TC39, please propose this to committee for consideration, rather than expressing your concern to individual proposal authors in random patches (this PR does not introduce the polyfill).

[ljharb]

This proposal is in stage 0, and it's not until stage 2 that we usually discuss solutions, so I'm not sure why a polyfill would be necessary merely to describe a problem for us to investigate. In other words, a polyfill doesn't even make sense for a proposal that's this early in the stage process.

Additionally, as I have indeed discussed in plenary before, this was a committee policy for years, but by the time I realized another proposal had done this, there wasn't consensus to block it (and that proposal hasn't sought advancement since). There, however, also is not consensus for a proposal to have a published polyfill, and that certainly is likely to come up in plenary as it seeks advancements.

Since this proposal was developed in secret (which is confusing given your previous feedback to me on the globalThis proposal), it wouldn't have been possible to me to comment on the introduction of the polyfill - this is the first I've been made aware of it.

[littledan]

I hid comments on this topic, which is not related to the PR at hand. Please raise your process proposals separately from development in this repository, and I am happy to keep discussing there.

[littledan]

Thanks for creating this automation. I am not sure of the best strategy for maintaining this (unstable) polyfill, so I am not ready to land this patch yet.

[littledan]

We'll be developing this code in a different repo.