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.
- Part 1: Why I started building Symfony-native packages instead of doing infrastructure again and again
- Part 2: Why Symfony projects feel more fragmented than ever
For package-level deep dives already published:
- Font Manager: Multi-Format Font Export for Symfony
- 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.