Stripping down framework-bundle #15748

johnknl · 2015-09-10T05:48:03Z

There are quite a number of dependencies in symfony/framework-bundle that should be optional.

symfony/asset

Don't need it when building an app without GUI.

symfony/security-core

Don't need when I don't want to include any sort of access control

symfony/security-csrf

Don't need it unless I have forms. Which is an optional requirement in the form (pardon the pun) of symfony/form. Even if you keep security-core, this should go unless you have symfony-form.

doctrine/annotations

I may not want to use annotations.

symfony/translation

I might not care about translations

symfony/stopwatch

Why is this not in require-dev?

symfony/templating

Again, without a GUI I don't really need this.

Anyone sharing this opinion or should I create my own symfony-minimal-framework-bundle if I want something less 'standard distribution'-like?

Possible solution would be extracting the other deps into something like symfony/core-framework-bundle and have symfony/framework-bundle depend on that. Then packages depending on framework-bundle would not suddenly have to deal with missing deps.

mvrhov · 2015-09-10T08:51:38Z

Well if it bothers you so much, then I recommend, that you build your app from empty composer.json.

jvasseur · 2015-09-10T08:53:45Z

@mvrhov The problem is, that if you need the framework bundle you will get all those dependencies that you don't necessarily need.

johnknl · 2015-09-10T09:31:05Z

@mvrhov: I will. But it will require me to create and test a bundle that integrates only the minimal component and use it place of framework-bundle. Which is a bit of a shame. I'd much rather have this gets solved 'the official way'.

theofidry · 2015-09-13T13:09:09Z

+1 for making those dependencies optionals, most of them are completely useless when building a REST API application for example.

@dunglas any opinion about this regarding ApiPlatform?

gnugat · 2015-09-13T14:19:26Z

@kleijnweb I was thinking about something similar recently, here's my conclusion on the matter.

Generally choices are made to make Symfony easier for new comers (e.g. Standard Edition including all Symfony components). If you have specific need, you can strip down the dependencies.
Every now and then, some people would ask for a minimalistic version (e.g. an empty edition) which is more appealing to "advanced" developers: they could add the specific dependencies they need and obtain a tailored app.

I'd be glad if the two solutions would be provided (e.g. a full-stack edition and a micro-edition) but I guess it makes things harder to maintain. On the other hand we, as a community, can provide our own editions.

Which led me to the same issue you're exposing: the FrameworkBundle itself is in the same position (embeds as much dependencies as possible to be more appealing to new comers). I've played a bit with the idea of creating a MicroFrameworkBundle that would do the strict minimum (HTTP, routing, events and caching), but community bundles usually set symfony/framework-bundle as their main dependency, even if they could set narrower dependencies (e.g. see this sample).

The alternative would be to extract the extra dependencies of FrameworkBundle into separate bundles, but that would be a big BC break (I guess).

I'm really looking forward to @weaverryan's talk at the up coming SymfonyCon to see if they're a solution for this.

johnknl · 2015-09-13T16:04:31Z

I'll take a crack at stripping it down myself when I find the time. From the looks of it, there really wouldn't be much "own code" left once you strip all the "niceties".

Leaving "Open" for anyone else's 2 cents.

jvasseur · 2015-09-14T08:55:53Z

I don't think stripping dependencies is a big problem for newcomers because they will most likely require the full stack symfony package (because it is what the standard edition do) and get them anyway.

johnknl · 2015-09-14T08:58:23Z

I agree, and as I suggested, you can keep the deps for framework-bundle intact by making it depends on a new, optional deps free, Composer package. No dependents would break.

sonu27 · 2015-09-14T10:27:49Z

+1 for this.

I agree, and as I suggested, you can keep the deps for framework-bundle intact by making it depends on a new, optional deps free, Composer package. No dependents would break.

stof · 2015-09-14T10:33:14Z

@jvasseur the issue is the BC break for third-party bundles. currently, they can all rely on the fact that FrameworkBundle provides the annotation_reader service for instance, and use it to read annotations instead of creating their own annotation reader which would then duplicate the work (because the cache would not be reused).
the same is true for a bunch of other services

johnknl · 2015-09-14T10:37:02Z

@stof So what are your thoughts on splitting it, keeping deps for framework-bundle intact but by way of a parent package?

derrabus · 2015-09-14T14:23:59Z

I like the idea of a Symfony edition with minimal dependencies.

@stof If BC is the problem, would stripping down the dependencies be an option for the master (aka 3.0) branch? The upgrade path for such applications would be very easy as they would simply need to add the dependencies they're missing.

stof · 2015-09-21T00:20:50Z

@derrabus but this would mean that we would have to create a ton of bundles providing the different core services you would remove from the core, to allow bundles to depend on them (while still having a single service, and not one per bundle needing the feature). This would not be a good developer experience IMO.

gnugat · 2015-09-21T09:29:59Z

@stof as suggested above, we could use FramewrokBundle as meta package. Developers looking for a tailored application wouldn't mind having to select each individual bundles.

derrabus · 2015-09-21T10:07:22Z

@stof I don't want to remove anything from core and neither would I create individual bundles for core components. I just think that it's pointless to have the e.g. Templating component pulled as a dependency of FrameworkBundle if I can disable templating completely. symfony/templating would be moved from the require section of composer.json to require-dev and suggest.

johnknl · 2015-09-25T06:13:48Z

For a more visual view of what happens when you require framework-bundle, see this diagram.

ghost · 2015-10-23T01:14:11Z

+1 for different new Symfony editions. 👍

johnknl · 2016-02-29T20:33:51Z

Been a while, anyone want to weigh in on this or should I consider it a lost cause?

gnugat · 2016-03-01T09:31:51Z

I've created a POC to see what it would look like: MicroFrameworkBundle

fabpot · 2016-09-28T04:43:28Z

I'm working on this one. First PR that goes this way is #20067

johnknl · 2016-09-28T05:56:15Z

That's good news :)

…cy on FrameworkBundle (fabpot) This PR was merged into the 3.2-dev branch. Discussion ---------- [FrameworkBundle] removed the Asset component dependency on FrameworkBundle | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/asset explicitly) | Deprecations? | no | Tests pass? | yes | Fixed tickets | #15748 partially | License | MIT | Doc PR | n/a Trying to reduce the number of required dependencies on FrameworkBundle. This PR removes the Asset component from the list. Commits ------- 1dd4e21 [FrameworkBundle] removed the Asset component dependency on FrameworkBundle

…pendency on FrameworkBundle (fabpot) This PR was merged into the 3.2-dev branch. Discussion ---------- [FrameworkBundle] removed the Translation component dependency on FrameworkBundle | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/translation explicitly) | Deprecations? | no | Tests pass? | yes | Fixed tickets | #15748 partially | License | MIT | Doc PR | n/a Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Translation component from the list. Commits ------- a496a2a [FrameworkBundle] removed the Translation component dependency on FrameworkBundle

…endency on FrameworkBundle (fabpot) This PR was merged into the 3.2-dev branch. Discussion ---------- [FrameworkBundle] removed the Templating component dependency on FrameworkBundle | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/templating explicitly) | Deprecations? | no | Tests pass? | yes | Fixed tickets | #15748 partially | License | MIT | Doc PR | n/a Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Templating component from the list. I made most of the work in previous version, so this change is really just about adding a good error message when templating is not enabled. For the record, this is also in the path of making possible to use Symfony with Twig without using the Templating component indirection (I think that this is in fact the last step). Commits ------- b3de62f [FrameworkBundle] removed the Templating component dependency on FrameworkBundle

…ty CSRF component dependencies on FrameworkBundle (fabpot) This PR was merged into the 3.2-dev branch. Discussion ---------- [FrameworkBundle] removed the Security Core and Security CSRF component dependencies on FrameworkBundle | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no (except for people using FrameworkBundle without requiring symfony/symfony which should be pretty rare; and fixing this is easy by adding symfony/security-core and symfony/security-csrf explicitly) | Deprecations? | no | Tests pass? | yes | Fixed tickets | #15748 partially | License | MIT | Doc PR | n/a Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Security Core and CSRF components from the list. Commits ------- d703784 [FrameworkBundle] removed the Security Core and Security CSRF component dependencies on FrameworkBundle

fabpot · 2016-09-28T17:30:55Z

From the list above:

~~1) symfony/asset~~ (#20067)
~~2) symfony/security-core~~ (#20075)
~~3) symfony/security-csrf~~ (#20075)
4) doctrine/annotations (#20097)
~~5) symfony/translation~~ (#20070)
6) symfony/stopwatch
~~7) symfony/templating~~ (#20072)

… dependency on FrameworkBundle (fabpot) This PR was merged into the 3.2-dev branch. Discussion ---------- [FrameworkBundle] removed the Doctrine Annotations lib dependency on FrameworkBundle | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | yes (fixing this is easy by adding doctrine/annotations explicitly) | Deprecations? | no | Tests pass? | yes | Fixed tickets | #15748 partially | License | MIT | Doc PR | n/a Another PR to reduce the number of required dependencies on FrameworkBundle. This PR removes the Doctrine annotations library from the list. Commits ------- c2d8356 [FrameworkBundle] removed the Doctrine Annotations lib dependency on FrameworkBundle

javiereguiluz added the RFC RFC = Request For Comments (proposals about features that you want to be discussed) label Jan 26, 2016

theofidry mentioned this issue Apr 28, 2016

Doctrine & Symfony tight coupling #18665

Closed

fabpot mentioned this issue Sep 28, 2016

[FrameworkBundle] removed the Asset component dependency on FrameworkBundle #20067

Merged

fabpot mentioned this issue Sep 29, 2016

[FrameworkBundle] removed the Doctrine Annotations lib dependency on FrameworkBundle #20097

Merged

fabpot closed this as completed Sep 30, 2016

xabbuh mentioned this issue Oct 11, 2016

explicitly list all required packages FriendsOfSymfony/FOSRestBundle#1589

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Stripping down framework-bundle #15748

Stripping down framework-bundle #15748

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!