DEV Community: Wolf

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.