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

#opensource #symfony #php #softwaredevelopment

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.