Publishing Guide

Releases in this monorepo are automated with Changesets. You do not run npm publish by hand or bump versions manually — CI does both.

Published packages

The flow applies to every published workspace:

• @acronis-platform/ui-react — the next-generation React component library (primary)
• @acronis-platform/shadcn-uikit — the legacy library (ui-legacy)
• @acronis-platform/icons-react
• @acronis-platform/icons-sprite
• @acronis-platform/tokens-pd
• @acronis-platform/design-tokens
• @acronis-platform/design-assets

The apps/ and tools/ workspaces are private and never published (they are in .changeset/config.json's ignore list).

Prerequisites

• pnpm 10.27.0 — corepack enable or npm install -g pnpm@10.27.0
• Node 22.x

Publish credentials are handled by CI (OIDC Trusted Publishing); contributors do not need an npm token.

The release flow

1. Add a Changeset with your change

Any PR that changes the published surface of a published workspace (its src/, package.json, or build config) must include a Changeset:

pnpm changeset

The interactive prompt asks which packages changed, the bump type (patch / minor / major), and a one-line summary. It writes a markdown file under .changeset/. Commit that file alongside your code change.

Bump-type guidance:

• patch — bug fixes, internal refactors, dependency updates that don't affect consumers.
• minor — additive, backwards-compatible: new exports, new options, new props.
• major — breaking changes (removed exports, renamed identifiers, changed defaults).

Pure repo-tooling changes (root config, CI, context/, AGENTS.md, READMEs) do not need a Changeset.

2. Merge to main — the Version Packages PR

On merge to main, the Release workflow opens (or updates) a single "Version Packages" PR that aggregates all pending changesets. For each affected workspace it:

• bumps the package.json version,
• updates the workspace's CHANGELOG.md,
• deletes the consumed .changeset/*.md files.

Do not edit versions or delete changeset files by hand — Changesets owns them.

3. Merge the Version Packages PR — publish

Merging the Version Packages PR triggers the publish step, which runs changeset publish to push the bumped packages to npm (with provenance) and create a GitHub Release.

Authentication: OIDC and token bootstrap

Two workflows can publish; both attach build provenance.

• release.yml — OIDC Trusted Publishing (default). Runs on the Version Packages PR merge with no npm token: GitHub's OIDC token is exchanged for a short-lived npm credential. This is the normal path for packages that already exist on npm. Provenance validates each package's repository.url against https://github.com/acronis/uikit, so the repository field must be present.
• release-token.yml — token auth (manual bootstrap / fallback). Dispatched manually (workflow_dispatch) with a static automation token and a per-package skip-if-already-published guard. Use it for a package's first-ever publish (OIDC cannot bootstrap a package that doesn't exist on npm yet) or if OIDC config is missing. It deliberately does not publish shadcn-uikit, which stays on the OIDC path.

Putting a new package on the OIDC path (one-time)

1. Publish its first version via release-token.yml.
2. On npmjs.com → the package → Settings → Trusted Publisher → GitHub Actions, set organization acronis, repository uikit, workflow filename release.yml, environment blank.
3. Later versions then publish automatically through release.yml.

The binding is exact: renaming release.yml or the repo requires updating the npm config, or OIDC publishes will fail.

Root release scripts

These back the Release workflow — you rarely run them locally:

Usage after publishing

import '@acronis-platform/ui-react/styles';
import { Button, InputText, Switch } from '@acronis-platform/ui-react';

function App() {
  return <Button>Click me</Button>;
}

See also

• Versioning guide — bump types and Conventional Commits
• Changelog — where release notes live