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

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. Links will be added as the stories get published.

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.

This article was previously published on medium.com.