Proposal: automating npm releases and Updates for samsam

[YasharF]

To reduce manual effort in publishing npm packages—especially when maintainers are tied up with life, work, etc - I propose using GitHub Actions, Dependabot, and related automation to streamline dependency updates and auto-publish releases to npm. Samsam is a good candidate for this, thanks to its consistently high code quality (e.g. 100% test/code coverage).

• Dependency Updates (Low Effort)
  We can just setup depandabot and add github workflows to automerge its PRs if the current tests pass.
  I'm happy to open a PR for this within a day or so if you like.

• Auto-Publishing to npm
  Assuming this is desired, we need a few key decisions:

  • Release Cadence: Should a release happen after every commit to main or on a regular schedule (e.g. every two weeks assuming there have been commits)?
  • Auto-release limited to depandabot changes: Only auto-publish if the changes since the last release come exclusively from Dependabot. These would be published as patch versions. Challenge: When regular PRs (human-authored) are merged, auto-publishing would stall - this limits automation benefits and could delay routine updates.
  • Versioning Strategy: Current commits mostly don’t use conventional commits (fix, feat, chore, etc.), so automatic semantic versioning wouldn't quite work. I am not sure what the best way forward is. Switching to using conventional commits? Adding some actions/workflows to ensure conventional commits? Adding some actions/workflows to keep non-patch changes out of main?

[fatso83]

This is great. We have talked about this in the Sinon team years ago. Using conventional commits is fine by me, but it will require a few rules I guess to enforce it. And PR's would probably need to be squashed into a single commit and/or frequently rebased when receiving feedback to avoid commits without fix-feat-chore?

[YasharF]

If you would want to go the conventional commit's route, we can potentially start with:

1. Add something like commitlint and run it thru the husky commit-msg hook to check the commits formatting.
2. Add something like semantic-pull-request github action as part of the pull request workflows - https://github.com/marketplace/actions/semantic-pull-request

I'm assuming the main branch already is restricted to require pull requests, etc.

[fatso83]

Seems like a good start. I do not have any experience with any projects I have worked on that employs this, only having a passing knowledge on what it means, not how to make it work in practice, so feel free to suggest any next steps.

[mroderick]

I'd be happy to adopt conventional commits (and even accept squashing over rebasing), if that means we can have more/better automation.

We should probably review the protection settings to prevent direct pushes from admins to prevent any mistakes that would bypass the validations and break some of the automations.

@YasharF, if you'd like to take lead on that one, that would be amazing! 👏