When a token build generates outputs for web, native apps and a design editor, why are token names recased per platform, and what can collide?
answer
- each platform's identifier rules
- path, not bare name
- join segments, then recase
- two sources, one output name
- fail the build, not the app
basics
~20 sEach platform has its own identifier rules and conventions, so the build derives every output name from the token's unique path. Distinct paths that differ only in case or separator placement can collapse into one name, and one token silently overwrites another.
solid answer
~40 sA token build starts from each token's **path** - its group names plus its own name - because names alone can repeat across groups while paths are unique in a file. It then joins the segments the way each platform expects: hyphenated lowercase names for web style variables, camel-cased constants or nested structures in native code, slash-separated groups in a design editor. The transform must also respect identifier rules, since many programming languages reject hyphens or a leading digit. The danger is that recasing is lossy: `invoice.total-amount` and `invoice-total.amount` both become `invoiceTotalAmount`, and names differing only in case collapse too, so one token silently overwrites the other. A good build detects collisions and fails, and documents the mapping so an engineer can find the same token on every platform.
go deeper
Recall that the same token has a different spelling per platform, derived from its path, and know how to find it on another platform.
Explain why paths are used, which identifier rules drive the transforms, and how separator or case differences collapse two tokens into one.
Show that the build must detect collisions per platform and fail with both source paths, and that fixes belong in the source rather than in exceptions.
Treat the mapping as part of the system's contract: predictable spelling across platforms is what lets cross-platform teams discuss one token.
## Why names change per platform A **token build** (sometimes called a token pipeline) reads one token source and writes an output for every consumer: style variables for the web, constants or resource entries for each native mobile platform, and a library or import file for the design editor. Each output lives in a different language with different **identifier rules** and **conventions**. A name that is idiomatic in a stylesheet is illegal or unidiomatic in native code, so the build cannot copy names verbatim; it derives them. ## From path to platform name The Design Tokens Community Group draft notes that token names are not unique within a file - the same name can appear in different groups - and advises translation tools to use each token's **path** instead, because paths are unique. The build splits the path into segments and joins them per platform. | Output | Joining convention | Path `ledger.amount.negative` becomes | |---|---|---| | Web style variables | lowercase, hyphen-joined | `ledger-amount-negative` | | Native constants, flat | camel-cased | `ledgerAmountNegative` | | Native constants, nested | one level per group | `Ledger.Amount.negative` | | Design editor library | slash-separated groups | `ledger/amount/negative` | The conventions in the table are common, not mandated; what matters is that each output's mapping is **mechanical** and documented. ## Identifier rules the transform must respect - **Separators.** Many programming languages do not allow hyphens in identifiers, so hyphenated segments are camel-cased or underscored for native code. - **Leading digits.** A scale step such as `100` cannot start an identifier in many languages, so a nested output needs a prefix or the step must be joined to its parent segment. - **Reserved words.** A segment such as `default` or `class` may be a keyword on some platform and needs escaping or renaming by rule. - **Case sensitivity.** The draft treats names as case-sensitive, but a recasing transform erases case differences. ## Collisions Recasing and joining are lossy functions: several inputs can map to one output. Typical collisions: 1. **Separator placement.** `invoice.total-amount` and `invoice-total.amount` both camel-case to `invoiceTotalAmount`. 2. **Case only.** `Total` and `total` become one identifier on any platform that normalises case. The draft itself warns that names differing only in case are likely to produce duplicate output where the second definition overwrites the first. 3. **Escaped segments.** Two different escapes of reserved words can meet the same result. In every case the build still succeeds, one token silently shadows the other, and an app renders the wrong value. The build should therefore compute every output name first, detect duplicates per platform, and **fail** with both source paths named. ## Keeping the mapping predictable - Apply the same transform to every token; no hand-written exceptions. - Document the mapping on the tokens page, with one worked example per platform, so a native engineer reading a web bug report can find `ledger-amount-negative` as `ledgerAmountNegative`. - Keep the source's description as a comment on the generated constant - the draft allows translation tools to render `$description` into code comments - so meaning travels with the name. - Search tools and documentation should accept any platform's spelling and show the others. ## An accounting example A small-business accounting product has tokens for ledger rows, invoice statuses and negative amounts. A contributor adds `invoice.status-overdue.text` next to the existing `invoice.status.overdue-text`. On the web both stay distinct because hyphens and dots produce different joins; in the native outputs both camel-case to `invoiceStatusOverdueText`. Without a collision check, the mobile apps would show whichever was written last. With the check, the build fails before release, and the naming conversation happens in review.
- Why should a token build derive platform names from token paths rather than token names?Because names can repeat in different groups, while a path - the group names plus the token name - is unique within a file. The Design Tokens Community Group draft advises translation tools to use paths for exactly this reason. Building from bare names would merge unrelated tokens that happen to share a name.
- How should a token build handle two tokens whose generated native names are identical?Fail the build and report both source paths. Picking one silently means an app renders a value nobody chose. The fix belongs in the source - renaming one token - rather than in a special-case rule for one platform, which would make the mapping unpredictable.
saying these in an interview costs you the question
- Every platform can use the same hyphenated names verbatim.
- Recasing is lossless, so collisions cannot happen.
- A collision should be resolved by keeping whichever token came last.
- Bare token names are unique, so paths are unnecessary.
- Each platform team should pick its own ad-hoc mapping.