🔨 (changelog): Setup changeset

[valpinkman]

📝 Description

I've been going around, trying semantic-release but it's definitely not made with monorepo in mind. There is no internal package dependencies update and overall is a pain to make it work in a monorepo.

So back to our loyal changesets tool. It follows the same convention as Ledger Live. Whenever we make a change that impact userland, we should provide a changeset with a description of the change as well as the severity of our change.

I've also setup the official changesets/action right now, but only for the creation of the versioning PR. Basically what it does, whenever we merge on develop, if there is a new changeset, it will be applied to an evergreen branch and the changeset version will be applied, keeping an updated version of each package.
Whenever we want to make a release, we should merge this branch then use changeset publish. The changesets/action can also be used to automate the release and publishing to npm and github release, however this is outside of the scope of this PR and should be discussed with the team to decide on the wanted workflow.

The github action can be removed if it's not fulfilling our expectations or we need a more custom release process.

Example of PR here (the infos are wrong, the branches also, but it's just provided as example)

❓ Context

• JIRA or GitHub link: DSDK-66

✅ Checklist

Pull Requests must pass the CI and be code reviewed. Set as Draft if the PR is not ready.

• Covered by automatic tests.
• Impact of the changes:
  • new sripts added to the root package.json
    • pnpm changelog runs changeset add
    • pnpm bump runs changeset version
    • pnpm release runs changeset publish
    • pnpm commitcl runs pnpm changelog && pnpm commit
  • changeset basic setup
  • changeset/action setup in a version.yml workflow for github action (baseBranch in changesets and in workflow both target develop)

---

🧐 Checklist for the PR Reviewers

• The code aligns with the requirements described in the linked JIRA or GitHub issue.
• The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
• There are no undocumented trade-offs, technical debt, or maintainability issues.
• The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
• Any new dependencies have been justified and documented.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
device-sdk-ts-sample	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 15, 2024 4:37pm

[aussedatlo]

LGTM 👍