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.
Alternatively, After committing all the changes, the contributor can also leverage changeset bot to add the chanesets.
This bot will comment on PRs saying that either a user might need to add a changeset(note that PRs changing things like documentation generally don't need a changeset)or say that the PR is good and already has a changeset.
For more details: https://github.com/changesets/bot
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.
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.
I left one question here, @blunteshwar. An additional thought I had was if you need to account for the fixed version numbers that you publish at. Spectrum CSS doesn't use fixed versioning, so I didn't look into this, but you may need to!
Otherwise, the rest of the changes here look good. Are you going to be using the bot and the GitHub Action?
I left one question here, @blunteshwar. An additional thought I had was if you need to account for the fixed version numbers that you publish at. Spectrum CSS doesn't use fixed versioning, so I didn't look into this, but you may need to!
Otherwise, the rest of the changes here look good. Are you going to be using the bot and the GitHub Action?
Yes, we are probably gonna use bot and the GitHub Action
As far as fixed versioning is considered, I am taking care of that in congig.json by leveraging"fixed": [["@spectrum-web-components/*"]],
@blunteshwar Once you resolve the changes requested by @castastrophe ,lets run a shallow release from this branch to make sure the build scripts are working with changesets! @castastrophe Do you feel is there another parallel way to mock test this change?
@blunteshwar Once you resolve the changes requested by @castastrophe ,lets run a shallow release from this branch to make sure the build scripts are working with changesets! @castastrophe Do you feel is there another parallel way to mock test this change?
The reason will be displayed to describe this comment to others. Learn more.
Great work! And once again, kudos for the level of detail you put into the PR description. I have a few suggestions and questions here and then I'm happy to re-review.
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.
mizgaionutalexandru
force-pushed
the
main
branch
from
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.Alternatively, After committing all the changes, the contributor can also leverage changeset bot to add the chanesets.
This bot will comment on PRs saying that either a user might need to add a changeset(note that PRs changing things like documentation generally don't need a changeset)or say that the PR is good and already has a changeset.
For more details: https://github.com/changesets/bot
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.