feat: migrated to changesets from lerna

blunteshwar commented 3 weeks ago

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

Please read the Intro to Using Changesets documentation.
Please read the description of the Changesets GitHub bot.
Please read the documentation on adding a changeset.
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
1. Go here
2. Do this
[ ] Test case 2
1. Go here
2. 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)
[x] 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)

Checklist

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] If my change required a change to the documentation, I have updated the documentation in this pull request.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] 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.

github-actions[bot] commented 3 weeks ago

Branch preview

github-actions[bot] commented 3 weeks ago

Tachometer results

Currently, no packages are changed by this PR...

github-actions[bot] commented 3 weeks ago

Lighthouse scores

Category	Latest (report)	Main (report)	Branch (report)
Performance	0.99	0.94	0.95
Accessibility	1	1	1
Best Practices	1	1	1
SEO	1	0.92	0.92
PWA	1	1	1

What is this?

[Lighthouse](https://github.com/GoogleChrome/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.*

Transfer Size

Category	Latest	Main	Branch
Total	221.331 kB	210.849 kB	210.747 kB 🏆
Scripts	53.477 kB	48.504 kB	48.299 kB 🏆
Stylesheet	34.995 kB	30.409 kB	30.399 kB 🏆
Document	6.04 kB	5.321 kB	5.302 kB 🏆
Font	126.819 kB	126.615 kB 🏆	126.747 kB

Request Count

Category	Latest	Main	Branch
Total	45	45	45
Scripts	37	37	37
Stylesheet	5	5	5
Document	1	1	1
Font	2	2	2

blunteshwar commented 3 weeks ago

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/*"]],

Rajdeepc commented 3 weeks ago

@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?

castastrophe commented 3 weeks ago

@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?

No I think that approach makes the most sense.

adobe / spectrum-web-components