today i tested the possibity to mirate some of our symfony2 bundles to a drupal8 module. i noticed that i can simply copy all of our bundles in the module folder and we are done. i only needed to patch a few lines in the drupal booting:


currently we have only:


the symfony2 way:


by the way, autoloading "bundleless" files will work also:


so now we have a registered bundle and from here we can do some more magic stuff...

i can optimize the code and provide a diff, if there is any interesting person.

#1 0001-every-module-can-provide-a-src-folder-for-recursive-.patch9.16 KBHaehnchen
PASSED: [[SimpleTest]]: [MySQL] 50,692 pass(es).
[ View ]


Status:Active» Patch (to be ported)
new9.16 KB
[ View ]

so here is the patch with some additional test cases.

Status:Patch (to be ported)» Needs review

hey i'm hungry now ;( Kudos for writing tests!

Let's first discuss how we actually want it to behave and then fix the code-style-issues etc.
It seems to make sense for me to have a new component in Drupal beside modules/themes/profiles, though a bundle wouldn't fit 100% into the previous 3 examples,
because it will not have an info file. In general it would be nice, to get the two worlds connected even more.

What about adding a new "bundles" folder to make it clear where to put your stuff.

Component:plugin system» base system
Issue tags:+WSCCI

Adapting the components.

Status:Needs review» Needs work
Issue tags:-WSCCI

The last submitted patch, 0001-every-module-can-provide-a-src-folder-for-recursive-.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+WSCCI

We can use the SystemListing to search for .info files which should find the themes also, currently this is only done on .profile and .module. by the way we can than provide the lib/Drupal structure also for themes.

i would not rename the src folder to bundle, because in the src folder we have an autoloader fallback. so we can put there any namespaced class which is than known by the classloader. i dont found any discuss about the /lib/Drupal/ namespace structure, but currently i can not see any possibility to reuse or write psr-0 styled code, without the Drupal prefix.

whats about registering the lib folder as autoloader fallback too and provide a bundles folder? or put the bundles into lib? provide a .bundle file?

would it be nice if the .info can also provider some autoloader folders? so any psr-0 lib can simply implemented without changes!

by the way the registerModuleNamespaces() misses an is_dir check, so way search in lib folders which are not there?

pls some decisions; we need more psr-0.
i can then provide some more patches.


I thought about using bundles/src instead of modules/src

Maybe people like crell and other people should be first involved in the issue

Hm. Actually, I don't this is Drupal's job to manage at all. At least not directly.

A well designed bundle is just glue code between a component/library and Symfony. If what you want is that component, just stick that component in Packagist using Composer and then use Drush Composer to pull it in. That will take care of the autoloading.

If you really do want a bundle... the bundle should *also* be in Packagist so the same thing applies. Now there's still the problem of core not supporting 3rd party Composer usage directly, but that's another issue (that should still get solved).

So if all you want is the code, Composer should deal with it for you, end of story.

If you want the Bundle itself "as" a bundle, not just as a bunch of autoloadable code... there are compatibility issues there that I don't think we've resolved. We're not using the Symfony Config component, so I suspect most bundles won't actually run. Sure they could pull in the Config component I suppose, but I have no idea how well that will work given that Drupal makes no attempt to do anything with Symfony config files I question if that would do anything useful.

I'm not sure how (or if) we want to resolve that question.

The use case I have is a module that wants to pull in a generic Symfony bundle (performance monitoring for HTTPKernel). Here's what I've done to get it to work (and it now works fine in D8):

  • Modify composer.json to add the bundle
  • Run `drush composer update` to pull in the bundle, putting it with other dependencies
  • Load the bundle into the DIC via setting $conf in settings.php
  • Register bundle classes as services via the module's

I think this is a very bad approach even apart from the bundle loading nonsense because modifying core's composer.json should be treated like hacking core. Unfortunately, since module composer.json files aren't part of a package, that's not a solution - they won't be recursively included on a run of core's composer.json. Running them as composer.json files independently is out of the question - there's not even any reason to use Composer if you're going to break dependency management like that.

We need to think ahead and provide at least a basic framework for how a module can require bundles. It's OK if we wait for contrib to do the implementation since it's a rarer use case, but something like Composer Manager won't work in D8 without thought of how it will integrate with core's composer.json. IMO a module featuring a Symfonic bundle needs to be able to do the following without requiring a command line tool or hacking core:

  1. Get its composer.json pulled in recursively when core's composer.json is updated
  2. Get the bundle autoloaded
  3. Get the bundle registered
  4. Prevent `composer update` if it would change core in a way broken with the module's composer.json
  5. Prevent module update if it would change the module's composer.json in a way broken with core

3 is its own issue, so I'll skip it for now. 1 and 2 come together. But, if we want to get 4 and 5 too, I think we want something like this:

  • Each interested module includes a composer.json of type `drupal-module`.
  • A custom installer recognizes `drupal-module` packages and no-ops apart from their requires (i.e., it doesn't shove the module into vendor).
  • Core requires the `modules` metapackage from the filesystem.
  • When the module list changes, the `modules` metapackage is rewritten to require all composer.json-including modules (sort of like Composer Manager, but not assuming that it's the root composer.json) from the filesystem.
  • `composer update drupal/modules` pulls in the new version of the `modules` package from the filesystem instead of remotely.

Unfortunately, right now this can't be done because Composer's 'archive' repository type assumes that local filesystem packages are .zips in a folder, rather than nested locations within it. But with that (frustratingly minor) upstream change, we could allow modules to have fairly arbitrary composer.json includes with proper dependency handling...

FWIW: In searching "drupal 8 symfony 2 bundle" I found "TraceView’s Oboe Symfony No. 2", a blog post about the performance monitoring bundle mentioned in #9. Thanks, Eronarn. I am still trying to figure out how Symfony2 bundles should/could be integrated with Drupal modules.

They can't...
Seriously Drupal is build on some Symfony components not the entire symfony suite. We even removed the ModuleBundle file to make it visual that you can't install Symfony Bundles.

It's already possible to install Symfony bundles, so the only question is how difficult we want to make it. I think it's a bit short-sighted to take a walled garden approach to this question. What's the point of adopting Symfony code into core if we're going to prevent contrib from bringing in more of it without jumping through hoops?

Issue summary:View changes

code highlight

So what is a proposed way to use custom Bundles in contrib modules?

I don't will will support this given that Drupal does not use symfony fullstack at all.

The way to do this is to encourage the bundle author to make the code into a stand-alone library and the bundle just a bit of glue-code to attach to Symfony. Then make a Drupal module that depends on the same library using Composer. As a bonus, the code becomes more decoupled from Symfony which just about everyone in Symfonyland views as a good thing.

Since we're not using the Symfony Config component, there's likely very few bundles that would work without heavy modification anyway.