DS Tokens IntelliSense

IntelliSense for DTCG design tokens organized in layers (core, semantic, component), as consumed by Style Dictionary. The extension catches errors in the editor that the build only reports at the end, without a file or line number: broken references, invalid colors, and cycles.

Diagnostics
In token files (configurable; by default any tokens/**/*.json, plus core.json, components.json, semantic.json and their per-theme variants components.<theme>.json / semantic.<theme>.json anywhere in the workspace):
| Issue |
Severity |
Missing reference {color.content.on-surface} (with a suggestion when a similar name exists) |
Error |
| Reference resolved in only one theme (light but not dark) |
Warning |
| Circular reference (the cycle is shown in the message) |
Error |
Invalid color (#18ZZZZ) |
Error |
Short hex (#1855), valid in CSS but outside the DTCG spec |
Warning |
Alias to a token with a different $type |
Warning |
In CSS files (excluding build/ and dist/): every var(--space-999) that matches neither a token nor a declared custom property is reported. If no token file has been indexed, the extension has no source of truth, so these CSS diagnostics are disabled instead of reporting every var() as missing.
Diagnostics update while you type, without waiting for a save.

IntelliSense


- Autocomplete for token keys when typing
{ in a $value, filtered by $type, with color swatches. The same applies in CSS for token-derived var(--...) values.
- Hover: full resolution chain by theme, for example
{color.action.primary} to {color.blue.600} to #185FA5.
- Go to Definition (F12, Cmd+click) from a JSON alias or CSS
var(--...) to the token definition. Both themes are offered for the semantic layer.
- Native color swatches on
$type: color tokens (the picker does not destroy aliases), plus decorative swatches on CSS var(--color-...) values.
- Highlighting of color token names using their resolved color, with black or white text based on luminance (can be disabled).
- Semantic highlighting for the DTCG structure: groups, token names,
$value and $type keys, and aliases, each with its own color.

Modèle de résolution multi-thèmes
The model reflects a multi-theme Style Dictionary build: shared layers (core, component, and a theme-less semantic.json) are visible to every theme, and each themed file forms a theme-specific resolution set. It is therefore normal, not an error, for light and dark to define the same paths; however, a token defined in only one theme triggers a warning on its usages.
Two layouts are recognized, and can be mixed:
| Layer |
Folder layout |
Flat layout |
| Core (shared) |
tokens/core/*.json |
core.json |
| Component (shared) |
tokens/component/*.json |
components.json |
| Component, per theme |
— |
components.light.json, components.dark.json |
| Semantic (shared) |
— |
semantic.json |
| Semantic, per theme |
tokens/semantic/light.json, tokens/semantic/dark.json |
semantic.light.json, semantic.dark.json |
The .tokens.json suffix is accepted everywhere (semantic.dark.tokens.json). Any other JSON file under tokens/ is treated as core.
Réglages
| Setting |
Default |
Purpose |
dsTokens.tokensGlob |
{**/tokens/**/*.json,**/core.json,**/components.json,**/semantic.json,**/components.*.json,**/semantic.*.json} |
Where to find token files |
dsTokens.nameHighlights |
true |
Highlight color token names with their color |
License
MIT