CI/CD pipeline for a design system monorepo

WHAT THIS TESTS The interviewer wants a coherent pipeline design: which jobs run, how they depend on each other, how a monorepo scopes work, and crucially what deterministic logic decides the version bump and triggers publication.

A GOOD ANSWER COVERS Start with setup: checkout and install dependencies with a cached lockfile, and in a monorepo use the tool graph to determine affected packages so you only test and build what changed. Next, a fan-out of quality gates that run in parallel: lint, type-check, unit tests, and visual regression tests. These must all pass before the build stage compiles each package, producing ESM, types, and any CSS. Pull requests run all of the above but do not publish. The release logic lives on merge to the main branch: a release job inspects the changes to compute the version bump. Two common approaches are conventional commits parsed by semantic-release, where commit prefixes like fix, feat, and breaking map to patch, minor, and major, or Changesets, where contributors add intent files that aggregate into bumps. The job then updates versions and changelogs, creates a git tag and release, and publishes the affected packages to the registry with the proper credentials.

COMMON WRONG ANSWERS Publishing before tests pass risks shipping broken releases. Running every package on every commit wastes time in a large monorepo. Manually editing version numbers loses traceability and invites mistakes. Putting registry tokens in the wrong scope or logging them is a security risk. Forgetting to build before publish ships source instead of artifacts.

LIKELY FOLLOW-UPS How do conventional commits versus Changesets differ in practice? How do you publish only changed packages? How do you handle interdependent packages within the monorepo bumping together? How do you gate publish behind a protected branch and required checks? How do you do canary or pre-release versions?

ONE CONCRETE EXAMPLE A contributor merges a feat commit touching the Button package. CI runs affected lint, type-check, unit, and visual tests in parallel, builds Button, and the release job, seeing a feat, bumps the minor version, writes the changelog, tags the release, and publishes only that package to the registry, all without anyone editing a version by hand.