feature #1070 Making *all* classes in src/AppBundle available as services (weaverryan)

fabpot · fabpot · commit 49b94d897aa2 · 2017-05-14T09:27:09.000-07:00
This PR was merged into the 3.3-dev branch. Discussion ---------- Making *all* classes in src/AppBundle available as services Hi guys! tl;dr; This makes *all* services from `src/AppBundle/` available as services by default. > This PR depends on symfony/symfony#22680 and symfony/symfony#22665 If this seems crazy to you, it's actually not: it's almost exactly how the system already works :). By registering *all* of `src/AppBundle`, we will almost undoubtedly register some classes that should *not* be services. But, because the services are private, unless you actually reference them somewhere, they're simply removed. In other words, **we're not *really* importing all services from `src/AppBundle`, we're making all classes in `src/AppBundle` *available* to be used as services**. Today, thanks to autowiring, if you type-hint a class that is *not* registered as a service, autowiring registers it for you. That means that **the total number of services in the compiled container today versus after this change will be the same**. * **Today** if you don't explicitly register a service as public and don't type-hint/reference it anywhere, it's never added. * **After**&nbsp;&nbsp; if you don't explicitly register a service as public and don't type-hint/reference it somewhere, it's removed from the final container So, the end result is the same as now. And there are a number of advantages: **PROS** * A) **Better developer experience: when a dev creates a new directory**, they don't need to remember to go into `services.yml` and add it. The original directories we added to the SE were a random "guess"... which should feel weird. I think it's because that approach is flawed in general. * B) **Less WTF and better DX with `autoconfigure`**: now, if I create a new class that extends `Twig_Extension` but forget to import my `Twig` directory, then my extension won't work. After this, we'll find it for sure. * C) **Clearer for the documentation**: before this change, in many places, we need to say "go to services.yml and add this new directory to your import... unless you already have it... and don't make your line look exactly like our's - you're probably also importing other directories" * D) **We could deprecating the "autowire auto-registration" code in 3.4** (i.e. when autowiring automatically registers a private services if no instance exists in the container). That means less magic: this is actually *more* explicit. This could be awesome - we could remove some "hacky" code (e.g. symfony/symfony#22306). And, if you type-hinted an `Entity` (for example) in autowiring, instead of the container creating a service for you, it can give you a clear error In theory, the CON is that this will slow down the container rebuilding as more services are added to `ContainerBuilder` (before being removed later). On one project, I compared the build time without importing everything (138 services added from `src/`) versus importing everything (200 services dded from `src/`). The build time difference was negligible - maybe 10ms difference (both were around 950ms). Btw, the `exclude` key added in symfony/symfony#22680 is almost not even needed, since unused services are simply removed. But, currently, the `Entity` directory is an exception due to the new "argument resolver" trying to see if it can wire those as services. That could be fixed in the future. But `exclude` is kind of nice, if you want to explicitly safe-guard someone from accidentally type-hinting something from that directory. Again, that's *better* than now... where we will *always* auto-register an Entity if you type-hint it. Cheers! Commits ------- 47d3561 Making *all* services in src/AppBundle available as services
diff --git a/app/config/services.yml b/app/config/services.yml
@@ -8,18 +8,28 @@ services:
     _defaults:
         # automatically injects dependencies in your services
         autowire: true
-        # automatically registers your services as commands, form types, etc.
+        # automatically registers your services as commands, event subscribers, etc.
         autoconfigure: true
         # this means you cannot fetch services directly from the container via $container->get()
         # if you need to do this, you can override this setting on individual services
         public: false
 
-    # loads services from whatever directories you want (you can add directories!)
+    # makes classes in src/AppBundle available to be used as services
     # this creates a service per class whose id is the fully-qualified class name
     AppBundle\:
-        resource: '../../src/AppBundle/{Command,Form,EventSubscriber,Twig,Security}'
+        resource: '../../src/AppBundle/*'
+        # you can exclude directories or files
+        # but if a service is unused, it's removed anyway
+        exclude: '../../src/AppBundle/{Entity,Repository}'
 
+    # controllers are imported separately to make sure they're public
+    # and have a tag that allows actions to type-hint services
     AppBundle\Controller\:
         resource: '../../src/AppBundle/Controller'
         public: true
         tags: ['controller.service_arguments']
+
+    # add more services, or override services that need manual wiring
+    # AppBundle\Service\ExampleService:
+    #     arguments:
+    #         $someArgument: 'some_value'
