A bundle should never be standalone, only Bridges should. A bundle at least requires the Symfony Framework.

However, I can't find the dependency on templating.engines in any version of the TwigBundle. Can you maybe link to the code you found this dependency?

@wouterj The ExceptionListenerPass uses the templating.engines parameter to check if Twig is an enabled templating engine. The parameter itself is set in the DI extension of the FrameworkBundle.

@wouterj:

A bundle at least requires the Symfony Framework.

I beg to disagree. The SF docs suggest all over the place that some kind of voodoo magic allows the various components to be used independently from one another. I fail to see why bundles should be any different. If the docs are anything to go by, I should be able to cherry pick the SF kernel, a few other components, a bundle here and there, and start coding.

Reality is admittedly very different; indeed very sorry. The SF components nearly all depend on one another in hidden and undocumented ways, and the various bundles I've tried here and there depend on things that their composer.json files fail to mention. Namely, they pretty much all assume you're using the SF standard distribution. It's as if, for all its test coverage, SF components are never tested individually without the heaps of dependencies introduced by composer install without the --no-dev option.

Speaking for myself, my vendor folder went from having half a dozen SF components to the SF stack in full, plus the Framework bundle, just to be able to use Twig. And I'm pretty certain that by the time I'm done I'll have the SF standard in full, and simply rebase the entire project on top of that.

The point of this ticket, though, was not to whine that Twig shouldn't require things it doesn't need. It was to highlight that when you simply add the Twig bundle to your project's composer.json file, create a bare-metal AppKernel class to bootstrap the bundle, and run composer install --no-dev, you're currently in for an unwelcome surprise if you were hoping to call it a day and start using Twig.

As such, allow me to spell out the only two sane options:

1. Change the check in the ExceptionListenerPass so it compiles without raising an exception, e.g. presumably by calling $container->hasParameter() prior to getParameter(); or
2. Move the Framework bundle requirement from require-dev to require in the composer.json file.

@ddebernardy TwigBundle is not meant to be usable without FrameworkBundle, given that it provides the integration of Twig into the Symfony framework, and all the core of the Symfony framework is configured by FraemworkBundle.
However, you probably don't need TwigBundle if you only try to use Twig outside a fullstack project. TwigBundle does not provide Twig. It configures it and provide a few framework-specific extensions (extensions which depend only on components are in the Twig bridge)

If the docs are anything to go by, I should be able to cherry pick the SF kernel, a few other components, a bundle here and there, and start coding.

That you have to pick the kernel, components and a few bundles means it's no longer standalone. A bundle provides integration of a library into the framework, which is completely different from a standalone library which provides the library itself.

The SF docs suggest all over the place that some kind of voodoo magic allows the various components to be used independently from one another. [...] The SF components nearly all depend on one another in hidden and undocumented ways

This is not a voodoo magic. The components are created as a seperate library first and then they are integrated into the framework using the FrameworkBundle.

All dependencies they need to work are documented in the composer.json's require section. Some optional dependencies are documented in the suggest section.

If a dependency is missing from the composer.json file, or if the documentation lacks explaining things: Please create tickets for it or fix it.

the various bundles I've tried here and there depend on things that their composer.json files fail to mention. Namely, they pretty much all assume you're using the SF standard distribution. It's as if, for all its test coverage, SF components are never tested individually without the heaps of dependencies introduced by composer install without the --no-dev option.

You might have a good point here (never tested any bundle without the SE). However, 99,99% of all Symfony bundles are created by the community, there is nothing that Symfony's team can do about that. The same rule applies here as the previous paragraph: Open an issue in the bundle's tracker and it'll be fixed. The maintainers don't like it when people get irritated of their projects.

Speaking for myself, my vendor folder went from having half a dozen SF components to the SF stack in full, plus the Framework bundle, just to be able to use Twig. And I'm pretty certain that by the time I'm done I'll have the SF standard in full, and simply rebase the entire project on top of that.

My suggestion: Don't use bundles, if you don't want Symfony full stack, it doesn't make sense to use bundles. Use bridges and standalone components instead. (nothing prevents you from using normal PHP code in Symfony).

The components are created as a seperate library first and then they are integrated into the framework using the FrameworkBundle.

And hence the point I raised in most of the tickets I filed since I began using SF. The components might initially have been intended to be used as separate libraries at some distant point in the past. In practice nearly all of them depend on other components in hidden or undocumented manners.

If a dependency is missing from the composer.json file, or if the documentation lacks explaining things: Please create tickets for it or fix it.

Well... isn't that what I did here? ;-)

I never asked to be suggested to not use bundles in a project that makes use of an http kernel precisely for that reason.

The title says: "Add (or fix) the missing Dependency in Twig Bundle."

Potential solutions imho:

1. Add the Framework Bundle as a dependency to its composer.json; or
2. Add a call to hasParameter() before calling getParameter() in the offending compiler pass.

And hence the point I raised in most of the tickets I filed since I began using SF. The components might initially have been intended to be used as separate libraries at some distant point in the past. In practice nearly all of them depend on other components in hidden or undocumented manners.

Many components have optional dependencies on other components for some of their features (for instance, the Valdiator component will require the Config component if you want to load the mapping from files rather than defining the mapping in PHP directly). and the suggest section of the components are describing such optional dependencies

Well, the behvaiour is indeed a bit upsetting. Of course, you don't have to use the Frameworkbundle. So, it is correct to not have it as a dependency. But the compiler pass then shouldn't assume that the parameter a parameter is doesn't set itself and that is not set by one of its dependencies is present at all. What's wrong with checking if the parameter is set and otherwise remove the twig.exception_listener definition (like when the twig engine is not configured)?

Closing this ticket. The Twig bundle is not meant to be used standalone, the Twig bridge is. I've opened a PR trying to make the bundle less dependent on FrameworkBundle and be able to move things more in the bridge for better reusability.