You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Finally, this blog post is handy and gives more information about using Changesets.
I added two commits (a change to Well, and a changeset) to demonstrate what this would look like when the GitHub bot detected a changeset. I'll drop those two commits before merging.
It's important to know that moving to Changesets shifts the onus of version determination toward a more intentional choice for contributors. Some could argue that the onus was already on the contributor as we used Conventional Commit messages to provide Lerna a way to infer the severity of a version increase. Now, instead of relying on Conventional Commit messages, the contributor will be asked to provide changesets as part of their PR process.
The workflow for this will look something like:
The contributor makes their changes and commits them.
Locally, the contributor runs yarn changeset and is asked in the CLI to choose which package(s) should be part of the changeset.
After the package(s) have been selected, the CLI will ask if the version increment should be a major, minor, or patch. Hitting enter in the CLI without making a choice will skip options with patch being the final option.
Next, the CLI will ask for a summary of the changes. This summary will be used in the changelog.md for the respective package(s). We're also using the @changesets/changelog-github package to provide additional GitHub-related context (pull request number + link, contributor information), and this info will show in the changelog.md for the package(s), as well.
Stage the change, commit the change, and push to the remote branch.
Motivation and context
How has this been tested?
Test case 1
Go here
Do this
Test case 2
Go here
Do this
Screenshots (if appropriate)
Types of changes
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)
If my change required a change to the documentation, I have updated the documentation in this pull request.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.
I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
Best practices
This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Lighthouse scores comparing the documentation site built from the PR ("Branch") to that of the production documentation site ("Latest") and the build currently on main ("Main"). Higher scores are better, but note that the SEO scores on Netlify URLs are artifically constrained to 0.92.
The reason will be displayed to describe this comment to others. Learn more.
A few things here, @Rajdeepc. I think my requests here all relate to what can actually be handled by Changesets and what might need to be updated to use Yarn.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This removes Lerna and replaces it with Changesets for handling package versioning and publishing (releases).
How and where has this been tested?
Please tag yourself on the tests you've marked complete to confirm the tests have been run by someone other than the author.
Validation steps
It's important to know that moving to Changesets shifts the onus of version determination toward a more intentional choice for contributors. Some could argue that the onus was already on the contributor as we used Conventional Commit messages to provide Lerna a way to infer the severity of a version increase. Now, instead of relying on Conventional Commit messages, the contributor will be asked to provide changesets as part of their PR process.
The workflow for this will look something like:
yarn changesetand is asked in the CLI to choose which package(s) should be part of the changeset.major,minor, orpatch. Hittingenterin the CLI without making a choice will skip options withpatchbeing the final option.changelog.mdfor the respective package(s). We're also using the@changesets/changelog-githubpackage to provide additional GitHub-related context (pull request number + link, contributor information), and this info will show in thechangelog.mdfor the package(s), as well.Motivation and context
How has this been tested?
Screenshots (if appropriate)
Types of changes
Checklist
Best practices
This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against
main.