…loader (weaverryan)This PR was merged into the 3.3-dev branch.Discussion----------[DI] Fixing missing "exclude" functionality from PSR4 loader| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | yes| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | none| License       | MIT| Doc PR        | TODOWhen the PSR4 loader was added in#21289,@nicolas-grekas said this:> given that glob() is powerful enough to include/exclude dirs, I removed the Test special exclusion (source:#21289 (comment))But, I don't believe that's true! [Glob is all about inclusion, not exclusion](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax) - the maximum you can exclude is a single character. Thus, I've marked this as a bug.My motivation came from upgrading KnpU to the new 3.3 DI stuff. We have many directories (40) in `src/`, and listing them all one-by-one in `resource:` is crazy - the `resource` line would be ~350 characters long and quite unreadable. What I really want to do is include *everything* and then exclude few directories. I tried to do this with `glob`, but it's not possible.This PR allows for something like this:```ymlservices:    _defaults:        public: false    # ...    AppBundle\:        resource: '../../src/AppBundle/*'        exclude: '../../src/AppBundle/{AppBundle.php,Entity}'```This works *beautifully* in practice. And even if I forget to exclude a directory - since the services are private -  **they're ultimately removed from the container anyways**. In fact, the *only* reason I need to exclude *anything* is because of the new "service argument resolver", which causes entities to not be properly removed from the compiled container.Thanks!Commits-------7d07f19 Allowing prototype/PSR4 service loading ability to exclude, because glob doesn't support this

…ices (weaverryan)This PR was merged into the 3.3-dev branch.Discussion----------Making *all* classes in src/AppBundle available as servicesHi guys!tl;dr; This makes *all* services from `src/AppBundle/` available as services by default.> This PR depends onsymfony/symfony#22680 andsymfony/symfony#22665If 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**     if you don't explicitly register a service as public and don't type-hint/reference it somewhere, it's removed from the final containerSo, 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 errorIn 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 insymfony/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