@chris The first Symfony project (2.x) I worked with had bundles that weren't decoupled anymore after just a few features later. There was also no point for reusing a bundle.
@chris We moved away from bundles for projects because it simplified things as those bundles were often not reusable anyway (nor decoupled when having multiple ones). But bundles still exist in Symfony and are the way to share things (project-level code can customize the kernel directly, but that's not composable without bundles)
@stof interesting… thank you! I've been interested in more modular approaches to building PHP apps (not necessarily Symfony), and wondered if there were any specific downsides that led to that decision. In my experience, apps of a certain size benefit from being organized into separate domains (even if you're not going full DDD), and bundles strike me as a decent way to do that.
@chris organize your PHP code in well thought out namespaces and use tools like Deptrac or PHPAT to enforce these.
Bundles are standalone packages, e.g. they have to define their own services, tests, templates, translation files, etc. Unless this is shared by more than 1 different application, this extra overhead never pays off.
And history has learned that 90% of the code in applications fall outside this category, which is why Symfony stopped using bundles for application code by default.
Add comment