refactor(tooling): add sanity ecosystem automation

[stipsan]

Hi 👋

As promised in sanity-io/next-sanity#5 (comment) here's a PR with the typical automation we use in our own libraries like next-sanity and @sanity/client 😄

I'll keep the PR description brief, but please feel free to ask questions in diff comments and I'll do my best to fill you in on the deets 🙇

TL;DR

The automation is for:

• Making releases to npm, github and updating/creating a CHANGELOG.md file with semantic-release.
• Use our preset for Renovatebot that keeps npm dependencies up to date, makes sure your peerDependencies let your consumers use the latest and notifies you if any .github/workflows/*.yml files have shared actions that can be updated.
• Run ESLint and Jest on PRs, as well as direct pushes to main.

Next steps a maintainer with admin powers should do

Renovatebot

For Renovate to be enabled you need to install the app. We recommend enabling it on one repository at a time since it will create onboarding PRs on repos without a renovate.json file by default which can blast your email inbox and be really noisy.
Once enabled you should see it create a GitHub issue like this: sanity-io/next-sanity#58
More information on the preset itself: https://github.com/sanity-io/renovate-presets/blob/main/ecosystem/README.md

Semantic Release

There's detailed information on our preset here: https://github.com/sanity-io/semantic-release-preset
Most importantly you'll need to create an NPM_PUBLISH_TOKEN with auth-only 2FA and add it to the repository secrets. And your npm package settings should set Publishing access to Require two-factor authentication or an automation or granular access token:

I noticed you're using a different git commit convention than ours. If you decide to adopt conventional commits then the next time you push a commit prefixed with fix: the bug is gone or feat: images pop even more then you can make a new release using this flow:

how.to.release.mov

If you wish to stick to your current convention then, as semantic release presets don't really support merging presets, it's best to replace the .releaserc.json file in this PR with a new .releaserc.cjs that have the contents of our preset: https://github.com/sanity-io/semantic-release-preset/blob/main/index.js
The commit preset used is defined at the top. Here's a list over available presets: https://github.com/semantic-release/commit-analyzer#options

Please note that our Release preset currently requires the ability to directly push commits to main

Specifically this means that all GitHub branch protection rules that require a PR to be made before you can push to main, can't be used:

As our preset will attempt to push a commit right after release that bumps the version in your package.json, adds another entry to the CHANGELOG.md (or creates the file if it doesn't already exist), and pushes it right away.

We're working on an updated preset that is compatible with PR based branch protection rules and will let you know when that's available 🙇

[stipsan]

Suggested change

	- run: pnpm release --dry-run --debug
	- run: pnpm release

After you've run this on the CI at least once, and verified that the output looks good and what it's intending to do, its predicted new version number and so on match your expectations, then it's a good time to remove --dry-run --debug

[lorenzodejong]

This is completely awesome! Thanks for the effort and all the clear documentation you provided.

I think all the code is fairly clear, however i was wondering what would happen during the first time i release. How can i determine a follow-up of the existing version number, will the commit-analyzer pick up the changes as a major version change initially?

I'll make sure to follow the steps you've provided and also change to pnpm, i'm already using that for all other projects so i like the change!

[stipsan]

I think all the code is fairly clear, however i was wondering what would happen during the first time i release. How can i determine a follow-up of the existing version number, will the commit-analyzer pick up the changes as a major version change initially?

The first time it runs it'll try and look at the package on npm as well as the git tags to determine what the current version is. I see that the current version is 6.0.0 but you don't have a v6.0.0 tag. semantic-release uses v prefixes for its tags. Create a v6.0.0 tag and it'll only look at commits since that tag when determining a new release.

Then, to make a new release, you use commits like fix: removed bug, the fix prefixes makes it a patch increment: 6.0.1. For 6.1.0 you'll need the feat: prefix. To bump major you can use either feat!: or fix!: :)

[lorenzodejong]

Great! I made sure to create a v6.0.0 tag to make sure the latest version is picked up correctly. Will get this PR integrated and try it out with the next release.

Thanks for the effort, and very nice we could get a collaboration going. Very cool to hear that this is used on the Sanity website, so i'd be happy to hear any feedback when using this library!

[github-actions]

🎉 This PR is included in version 6.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[lorenzodejong]

@stipsan wanted to let you know that we just ran the first release and it worked flawlessly! Thanks again for the effort 🚀

[stipsan]

@stipsan wanted to let you know that we just ran the first release and it worked flawlessly! Thanks again for the effort 🚀

Great to hear!! 🎉