build(ui-scripts): fix changed token/theme parsing to follow the new design token structure

[HerrTopi]

Summary

Brings InstUI's token build in line with the new design-token structure and adds runtime support for color modifiers.

Token parsing fixes (ui-scripts)

• Token references in the new structure already carry the semantic. prefix, so formatReference no longer prepends semantics.. Param name in generated component files renamed semantics → semantic to match.
• Multi-file semantic token sets now merge via mergeDeep instead of shallow spread, so nested keys from different files no longer clobber each other. mergeDeep is inlined into generateSemantics.ts rather than imported from @instructure/ui-utils, because build scripts need to run before workspace packages are compiled.

Bootstrap design-token refresh

• scripts/bootstrap.js now refreshes @instructure/instructure-design-tokens from its GitHub source before building themes, so a clean bootstrap doesn't reuse a stale tarball.
• Scoped via pnpm --filter @instructure/ui-scripts update … (only ui-scripts declares the dep) to avoid the workspace-wide lockfile churn that pnpm update -r was causing.

Color modifiers (emotion, ui-scripts)

• New applyColorModifiers util in packages/emotion resolves Tokens Studio darken / lighten modifiers in HSL space, matching Studio's space: "hsl" math (each step is a fraction of the remaining distance to black/white, so it never overshoots).
• Wired into both useStyleNew and withStyleNew so any component theme entry shaped as { value, modify: { type, value } } is collapsed to a final color string before reaching the component.
• generateComponents.js now preserves the $extensions["studio.tokens"].modify payload through the token build instead of dropping it, so the modifier metadata actually reaches the runtime.

Theme type generation refactor

• Generated per-component theme files no longer carry an explicit return type or import their type from componentTypes/; the function is emitted untyped and consumers rely on the aggregate ComponentTypes shape. Reduces cross-file coupling in the generated output.

Test plan

• pnpm run bootstrap succeeds end-to-end on a clean checkout; only ui-scripts-related entries change in pnpm-lock.yaml.
• Spot-check a generated component file under packages/ui-themes/src/themes/*/components/ — signature is (semantic: Semantics) and body references resolve against semantic.*, not semantics.*.
• Spot-check a generated semantics.ts for at least one theme — values that come from multiple token files are all present (verifies the deep-merge fix).
• Spot-check a component whose theme uses a darken / lighten modifier (e.g. a hover/active state) — at runtime, the resolved CSS shows an hsl(…) / hsla(…) color rather than a { value, modify } object, and the shade matches what Tokens Studio renders for the same token.
• pnpm run ts:check passes.
• pnpm run dev boots the docs app and components using semantic tokens (e.g. Button) render with correct theming, including any states that rely on color modifiers.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-05-26 15:24 UTC

[github-actions]

Visual regression report

✅ No changes.

Status	Count
Unchanged	32
Changed	0
New	0
Removed	0

📊 View full report

_{Baselines come from the visual-baselines branch. They refresh on every merge to master.}

[joyenjoyer]

Added my comments. Using both semantic and semantics for the same idea makes the code harder to read, the reader has to map the two forms and remember which one is correct in each spot, can you come up with better names?

[matyasf]

As I understand the code, we are now lying about the token type in generateComponents. Please make a ticket where we fix this

[matyasf]

This should be in ui-color-utils in the future