ci: use changesets for versioning and publishing

[andrii-bodnar]

Description

This PR replaces Lerna with Changesets for package versioning and changelog.

Types of changes

• Bugfix (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 not work as expected)
• Documentation update
• Examples update
• CI/CD

Fixes #2127

Checklist

• I have read the CONTRIBUTING and CODE_OF_CONDUCT docs
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

[vercel]

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

Name	Status	Preview	Updated (UTC)
js-lingui	✅ Ready (Inspect)	Visit Preview	Feb 13, 2025 9:43am

[github-actions]

size-limit report 📦

Path	Size
packages/core/dist/index.mjs	2.91 KB (0%)
packages/detect-locale/dist/index.mjs	618 B (0%)
packages/react/dist/index.mjs	1.35 KB (0%)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.38%. Comparing base (6bb8983) to head (6b07e1b).
Report is 174 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2182      +/-   ##
==========================================
- Coverage   77.05%   76.38%   -0.67%     
==========================================
  Files          84       87       +3     
  Lines        2157     2439     +282     
  Branches      555      637      +82     
==========================================
+ Hits         1662     1863     +201     
- Misses        382      460      +78     
- Partials      113      116       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[timofei-iatsenko]

Interesting how flow with changesets should look like where next merged into main.

Also thinking about implementing a "true", CD approach, when everything what merged to main automatically published on a "canary" channel. Like nextjs and similar projects doing.

I believe that next branch in general is not needed. We should use main as a trunk, and create branches for version to have an ability for hotfixes.

[timofei-iatsenko]

There should be "private: false" to not public private packages (jest-mocks for example)

[andrii-bodnar]

There is no such option in the configuration (schema.json), changesets should ignore private packages by default

[timofei-iatsenko]

https://github.com/changesets/changesets/blob/01c037c0462540196b5d3d0c0241d8752b465b4b/packages/config/schema.json#L78

privatePackages: false

[timofei-iatsenko]

i think this package version here could be reset to "0.0.0" to avoid confusion with public packages

[andrii-bodnar]

This one is updated by changesets (as well as its CHANGELOG) because it's listed in the devDependencies of some packages and cannot be ignored even if it is private. Yes, it's strange and unexpected.

It's a known issue mentioned here - changesets/changesets#1158

[timofei-iatsenko]

It could be ignored, i'm using changeset on my full-time job and we have plenty of the private packages and they don't get bumped

[timofei-iatsenko]

Probably need some explanation here, you can tell changeset to ignore private packages in two ways:

• Remove the version field from package json. - This is a recomended way by theirs maintainers and it was there since the begining. Changeset will not bump packages which doesn't have a version field. However, this doesn't play well with a "workspace:" protocol in yarn / pnpm. They will fail publishing a package if encounter a link to a package without version field.
• privatePackages: false this will disable changeset bump for packages with "private": true

[andrii-bodnar]

As for canary releases, I think it's overcomplicated for the Lingui case. The flow with main as stable and next as unstable future major release works pretty well and there is no need to publish every merge to the main branch. Most of the time, we simply don't have a next branch at all.

Interesting how flow with changesets should look like where next merged into main.

Good question. Probably this could cause problems and the first stable release of the new major version should be done manually to make sure everything is ready for release. I am also still thinking about a separate workflow for publishing that should be triggered manually. This gives more control over the process.

[timofei-iatsenko]

As for canary releases, I think it's overcomplicated for the Lingui case. The flow with main as stable and next as unstable future major release works pretty well and there is no need to publish every merge to the main branch. Most of the time, we simply don't have a next branch at all.

This is debatable, but I don’t think it’s complicated. In fact, it’s even simpler because it removes the need for branching entirely—it’s a shift in how we think about releases.

The next branch actually introduces a problem: once it’s created, you now have two branches to maintain and keep in sync whenever something lands in main. The real issue here is the branching topology.

Instead, a more streamlined approach could be:

• main → Always has the latest changes, including breaking ones.
• v5 → A snapshot of the repo when we decided to start the next major version.
• v4, v3, etc. → Older stable versions.

With this model, if a hotfix is needed for the latest stable version, you apply it there and cherry-pick it to main if necessary—without having to constantly sync next with main.

This also benefits contributors, as they always work with the latest changes by default, without needing to be explicitly directed to a next branch.

And as for canary releases, it's really just about automation—fresh changes are published automatically so contributors and early adopters can start using them right away.