feat: introduce changesets for package publishing

[dnechay]

Issue tracking

#3424

Context behind the change

What's in

1. Refactored monorepo to have eslint and prettier per app/lib, so we have cleaner config files for these tools, ability to refactor them separately and can have some root-level scripts that are not affected by root-level lint/prettier. Also removed global jest config because it's not used (note: .gitignore changes in apps related to it because .ignore config of tools relies on it). Resulting configs are the same except for gcv app that has a small change in prettier related to trailingComma
2. Updated yarn version to latest stable in order to have some latest pieces that are necessary for publishing process (--json flag in yarn npm publish + fixed pre- version; some other items you can find in their changelog)
3. Added .local to .gitignore, so developers can have their .local folder with any stuff for local tests. Also added package.tgz to avoid potential commit of packed packages
4. Set npmPublishAccess to public by default since we publish our packages with that
5. Added prepack lifecycle hook to packages, so they are built automatically when publish is triggered. Also updated build command to have clean included to avoid potential garbage when doing builds on local (you can still rely on incremental TS builds if build by tsc, not via package.json scripts)
6. Actualized existing packages versions to what we have published in npm
7. Introduced changesets for version management + new GitHub Action to publish packages and create tags.

Drill down into the new publish process

The whole idea as same as in original issue, only version management relies on changesets tooling to simplify process for us.

Warning

We rely on changesets only to easily track changes and properly set new versions. We still do publishing relying on yarn workspaces we have and not on some fancy tooling provided by changesets only because under the hood it runs npm publish instead of yarn npm publish and because of that .yarnrc is not respected + it causes some other issues with published packages (e.g. like mentioned in this issue)

As part of a new process, engineers will have to create changeset file as part of their PR in case they have some changes for publishable packages. Before somebody opens a PR - they should run yarn changeset command in their branch from the repo root, select packages with changes and what version part (major, minor, patch) expected for bump according to their changes. This will generate a changeset file in .changeset folder that should be part of PR and also reviewed and merged to develop.

Let's loot at an example

I. Work on packages changes w/o worrying about exact version number, only about semver "weight"

1. Engineer A does a patch version change for sdk, then merges PR to develop. Nothing happens at this point
2. Engineer B does minor change for logger package and merges PR to develop. Nothing happens at this point
3. Engineer C changes both sdk and logger with patch, merges PR to develop. Nothing happens at this point

II. Pre-leases: do actual versions update

When we are ready to release, engineer that facilitates the release will need to open a new PR from develop to do a version bump. To do that - run yarn changeset version from the project root, commit changes and open a PR. Then we review that new versions are correct and merge it to develop

Note

In our example we will get a patch version change for sdk because all changes from last version are patch (i.e. 1.2.3 -> 1.2.4); For logger - it's going to be a minor version bump (i.e. 1.2.3 -> 1.3.0), because patch can be a part of minor version, but not vice-versa and all changes go in a batch for next release.

III. Publish packages with proper versions
There is a GitHub action that will automatically publish all packages that have new versions. It's triggered by pushed on main branch, so in order to release packages - just merge develop into main with new proper versions set up.
This action will also create git tags for published packages, such as @human-protocol/logger@1.1.0.

Important

Since we rely on yarn workspaces to publish packages and have proper package versions in package.json - yarn will resolve worksapce: links for us correctly while doing publishing in topological order, e.g. core will be published first, then sdk

How has this been tested?

• run yarn changeset to get package changes tracked
• run yarn changeset version to make sure versions updated correctly
• run publish command from GitHub Action to make sure packages are built, packed and can be published
• grabbed and example log file from publishing a synthetic package to personal registry and tested tagging script on it
• called yarn pack w/ and w/o SKIP_PREPACK to make sure prepack script works and SKIP_PREPACK is respected
• run at least on service (used RepO) that relies on all packages in docker and use healthcheck to verify it works

Release plan

1. Make sure that there are no pending packages for release (because once we get new flow merged to develop - new github action will be in place)
2. Merge this PR and release it separately in order to e2e test the new flow.

Potential risks; What to monitor; Rollback plan

• it might be blocking for some packages that have "pending" release (i.e. changes merged to develop, but not published yet)
• GitHub action is not tested, because we have to put it into main for it, so some things might be failing and we will have to fix them separately

What's next

• we might want to set up some GitHub action that will be releasing alpha/beta versions with tag next instead of latest from the specific branch you provide in input arguments
• as part of [SDK] spike: find a better way of publishing docs to GitBook #3483 , we can have another GitHub action that will be triggered on new tag creation and will sync changes to GitBook: it will need to create a new space for new sdk version + trigger sync from git tag
• discuss possibility to also commit artifacts of core package build using Git LFS, in order to speed up builds in CI/CD systems

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
human-app	Ready	Preview	Comment	Sep 5, 2025 0:28am
human-dashboard-frontend	Ready	Preview	Comment	Sep 5, 2025 0:28am
staking-dashboard	Ready	Preview	Comment	Sep 5, 2025 0:28am

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
faucet-frontend	Ignored	Preview		Sep 5, 2025 0:28am
faucet-server	Ignored	Preview		Sep 5, 2025 0:28am

[dnechay]

Let's hold the merge till we have all the pending items released

[Dzeranov]

👍 👍 👍

[dnechay]

Made a rebase from develop and added changesets for SDK updates mentioned in release PR, so we can test the whole publishing flow