Skip to Content
Engine Pipeline

Engine Pipeline

ngCorex follows a clear, deterministic pipeline to transform design tokens into CSS.

Each stage has a single responsibility.
Each stage produces predictable results.

This document explains how the pipeline works and why it is structured this way.

High-level flow

At a high level, ngCorex processes tokens in the following order:

ngcorex.config.ts
↓
Extends Resolution
↓
Presets Application
↓
Token Merging
↓
Normalization
↓
Validation
↓
CSS Variable Generation
↓
Utilities Generation (optional)

All work is performed at build time.

Stage 1: Configuration input

The pipeline begins with ngcorex.config.ts.

This file contains the engine configuration, including:

  • Token sources (extends, presets, inline tokens)
  • Output settings (file path, format)
  • Utility generation options
  • Constraint configuration

At this stage:

  • configuration is loaded and parsed
  • no transformations are applied yet
  • the configuration structure is validated

Stage 2: Extends resolution

If the configuration includes an extends field, ngCorex resolves the base token files.

This allows you to:

  • Share tokens across multiple projects
  • Create design system foundations
  • Override specific values as needed

The extends feature:

  • Loads each base token file in order
  • Merges them using deep merge (last wins)
  • Resolves paths relative to ngcorex.config.ts

Stage 3: Presets application

If the configuration includes a presets array, ngCorex applies each preset in order.

Presets provide:

  • Pre-configured token sets
  • Quick starting points
  • Common design system patterns

The presets are applied:

  • Each preset’s tokens are merged into the configuration
  • User tokens override preset tokens
  • Multiple presets can be combined

Stage 4: Token merging

After extends and presets are resolved, ngCorex merges all token sources.

The merge order is:

  1. Base token files (from extends)
  2. Preset tokens
  3. User-defined tokens (from ngcorex.config.ts)

This ensures that user tokens always take precedence.

Stage 5: Normalization

Normalization converts raw token values into a consistent internal format.

Normalization exists to:

  • standardize value shapes
  • remove ambiguity
  • prepare tokens for validation and output

Examples of normalization:

  • ensuring consistent units and value types
  • flattening nested structures where needed
  • aligning token categories to a common internal model

Normalization does not change the meaning of a token.

Stage 6: Validation

After normalization, tokens are validated against defined constraints.

Validation ensures:

  • values are structurally correct
  • formats and units are supported
  • token categories follow expected patterns

Validation produces three kinds of diagnostics:

  • errors (blocking)
  • warnings (non-blocking)
  • informational messages

If errors are present, the pipeline stops here.

Stage 7: CSS variable generation

Once tokens are validated, ngCorex generates CSS variables.

At this stage:

  • token names are converted into CSS-safe identifiers
  • values are emitted as --css-variables
  • output is deterministic and stable

Generated CSS is treated as build output and should not be edited manually.

Stage 8: Utilities generation (optional)

If utilities are enabled in the configuration, ngCorex generates utility classes.

Utilities generation:

  • Reads normalized tokens
  • Applies utility configuration
  • Generates CSS classes for each enabled utility category

The output includes:

  • Spacing utilities (margin, padding, gap, width, height)
  • Color utilities (text, background, border)
  • Layout utilities (display, flex, grid)
  • Typography utilities (fontSize, fontWeight, lineHeight)
  • Radius, shadows, opacity utilities
  • Border width and style utilities
  • Gradient and icon utilities
  • Container utility

Utilities are generated in a separate output file (configurable via utilities.output).

Determinism and predictability

The ngCorex pipeline is deterministic by design.

This means:

  • the same input always produces the same output
  • the same validation messages appear in the same order
  • builds are reproducible across environments

This is critical for:

  • CI pipelines
  • team-based workflows
  • long-lived projects

Why this pipeline matters

Separating the pipeline into clear stages allows ngCorex to:

  • catch errors early
  • keep output stable
  • evolve individual stages without breaking others
  • remain understandable as the system grows

Each stage builds on the guarantees of the previous one.

The addition of extends, presets, and utilities provides:

  • Token inheritance and sharing
  • Quick starting points with presets
  • Rapid development with utilities
  • Flexibility without sacrificing governance

No runtime cost

All processing happens at build time.

ngCorex does not:

  • inject runtime JavaScript
  • compute styles dynamically
  • add client-side overhead

The output is plain CSS.

Extensibility (conceptual)

The pipeline is designed to support future expansion without changing its core structure.

Additional stages or outputs can be added while preserving:

  • token input
  • normalization guarantees
  • validation behavior
  • backward compatibility

These extensions are incremental and opt-in.

Next steps

To continue learning:

Last updated on
Token ValidationProject Structure