chore: bump version and add CHANGELOG.md

[Nemikolh]

This PR introduces conventional-changelog to update automatically the CHANGELOG.md file based on the git history.

To create a new version in the changelog, one must do:

1. Update the version field in every package
2. Run pnpm changelog
3. Check the update to CHANGELOG.md and add shoutouts for our awesome external contributors 🥳
4. Open a PR
5. When the PR is merged and the package is published, update a new tag with:

git tag -a $VERSION $COMMIT_HASH -m "TutorialKit $VERSION"
git push --tags

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 000f128

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.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[d3lm]

Generally I like this but this generates only a single changelog (right?) and it'd be nice to have a changelog for all packages that we publish separately IMO. From this changelog it's not clear which feature or bug belongs to which package (unless I click on something I check myself). That's what I mentioned on Slack where a single changelog could work if we enforced scopes where the scope is the package so it's immediately clear where it belongs to.

[Nemikolh]

@d3lm Ah got it! Makes tons of sense 🙏

The conventional-changelog tool supports providing a --commit-path. With this flag I think we could run it once per package and have it update the changelog for only that package.

Do you think that's worth pursuing?

[d3lm]

Yea I think that would be cool! Having one changelog for every package we publish is prolly desirable and if we can use --commit-path to do that and run it once per every package that would be cool! Is it possible to include the type of the commit as well? Like feat etc. cause I do like that a lot in the Node.js changelog for instance cause I can quickly ignore some type of commits or look for commits of a specific type which I have done plenty of times for upgrading WebContainer.

[Nemikolh]

Is it possible to include the type of the commit as well?

From my observation, with the angular preset it seems that the tool uses the type to decide where the commit should be positioned in the CHANGELOG.md. So for instance, for feat, the commit ends up in the ## Features section:

## Features

<!-- A commit like "feat: foobar (#123)" seems to land here: -->
* foobar ([#123](<link PR>)) ([<commit hash>](<link commit>))

They seems to have support for other presets and the ability to have our own! 🤯

I can experiement with the presets and let you know what we get for each if you want! 😃

[d3lm]

I think if it's separated into separate sections then it should be fine 👍 Thanks for checking.

[SamVerschueren]

Looks great!