Repository navigation
Conversation
7 of 8 tasks
ehnruiz
marked this pull request as ready for review
October 11, 2026 09:09
…is emitted under Site Import turned root colour custom properties into framework tokens, which the framework emits under the normalised slug (`--brand---neutral--700` -> `--brand-neutral-700`), but left the imported `var()` references on the authored name, so they no longer resolved. The slug is now settled at plan time by `normalizeImportedColorTokens`, and every changed name is rewritten in the imported style rules and node inline styles before conflict detection, so the conflict step and the commit see the emitted name. Two names that normalise to the same slug both survive with a numeric suffix instead of one being dropped at commit. Token renames (normalisation and conflict renames) now also rename declarations of the variable in other rules, their priorities, and raw @Keyframes CSS, so a `.dark { --bg: ... }` override follows its token. Conflict rename targets skip the import's other token names and any custom property the imported CSS declares, and a colour custom rename is normalised like the slug it becomes. The rename helpers move from conflicts.ts into siteImport/varRefs.ts, which keeps conflicts.ts under the 700-line module budget. Fixes CoreBunch#615
…n is emitted under Site Import normalised a root `--font-*` variable at extraction (`--font-Heading` -> `font-heading`), and the store emits that form, but the imported `var(--font-Heading)` references kept the authored name and no longer resolved. Two authored names that normalise alike were deduped into one token, losing a font. Extraction now keeps the authored variable, and `normalizeImportedTokens` (new `siteImport/tokenNames.ts`) settles the emitted name of every imported colour and font token at plan time, in one pass against one set of claimed names, since both kinds share one CSS namespace. The `authored -> emitted` renames go through the existing var() and declaration rewrite, before conflict detection. `normalizeImportedColorTokens` is replaced by `normalizeImportedTokens`. Fixes CoreBunch#619
ehnruiz
force-pushed
the
fix/import-font-token-refs
branch
from
October 15, 2026 20:41
ce81f03 to
cec37f2
Compare
7 of 8 tasks
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #619. Site Import normalised a root
--font-*variable at extraction (normalizeFontTokenVariable:--font-Heading→font-heading), and the store emits that form, but the importedvar(--font-Heading)references kept the authored name and no longer resolved. Two authored names that normalise to the same variable (--font-Heading/--font-heading) were deduplicated into one token, so one font was lost.What changed:
fontTokens.ts).planCssnow deduplicates on it, so two names that normalise alike both reach the plan.normalizeImportedTokens(newsiteImport/tokenNames.ts) settles the emitted name of every imported colour and font token at plan time, as fix(siteImport): rewrite var() references to the slug a colour token is emitted under #618 does for colours:-2,-3, ... suffix when that is taken.--font--accent: #fffnext to--font-accent: "Inter", serif).authored → emittedrenames go through fix(siteImport): rewrite var() references to the slug a colour token is emitted under #618'srewriteImportVarRefs, so references, overrides in other rules (.dark { --font-Heading: … }), priorities and@keyframesfollow, before conflict detection.normalizeImportedColorTokens(added in fix(siteImport): rewrite var() references to the slug a colour token is emitted under #618) is replaced bynormalizeImportedTokens; no shim.Verification
bun run build(exit 0)bun test: 7070 pass, 1 fail. The failure isno-circular-dependencies, whose madge call hit the test's 15 s limit at load average ~20. Run on its own, it passes in 6.6 s.bun x madge --circular --ts-config tsconfig.json --extensions ts,tsx src serverexits 0 with "No circular dependency found!" across 2781 files. An earlier full run of this branch before the review fixes had 7068 pass, 0 fail.bun run lint(exit 0);tsc -p tsconfig.app.json --noEmit(exit 0)New tests fail without the fix and pass with it:
buildImportPlan): the issue's repro with a.darkoverride; two font names normalising alike both kept; a font name never taking a colour slug.normalizeImportedTokens): a colour never takes a font's name and a font never takes a colour's; fix(siteImport): rewrite var() references to the slug a colour token is emitted under #618's colour cases carried over.--font-Primaryagainst an existingfont-primarytoken is detected asfont-primary, auto-renamed tofont-primary-2, and its references follow.Checklist
docs/features/site-import.md).