DEV Community: Wolf

UI Kernel: Design Tokens as Symfony infrastructure

Wolf — Fri, 03 Jul 2026 22:34:20 +0000

For years, Symfony teams solved UI scaling one of two ways.

Either you adopted a JavaScript build pipeline — Webpack Encore, Vite, npm scripts — and a utility CSS framework like Tailwind.

Or you stayed "PHP-first" and watched every project grow its own app.css, its own spacing scale, its own dark-mode hacks, and its own Bootstrap overrides.

Both paths work. Neither scales cleanly across agencies, products, and long-lived admin UIs.

UI Kernel (symfinity/ui-kernel, current line 0.3.x) is Symfinity's answer on the Symfony side: treat design tokens as infrastructure — resolved in PHP, emitted as CSS custom properties, consumed by Twig and component CSS — without making Node the gatekeeper of your theme.

This article explains the CSS story first, then where Symfony fits in — including the 0.3.x theme engine (runtime switching, overlays, and inheritance).

The problem tokens solve

Hard-coded hex values in templates do not scale.

When primary blue lives in forty places, rebranding is a grep exercise. When dark mode is bolted on with @media (prefers-color-scheme: dark) and ad hoc overrides, contrast breaks in corners nobody tested. When spacing is "whatever looked fine in Figma," components drift apart.

Design tokens are the fix: named, semantic variables (--color-text, --space-md, --radius-lg) that components reference instead of raw values.

That idea is not new. What changed recently is how we author and validate those tokens in CSS — especially for colour.

Why OKLCH matters for palettes

Classic spaces — RGB, HSL — are easy to compute but bad at matching human perception.

A "50% lightness" yellow and a "50% lightness" blue do not look equally bright. Darkening with hsl() or Sass darken() shifts hue and brightness in unpredictable ways. Building a ten-step brand ramp that stays accessible was always guesswork.

OKLCH (lightness, chroma, hue in the Oklab model) is perceptually uniform: equal steps on the L axis feel like equal brightness changes across hues. That makes ramps, states (hover, active), and dark-mode pairs far more predictable.

In modern CSS you can write tokens directly:

:root {
  --text: oklch(0.30 0.03 260);
  --surface: oklch(0.97 0.01 260);
  --accent: oklch(0.60 0.14 255);
}

Progressive enhancement still matters — ship sRGB fallbacks, layer OKLCH behind @supports:

:root {
  --text: #222326;
  --accent: #005fcc;
}

@supports (color: oklch(0.5 0.1 0)) {
  :root {
    --text: oklch(0.30 0.03 260);
    --accent: oklch(0.60 0.14 255);
  }
}

For state colours, color-mix(in oklch, …) keeps blends on the perceptual axis instead of muddy RGB averages.

Contrast: WCAG today, APCA tomorrow

Accessibility checks still anchor on WCAG 2.x contrast ratios (4.5:1 body text, 3:1 large text/UI). OKLCH helps because L tracks perceived lightness — pairs with sufficient L separation tend to pass, which is why token-driven systems can enforce contrast at generation time instead of in every component file.

APCA (Advanced Perceptual Contrast Algorithm) is the direction of travel for WCAG 3. Good practice in 2026: design with APCA awareness, audit with WCAG for compliance paperwork. They usually agree; where they diverge, APCA often reflects real-world legibility better (thin type, dark UI, wide gamut).

Tools worth bookmarking

These are the references I reach for when building or reviewing token palettes — independent of Symfony:

OKLCH Color Picker & Converter — oklch.com — pick, convert, P3/Rec2020 preview, palette building with APCA (Evil Martians)
Evil Martians OKLCH ecosystem guide — Exploring the OKLCH ecosystem — Harmonizer, apcach, and related tooling
Atmos OKLCH picker — atmos.style/color-picker/oklch — fast format conversion plus WCAG/APCA hints
HubTools color picker — hub-tools.com/tools/color-picker — OKLCH/LAB/P3, harmonies, CVD simulation, W3C token export
APCA introduction — APCA easy intro — readable explainer for the contrast model
W3C Design Tokens Community Group — designtokens.org — format spec for portable token files

From CSS files to Symfony infrastructure

Node-centric pipelines (Style Dictionary, Tailwind config, theme JSON → build step) fit design agencies. They hurt Symfony teams who want Flex install, YAML config, and AssetMapper without a second repository for tokens.

UI Kernel inverts the default:

Tokens live as data — W3C DTCG-shaped theme layers (colour, spacing, radius, motion, typography references).
PHP resolves and validates — lineage (Balanced, Semantic, Utility), light/dark variants, OKLCH ramp math, contrast-aware semantic colours.
CSS is emitted server-side — custom properties on [data-theme="…"], wrapped in cascade layers (kernel.tokens, kernel.profile) for predictable stacking with ux-blocks-* tiers.
Twig wires the page — boot script, layer order, and theme CSS in the layout; no Encore entry for "theme variables."

Minimal layout (order matters — boot script first avoids a flash of the wrong theme):

{# templates/base.html.twig #}
<head>
    {{ ui_kernel_theme_boot_script() }}
    {{ ui_kernel_layer_order()|raw }}
    {{ ui_kernel_css()|raw }}
</head>

Or use the bundle partial, which emits the same three calls:

{% include '@UiKernel/_head.html.twig' %}

Configuration stays in familiar Symfony paths:

# config/packages/symfinity_ui_kernel.yaml
symfinity_ui_kernel:
    default_theme: semantic
    default_variant: semantic
    schema_version: '2.0'

Install is Composer + Flex — same story as any other bundle:

composer require symfinity/ui-kernel

What you do not need for theming: Tailwind as the token source of truth, a Sass pipeline for variables, or Encore/Vite solely to compile :root { --… }.

What you still use Symfony for: AssetMapper for component JS/CSS paths, Stimulus for micro-interactions, UX Twig Components for leaves — AssetMapper is plumbing, not your design system.

Runtime theme engine (0.3.x)

Static token emission was the 0.2.x story. 0.3.x adds a theme engine on top — still server-resolved, still no Node build step.

Runtime switching

Users pick light, dark, or auto without redeploying CSS. The boot script sets data-theme before first paint; preference cookies (symfinity_ui_kernel_lineage, symfinity_ui_kernel_scheme) persist the choice.

Scheme API

PATCH /_ui/theme/scheme returns resolved theme id, colorScheme, and refreshed CSS when the client needs server-side dark-mode resolution.

Theme shell

ui_kernel_theme_shell() emits layout chrome (lineage + light/dark/auto controls) wired to the same preference model.

Overlays

Config user_tokens merge atop the registry theme; app config/themes/{lineage}/ overrides bundle lineages; optional session preview on designated preview hosts (pairs with symfinity/ui-designer in dev).

Theme inheritance

Optional extends on a variant entry in theme.meta.yaml merges a parent theme layer before child overrides — multi-hop chains with cycle detection (0.3.1).

Capability probe

ui_kernel_theme_capabilities() reports which engine features are active (runtime_switch, user_token_overlay, nested_theme, and others).

Built-in lineages still ship as W3C DTCG files under config/themes/{lineage}/ (theme.meta.yaml + {variant}.dtcg.yaml), not a bespoke preset blob. Consumer apps drop overrides in the same layout; merged variants appear in ThemeRegistry.

Authoring UI for composition graphs, import/export, and the visual studio at /ui-designer lives in symfinity/ui-designer (dev-only, requires ui-kernel ^0.3.1) — the kernel stays the runtime contract.

How this stays scalable

Semantic tokens, not utility soup

Components and UX Blocks reference roles and semantic variables (data-ui-role, --ui-color-accent, spacing rhythm) — not p-4 text-gray-600 copied across Twig files.

The kernel owns the look spine; symfinity/ux-blocks-* packages own component CSS that consumes those variables. Boundary stays explicit: kernel emits tokens and global profile rules inside @layer kernel.*; blocks emit role selectors inside @layer blocks.*. Call ui_kernel_layer_order() before theme CSS so integrator CSS can override predictably.

One theme graph, many surfaces

The same resolved token graph can feed:

Web layouts — static emission plus 0.3.x runtime switching, overlays, and inheritance without forking app.css
Email HTML with inline-safe subsets (horizon)
PDF/print (horizon)
CLI/TUI structured output (horizon)

That is the payoff of server-resolved tokens versus "whatever landed in public/build/app.css last Tuesday."

OKLCH inside, CSS outside

Internally, Symfinity generates palettes in OKLCH for perceptual ramps and ref resolution. Public CSS still ships browser-ready strings (sRGB hex/rgb(), with P3 where supported). You get palette math without asking every integrator to hand-author oklch() literals in YAML.

Works with what you already run

UI Kernel complements Symfony UX — it does not replace Live Components, Turbo, or Stimulus.

Typical Stage A path:

Install kernel for tokens on the layout shell.
Drop UX Blocks into existing Twig.
Add font-manager when typography tokens need real webfonts.

Plain Twig + your own CSS remains valid for marketing pages. The stack targets long-lived product and admin UI where theme drift hurts.

When Tailwind or Encore still make sense

Honest scope:

Tailwind — excellent for marketing microsites, rapid prototypes, or teams already standardized on utility CSS. Symfinity does not ask you to rip it out on day one.
Encore/Vite — still right when you need a heavy JS application bundle, legacy React/Vue islands, or org-wide frontend tooling unrelated to tokens.

UI Kernel draws a line: theming and design-system variables are Symfony infrastructure, not npm devDependencies.

If your pain is "every client has a different primary colour and our admin UI looks nothing like last year's project," tokens in PHP beat another tailwind.config.js fork.

Try it locally

After adding the symfinity/recipes Flex endpoint:

composer require symfinity/ui-kernel

Handbook: ui-kernel docs — quick start, themes (0.3.x), upgrade guide.

What's next

UI Kernel roadmap: 0.3.x theme engine (current) → 0.4.x token engine (computed tokens, references, expressions) → 0.5.x generator engine. See ROADMAP.md.

Don't miss the introduction series to Symfinity:

For package-level deep dives already published:

Articles on further Symfinity package tiers are planned — ui-designer (theme authoring studio) and UX Blocks deep dives are on the list.

Explore packages and source at github.com/symfinity.

Updated 2026-07-05 for ui-kernel 0.3.x (runtime switching, cascade layers, theme inheritance).

The rule behind every Symfinity package

Wolf — Wed, 24 Jun 2026 20:00:14 +0000

Whenever I start a new package, I try to follow a simple rule.

If a package does not improve developer experience, it probably should not exist.

That sounds obvious. But it has become the guiding principle behind Symfinity.

A package must solve a real problem

The first question is simple:

Would I actually use this package in my next project?

If the answer is no, it probably belongs in an experiment repository instead.

That is how symfinity/font-manager and symfinity/omnia-ipsum started: I needed fonts and placeholder content on the next greenfield, not another abstract slot in a roadmap slide.

A package must be Symfony-native

I do not want packages that fight Symfony. I want packages that feel like they belong there.

Symfony-native, for Symfinity, means:

Composer-first — install with composer require, not a parallel plugin manager
Flex recipes where they earn their keep — sensible defaults, manifest-driven wiring, overrides in the usual Symfony config paths
Standard bundle shape — Extension, Configuration, services tagged the Symfony way; no hidden bootstrap magic
Hooks you already know — Twig, Console, AssetMapper, and HTTP integration that follow Symfony docs, not a second framework inside the framework
Predictable integration — if you know Symfony, you know where to look

Minimal surprises. No ecosystem lock-in dressed up as convenience.

A package must require little configuration

Configuration is sometimes necessary.

Excessive configuration is usually a sign that something can be improved.

The best configuration is often the one users never have to write.

A package must work alone

Every Symfinity package should provide value on its own.

If somebody installs only one package, the experience should still be worthwhile.

No ecosystem lock-in. No artificial dependencies.

Install only symfinity/font-manager or only symfinity/omnia-ipsum and you should still get a complete answer to that one problem.

A package should work better together

At the same time, packages should share conventions.

The more packages you combine, the more benefits you should get.

Not because they are tightly coupled.

Because they speak the same language.

The principle

If I had to summarize the philosophy behind Symfinity in a single sentence, it would be this:

Independent packages. Shared conventions.

That idea influences every design decision.

And it will continue to guide the project as it grows.

What's next

This article is the third part of a short introduction series to Symfinity.

For package-level deep dives already published:

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

Why Symfony projects feel more fragmented than ever

Wolf — Wed, 24 Jun 2026 19:49:28 +0000

Let me start with something important.

I love Symfony

In my opinion, Symfony remains one of the best foundations for serious PHP applications.

So this is not criticism of Symfony. It is an observation about modern projects.

Symfony Is Great at Solving Individual Problems

Symfony gives us excellent building blocks—routing, dependency injection, security, forms, Messenger, Twig, the UX initiative, AssetMapper, Flex recipes, and more.

The ecosystem is huge and mature. That is a strength.

And Symfony keeps improving the glue: Flex recipes wire bundles in predictably, AssetMapper reduces frontend build-tool sprawl for many apps, and the UX packages give us shared patterns for live components and Stimulus.

Those tools genuinely reduce fragmentation within Symfony.

The side effect of success

Even with better defaults, modern Symfony projects often still stack:

Twig Components and UX packages from different vendors
Asset management and font handling from different ecosystems
Design systems and documentation tooling with their own conventions
Frontend build tooling where AssetMapper is not enough

Each piece solves a legitimate problem. But the overall picture becomes harder to understand. The project starts to feel like a collection of systems rather than a single system.

Placeholder content might come from one package, fonts from a workflow that still touches npm, UI primitives from a third library—each fine on its own, none sharing install steps or naming.

Death by configuration

The challenge is rarely one specific configuration file. The challenge is understanding where everything lives.

Which configuration belongs to which package?
What is a default?
What is overridden?
What came from a recipe?
What came from a bundle?

The more moving parts a project has, the more difficult those questions become.

Looking for Consistency

What I wanted was not less flexibility. I wanted more consistency.

The same conventions.
The same installation experience.
The same developer experience.
The same language across multiple concerns.

Symfony supplies the building blocks and much of the integration machinery.

What was still missing for me was a cross-cutting layer: packages that solve recurring app needs — fonts, placeholders, UI foundations — while agreeing on how they install, configure, and compose.

That is a different job from replacing Flex or AssetMapper.

The Symfinity Perspective

Symfinity is my attempt to create that consistency layer.

Not by replacing Symfony. Not by hiding Symfony.

But by building packages that share common conventions and integrate naturally with each other — and with the Symfony tools you already use.

Conclusion

Symfony's flexibility is one of its greatest strengths.

But flexibility also creates opportunities for fragmentation—especially across packages from different authors and eras.

The goal of Symfinity is not to remove flexibility.

The goal is to reduce friction.

What's next

This article is the second part of a short introduction series to Symfinity.

For package-level deep dives already published:

Articles on UI Kernel and the ux-blocks-* component tiers are planned.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

Why building Symfony-native packages instead of doing infrastructure again and again

Wolf — Wed, 24 Jun 2026 18:58:50 +0000

For years, I did what many Symfony developers do. Whenever I needed a feature, I searched for a package:

Need fonts? Go to Google Fonts and wire it up in the assets.
Need placeholder content? Add a package, implement helpers, call in Twig.
Need a frontend toolkit? Make a choice and wire it up in the assets and in Twig.
Need documentation tooling? Add another package and implement again.

None of these decisions were wrong. Most of the tools were excellent. But after building project after project, I noticed a pattern.

The same infrastructure, again and again

Every new project started with roughly the same checklist:

Fonts
Placeholder content
Assets
UI helpers
Documentation tooling
Project conventions

The business logic was always different. The infrastructure was usually the same. Yet I kept rebuilding or reconfiguring it.

Fonts often meant a separate frontend toolchain on top of PHP. Placeholder content meant yet another API shape and Twig integration to wire up. Each choice was reasonable; together they ate the first days of every greenfield.

When Symfony stops being the whole story

Symfony itself is fantastic.

Routing, Dependency Injection, Security, Messenger, Twig, Console, Events — these are not the problem.

The problem starts when a project grows.

Soon there is:

Composer
npm
Build tools
Frontend frameworks
Asset pipelines
Configuration files everywhere

Nothing is broken.

But the cognitive load keeps growing.

A different idea

At some point I stopped asking:

“Which dependency should I add next?”

And started asking:

“Why am I solving the same infrastructure problem for the tenth time?”

That question eventually became Symfinity. Not as a framework. Not as a Symfony replacement. Just as a collection of Symfony-native solutions for recurring problems.

The first packages I packaged for real use were practical ones: symfinity/font-manager for multi-format font export without leaving Composer and AssetMapper, and symfinity/omnia-ipsum for placeholder content with one Twig-facing API instead of ad hoc fixtures.

The goal

Every package should:

Solve a real problem
Feel native to Symfony
Require minimal configuration
Work independently
Integrate naturally with other Symfinity packages

A package should be useful even if it is the only Symfinity package in a project.

Conclusion

Symfinity did not start with a grand vision of building an ecosystem. It started with a simple observation: I was rebuilding the same infrastructure over and over again. Eventually, packaging those solutions became the more sensible option.

What's next

This article is the first part of a short introduction series to Symfinity.

Part 2: Why Symfony projects feel more fragmented than ever
Part 3: The rule behind every Symfinity package

For package-level deep dives already published:

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

Omnia Ipsum: Unified placeholder content for Symfony

Wolf — Wed, 24 Jun 2026 18:16:39 +0000

Rethinking fake content in Symfony projects

A prototype web page displaying pure placeholder content
When building early UI prototypes or shaping design systems in Symfony, placeholder content becomes a constant companion. Lorem ipsum text. Dummy profile photos. Placeholder videos. Silent audio. Temporary avatars. Realistic fake user data. Every project needs them — and yet most setups rely on a patchwork of libraries, links and hardcoded values.

Omnia Ipsum aims to fix that by giving Symfony developers a single, elegant toolkit for placeholder content of all kinds.

In this article, I will walk you through the motivation behind the project, the conceptual patterns it follows, and its most advanced features — all designed to make your prototyping workflow faster, cleaner and more maintainable.

Motivation: Why a placeholder library?

Most Symfony projects start the same way:

You add lorem ipsum text manually into Twig templates.
You grab placeholder images from an external service.
You generate avatars using yet another site.
You paste in temporary YouTube or stock video URLs.
You install Faker separately whenever realistic data is needed.

The result is inconsistent, fragmented and difficult to maintain.
And even worse: placeholder content often leaks into production unless guarded carefully.

The idea behind Omnia Ipsum was simple:

“If your UI needs placeholder content, it should come from one place — predictable, configurable, and accessible directly from Twig.”

This cuts down on boilerplate, cognitive overhead, and the "temporary chaos" of early-stage templates.

Quick Start

Prerequisite

Go to github.com/symfinity/recipes and follow the instructions to add the required recipe repository.

Installation

composer require --dev symfinity/omnia-ipsum

Usage

Use the Twig functions immediately:

<img src="{{ omnia_image(600, 400) }}" alt="Placeholder">
<img src="{{ omnia_avatar('John Doe', 100) }}" alt="Avatar">

<video src="{{ omnia_video(1920, 1080) }}" controls></video>
<audio src="{{ omnia_audio(10) }}" controls></audio>

<h1>{{ lorem_title() }}</h1>
<p>{{ lorem_paragraphs(3) }}</p>

<p>{{ fake('name') }} – {{ fake('email') }}</p>
<p>{{ fake_text(200) }}</p>

Everything is a Twig function

Omnia Ipsum provides a set of expressive Twig helpers:

omnia_image(width, height)
omnia_avatar(name, size)
omnia_video(width, height)
omnia_audio(seconds)
lorem_paragraphs(count)
fake('email')
fake_text(200)

Advanced Features

Multiple Image Providers

{{ omnia_image(800, 600, provider='picsum') }}
{{ omnia_image(800, 600, provider='dummy') }}
{{ omnia_image(800, 600, provider='dummyimage', background='#3355ff') }}

Automatic Avatar Generation

{{ omnia_avatar('Alice Johnson', 128) }}

Placeholder Video & Audio

<video src="{{ omnia_video(1920, 1080) }}" controls></video>
<audio src="{{ omnia_audio(5) }}" controls></audio>

Integrated Lorem Ipsum Utilities

{{ lorem_title() }}
{{ lorem_sentences(3) }}
{{ lorem_paragraphs(2) }}

Faker Integration

{{ fake('name') }}
{{ fake('email') }}
{{ fake('address') }}
{{ fake_text(120) }}

Extensible Architecture

Developers can add custom providers or extend generator logic via Symfony services.

When to Use Omnia Ipsum

Ideal for:

Design systems
Component libraries
Prototyping complex UIs
Responsive layout testing
Admin dashboards
Workshops and trainings

Conclusion

Omnia Ipsum provides a unified, elegant API for all placeholder content commonly needed in Symfony projects.

If you want cleaner templates, faster prototyping, and a more structured workflow, Omnia Ipsum is a strong addition to your toolbox.

Try it now: symfinity/omnia-ipsum

If you find it useful, star the repository and share it with your Symfony community.

What's next

Don't miss the introduction series to Symfinity:

Another package-level deep dive:

Font Manager: Multi-Format Font Export for Symfony

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

Font Manager: Multi-format Font export for Symfony

Wolf — Wed, 24 Jun 2026 18:15:42 +0000

The Problem

Typography should be one of the simplest parts of a project.

In reality, it often ends up scattered across multiple layers:

Bootstrap: $font-family-base variables
Tailwind: JavaScript configuration
TypeScript: type definitions
Design systems: W3C Design Tokens

The same font information gets copied and maintained in several places. Every update means touching multiple files, hoping everything stays in sync.

It's repetitive, error-prone, and easy to get wrong.

So I built Font Manager.

Define your fonts once and export them in whatever format your project needs — CSS, Bootstrap variables, Tailwind configuration, TypeScript definitions, design tokens, and more.

The Solution

A simple Twig function:

{{ font_manager('Ubuntu', '400 700') }}

Configuration:

symfinity_font_manager:
    export:
        formats:
            - scss_bootstrap
            - tailwind_config
            - typescript_definitions

One lock command:

php bin/console fonts:lock

Every format, automatically generated. Perfectly synced.

Bootstrap Example

Before:

// Manually copy font name
$font-family-base: 'Ubuntu', sans-serif;  // ❌ Duplication
@import 'bootstrap/scss/bootstrap';

After:

symfinity_font_manager:
    export:
        formats: [scss_bootstrap]

php bin/console fonts:lock

// app.scss
@import './assets/styles/fonts-bootstrap';  // ← Auto-generated
@import 'bootstrap/scss/bootstrap';

Bootstrap uses your fonts automatically. No manual mapping. No duplication.

Tailwind Example

symfinity_font_manager:
    export:
        formats: [tailwind_config]

// tailwind.config.js
const fonts = require('./assets/fonts-tailwind.config.js');  // ← Auto-generated
module.exports = {
  theme: { extend: { fontFamily: fonts.fontFamily } }
};

<p class="font-sans">Your custom font, via Tailwind.</p>

TypeScript Example

symfinity_font_manager:
    export:
        formats: [typescript_definitions]

import { fonts, type FontFamily } from './assets/fonts';

applyFont(element, 'sans');     // ✓ Valid
applyFont(element, 'invalid');  // ✗ TypeScript error!

Typos caught at compile time.

The 12 Formats

CSS, SCSS, JavaScript, Design Tokens — pick what you need:

php bin/console fonts:formats

CSS: Variables, Modules, @layer
SCSS: Variables, Bootstrap, Mixins
JavaScript: ESM, Tailwind, TypeScript
Design System: JSON, W3C Tokens, Figma, Style Dictionary

Build Tools

AssetMapper, Webpack, or Vite? Auto-detected.

Output paths adjust automatically. No config needed.

Design Systems

Export to Figma Tokens, Style Dictionary, or W3C Design Tokens:

formats:
    - design_tokens
    - figma_tokens

npx style-dictionary build  # CSS, iOS, Android from one source

Design once. Ship everywhere.

Privacy Options

Not just Google — choose your provider:

symfinity_font_manager:
    default_provider: 'bunny'  # GDPR-compliant, zero tracking

Google, Bunny, Fontsource, or Local. Same API. Your choice.

How It Works

Architecture: Strategy pattern. Each format is a separate exporter.

Dependency resolution: Automatic. css_modules needs css_variables? Handled.

Build detection: Scans for webpack.config.js, vite.config.js, asset_mapper.yaml.

Output paths: Adjusted per build tool. AssetMapper → assets/styles/. Webpack → assets/.

Commands:

php bin/console fonts:formats           # List all formats
php bin/console fonts:format:info scss  # Usage instructions
php bin/console fonts:export            # Export manually

Migrating from google-fonts

One command:

php bin/console fonts:migrate-from-google-fonts

Config, templates, manifest — all updated automatically.

Prerequisite

Go to github.com/symfinity/recipes and follow the instructions to add the required recipe repository.

Installation

composer require symfinity/font-manager

That’s it. Symfony Flex does the rest.

Quick Start

{{ font_manager('Ubuntu', '400 700') }}

Dev: CDN
Prod: Self-hosted (after fonts:lock)

Add exports:

symfinity_font_manager:
    export:
        formats: [scss_bootstrap, tailwind_config]

Lock:

php bin/console fonts:lock

Use:

@import './fonts-bootstrap';
@import 'bootstrap/scss/bootstrap';

Done.

Conclusion

Typography shouldn’t waste your time or violate privacy law.
With font-manager, you can design freely in development, ship safely in production, and forget about fonts altogether.

One Twig function. Multiple providers. Twelve export formats. Zero manual mapping.

That’s Font Manager.

Try it now: symfinity/font-manager

If you find it useful, star the repository and share it with your Symfony community.

What's next

Don't miss the introduction series to Symfinity:

Another package-level deep dive:

Omnia Ipsum: Unified Placeholder Content for Symfony

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

DEV Community: Wolf

UI Kernel: Design Tokens as Symfony infrastructure

The problem tokens solve

Why OKLCH matters for palettes

Contrast: WCAG today, APCA tomorrow

Tools worth bookmarking

Further reading (CSS and design systems)

From CSS files to Symfony infrastructure

Runtime theme engine (0.3.x)

Runtime switching

Scheme API

Theme shell

Overlays

Theme inheritance

Capability probe

How this stays scalable

Semantic tokens, not utility soup

One theme graph, many surfaces

OKLCH inside, CSS outside

Works with what you already run

When Tailwind or Encore still make sense

Try it locally

What's next

Don't miss the introduction series to Symfinity:

For package-level deep dives already published:

The rule behind every Symfinity package

A package must solve a real problem

A package must be Symfony-native

A package must require little configuration

A package must work alone

A package should work better together

The principle

What's next

For package-level deep dives already published:

Why Symfony projects feel more fragmented than ever

I love Symfony

Symfony Is Great at Solving Individual Problems

The side effect of success

Death by configuration

Looking for Consistency

The Symfinity Perspective

Conclusion

What's next

For package-level deep dives already published:

Why building Symfony-native packages instead of doing infrastructure again and again

The same infrastructure, again and again

When Symfony stops being the whole story

A different idea

The goal

Conclusion

What's next

For package-level deep dives already published:

Omnia Ipsum: Unified placeholder content for Symfony

Rethinking fake content in Symfony projects

Motivation: Why a placeholder library?

Quick Start

Prerequisite

Installation

Usage

Everything is a Twig function

Advanced Features

Multiple Image Providers

Automatic Avatar Generation

Placeholder Video & Audio

Integrated Lorem Ipsum Utilities

Faker Integration

Extensible Architecture

When to Use Omnia Ipsum

Conclusion

What's next

Don't miss the introduction series to Symfinity:

Another package-level deep dive:

Font Manager: Multi-format Font export for Symfony

The Problem

The Solution

Bootstrap Example

Tailwind Example

TypeScript Example

The 12 Formats

Build Tools