An accounting product's web app and two native apps show different values for the same tokens because teams copy values by hand; how would you set up build-time generation and publishing to keep them in sync?
answer
- copies drift, generated outputs don't
- one commit, every output
- generated files are never edited
- release all outputs together
- descriptions travel as comments
basics
~20 sGenerate every platform's output from one source in one build on each accepted change, publish all outputs together under one release identifier through each platform's normal dependency channel, and fail CI when generated files are hand-edited or stale.
solid answer
~50 sThe root cause is that each platform holds a hand-made copy, so drift is inevitable. I would make one build job, triggered by every accepted change to the token source, validate the source and emit web, native and design-editor outputs from the same commit. Outputs are artefacts: each file says it is generated, and a CI check regenerates them and fails on any difference, so hand edits cannot survive. All outputs are published together under one release identifier, with one changelog, through each platform's normal dependency channel, so apps adopt tokens like any other dependency and can say which release they use. The build carries descriptions and deprecation notes into code comments so engineers see intent in their editor. A CI check can also compare resolved values across outputs for a sample of tokens. Version-numbering rules and design-editor sync sit alongside, not inside, this setup.
go deeper
Recall that platform token files are generated from one source and must never be edited by hand.
Explain the build steps - validate, transform, emit, test - and why all outputs come from the same commit.
Show how you enforce generation with a regeneration check, publish all outputs under one release identifier and move every app off its copied files.
Frame the build as the organisation's consistency mechanism: who owns it, how requests for new outputs are handled, and what adoption pace to expect.
## Diagnosing the drift A small-business accounting product has a web app and two native mobile apps. The overdue-invoice color, the ledger row spacing and the negative-amount text color differ between them, even though a token source exists. The cause is a **copy step**: each platform team copied values from the source into their own files at some point and has edited them since. Any process that relies on people copying values will drift; the fix is to make the platform files a **generated output** that nobody writes by hand. ## The build One **token build** job, triggered by every accepted change to the source, does the whole job: 1. **Validate** the source: every token typed, every reference resolvable, no cycles, no name collisions after per-platform recasing. 2. **Transform** per platform: convert units, recase names, and resolve or preserve references according to each output's policy. 3. **Emit** every output - web style variables and script constants, a resource set for each native platform, an import for the design editor - from the **same commit**. 4. **Test** the outputs: snapshot representative tokens and compare resolved values across outputs for a sample, so a platform-specific transform bug shows up as a mismatch. ## Generated, never edited - Each generated file begins with a header saying it is generated and naming the source it came from. - A CI check regenerates outputs from the committed source and fails if the result differs from what is committed or published - catching both hand edits and forgotten regeneration. - Consumers that need something the build does not produce ask for a transform, instead of patching output files. - Descriptions and deprecation notes are rendered as comments on generated constants; the Design Tokens Community Group draft explicitly allows translation tools to do this, so intent and warnings reach engineers inside their editors. ## Publishing | Output | Typical form | Channel | |---|---|---| | Web | style variables plus script constants | the web platform's package registry | | Native platform A | resource and constants files | that platform's dependency manager | | Native platform B | resource and constants files | that platform's dependency manager | | Design editor | a library or import file | the editor's shared library | All outputs of one build share **one release identifier** and **one changelog**. That lets any team answer 'which tokens are we on?' and lets a bug report say 'web on release N, app on release N minus 2', which is often the whole diagnosis. How release numbers communicate breaking changes, and how renamed or removed tokens are phased out, are separate disciplines covered with token change management. ## Adoption across teams - Apps take token releases through their usual dependency updates, so a token change moves through each app's normal review and testing. - Automated update requests keep apps from falling far behind without forcing an instant upgrade. - The old copied files are deleted in each app when it first adopts the package, so there is only one place a value can come from. ## What stays out of scope The design editor's library is one output of the build, but keeping it matched with the component library and auditing design-code drift is its own practice. Likewise, the build is not the place to decide token names or tiers; it faithfully transforms what the source says. ## Why interviewers ask it The question tests whether a candidate sees the build as **the** mechanism of consistency rather than a convenience. Strong answers remove the copy step entirely, make hand edits impossible to keep, publish all platforms in lockstep and give every consumer a way to name the release they are on.
- Why publish all outputs of a design token build under one release identifier?So one identifier means the same values on every platform. Teams can say which token release they are on, support can compare a web bug with an app bug by release, and a changelog entry applies to all outputs at once. Separate per-platform numbering would make it hard to tell whether two apps even disagree.
- A native team needs a token format the design token build does not produce; what should they do?Request a new transform or output in the build, not a hand-maintained copy. A patched or hand-written file reintroduces exactly the drift the build removed, and the regeneration check would flag it. Adding the transform once serves every future release and every other team on that platform.
saying these in an interview costs you the question
- Platform teams can keep hand-editing generated files as long as they are careful.
- Each platform should run its own token build on its own schedule.
- Publishing outputs separately per platform keeps them in sync.
- Copying values from the documentation site is good enough to stay in sync.
- A token build only needs to run before major releases.