Design Tokens
Design tokens are the foundation of ngCorex.
Every spacing value, color, font size, or shadow used by your application is defined as a token. These tokens form a shared design vocabulary that ngCorex can validate, normalize, and compile into CSS.
What are design tokens?
Design tokens are named values that represent design decisions.
Instead of using raw values like 8px, #2563eb, or 1.25rem directly in styles, you define them once and reference them consistently.
Examples:
spacing.sminstead of8pxcolors.primary.500instead of#2563ebfontSize.mdinstead of1rem
This approach improves consistency, readability, and long-term maintainability.
The tokens.json file
All design tokens are defined in a single file: tokens.json.
This file is:
- the primary interface for most users
- the single source of truth for design values
- validated automatically during builds
A minimal example:
{
"spacing": {
"xs": "4px",
"sm": "8px",
"md": "16px"
},
"colors": {
"primary": {
"100": "#dbeafe",
"500": "#3b82f6",
"900": "#1e3a8a"
}
}
}You are encouraged to expand this file as your design system grows.
Supported token categories
ngCorex supports the following token categories.
Each category has its own validation rules and expected structure.
Spacing
Defines spacing values used for margins, padding, gaps, and layout.
{
"spacing": {
"xs": "4px",
"sm": "8px",
"md": "16px",
"lg": "24px"
}
}Spacing values must use supported units and formats.
Colors
Defines color palettes using nested objects.
{
"colors": {
"primary": {
"100": "#dbeafe",
"500": "#3b82f6",
"900": "#1e3a8a"
},
"neutral": {
"50": "#fafafa",
"900": "#111827"
}
}
}Color scales are validated for format, consistency, and common industry patterns.
Radius
Defines border radius values.
{
"radius": {
"sm": "2px",
"md": "4px",
"lg": "8px"
}
}Z-Index
Defines layering values.
{
"zIndex": {
"dropdown": 1000,
"modal": 1100,
"tooltip": 1200
}
}Z-index values are validated for type and format.
Typography
Defines typography-related tokens.
{
"typography": {
"fontSize": {
"sm": "0.875rem",
"md": "1rem",
"lg": "1.25rem"
},
"fontWeight": {
"regular": 400,
"medium": 500,
"bold": 700
},
"lineHeight": {
"tight": "1.2",
"normal": "1.5"
}
}
}Each sub-category is validated independently.
Shadows
Defines box shadow values.
{
"shadows": {
"sm": "0 1px 2px rgba(0,0,0,0.05)",
"md": "0 4px 6px rgba(0,0,0,0.1)"
}
}Shadow values are validated for structure and type.
Naming and structure guidelines
ngCorex does not enforce naming conventions, but the following guidelines are recommended:
- Use descriptive, semantic names
- Avoid embedding raw values in names
- Keep scales consistent within a category
Good:
spacing.sm,spacing.mdcolors.primary.500
Avoid:
spacing.8pxcolors.blueish
Validation and safety
All tokens are validated during the build process.
- Invalid values produce errors and block the build
- Suspicious patterns produce warnings
- Informational messages provide guidance without interruption
This ensures incorrect or inconsistent values are caught early.
Validation rules are designed to be deterministic: the same input will always produce the same results.
Normalization (brief overview)
Before generating CSS, ngCorex normalizes token values into a consistent internal format.
Normalization:
- does not change the meaning of values
- ensures consistent output across categories
- enables predictable CSS variable generation
The details of this process are covered in the Engine Pipeline documentation.
Recommended workflow
- Define or update values in
tokens.json - Run the build
- Review validation messages if any
- Import generated CSS into your application
Design decisions should always be made at the token level, not in generated output.
Next steps
To continue learning:
- Token Validation - understanding errors, warnings, and info messages
- Engine Pipeline - how tokens are normalized and compiled
- CLI Reference - available commands and flags