This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Introduce "container.service_locator" tag, replaces ServiceLocatorArgument
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (master only)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I first started working on adding this new "container.service_locator" tag, so here it is.
It allows defining and dumping service-locator services properly, where it wasn't possible previously (you had to create a DI extension to do so.)
Then I realized that this allowed us to entirely drop `ServiceLocatorArgument` and replace it with the more flexible `ServiceClosureArgument`.
This makes things simpler overall, see diff stat.
Commits
-------
5d230b5871 [DI] Introduce "container.service_locator" tag, replaces ServiceLocatorArgument
* 3.2:
[Cache] cache/integration-tests is now compatible with phpunit namespaces
[FrameworkBundle] Fix translation dep constraint
[Workflow] Added more tests
[Cache] Enhance error reporting for FilesystemAdapter
* 3.2:
[VarDumper] Add missing isset() checks in some casters
[VarDumper] Add missing isset() checks in some casters
[Form] Choice type int values (BC Fix)
bumped Symfony version to 3.2.7
updated VERSION for 3.2.6
updated CHANGELOG for 3.2.6
Use PHPUnit 5.4 instead of 5.3
[PropertyAccess] Use ArrayAdapter in debug mode
bumped Symfony version to 3.2.6
updated VERSION for 3.2.5
updated CHANGELOG for 3.2.5
cached files rely on umask
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI][Router][DX] Invalidate routing cache when container parameters changed
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #21426
| License | MIT
| Doc PR | N/A
Supersedes #21443 but only for master.
Indeed, this implementation uses a new feature: a `ContainerParametersResource` which compares cached containers parameters (collected at some point, here by the `Router`) with current ones in the container.
On the contrary of the previous PR targeting 2.7, this will only invalidate routing cache when parameters actually used in the routes changed and will avoid always rebuilding the routing cache when the container is rebuilt, just to catch the edge case of someone modifying a parameter.
Commits
-------
fad4d9e2ef [DI][Router][DX] Invalidate routing cache when container parameters changed
This PR was squashed before being merged into the 3.3-dev branch (closes#21763).
Discussion
----------
[DI] Replace wildcard-based methods autowiring by `@required` annotation
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no (affects things that are only on master)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
While playing a bit with new features in master around DI configuration, several people around me got bitten by wildcard-based autowiring. The typical example is adding `autowire: [set*]` in `_defaults`: use that on `resource: ../src/Command/` PSR4-based loading and boom, `setApplication` and `setHelperSet` will now be wrongly called. You could tell me "of course, don't to that" - but being bitten so early on a master-only feature makes me really unconfident that this will be easy enough for people after the release.
If wildcard-based autowiring is removed, then I don't see anymore the need for allowing arrays as in `autowire: [setFoo,getBar]`. Moreover, this array syntax has a core DX issue: it's a dead end as far as the learning curve is concerned. You learn it, then when becoming a more advanced dev, someone teaches you that you'd better use another syntax: explicit wiring.
And in fact, we don't need it at all, because something else already exists: just declare a method call, but don't define its arguments. If `autowire: true` is set, then the AutowiringPass already fills in the holes. There is only one tweak required to make this work: don't autowire optional arguments for method calls - or that'd be a BC break. To my PoV that's even better: this makes autowiring fit a "do the minimum to make it work" strategy. A really good one to me.
But there is still an issue: wildcard-based autowiring fits a need. Namely, it allows one to define a convention (eg. `'set*'`), and have all such methods that follow the convention be autowired. To me, this looks like doing it reverse (the DI config should adapt to the code, not reverse). So, to fill this need, let the declaration be in the source: just use an annotation!
This PR adds support for the `@required` annotation, borrowed from the Spring framework:
https://www.tutorialspoint.com/spring/spring_required_annotation.htm
Using the annotation is totally optional of course. If you do, *and if autowiring is on*, then it'll be autowired. If you don't, nothing changes: do manual wiring.
Even when not using autowiring, the annotation is still a nice hint for the consumer of your classes: it tells the reader that this method needs to be called for correct instantiation - thus lowering one drawback of setter injection (discoverability).
The implementation of the annotation parsing is done using a few regexp (no dep on any complex parser) - and works with inheritance, by leveraging the `@inheritdoc` tag (the default behavior being to *not* inherit anything from parent methods).
All in all, looking at the diff stats, it makes everything simpler. Good sign, isn't it?
Commits
-------
f286fcc25f [DI] Replace wildcard-based methods autowiring by `@required` annotation
9081699980 Revert "minor #21315 [DI][FrameworkBundle] Show autowired methods in descriptors (ogizanagi)"
This PR was merged into the 3.3-dev branch.
Discussion
----------
[HttpKernel] Add a ContainerControllerResolver (psr-11)
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
Extracts the controller as service resolution from the framework bundle controller resolver in a `Symfony/Component/HttpKernel/Controller/Psr11ControllerResolver`, allowing you to use `HttpKernel` with your own psr-11 container.
Commits
-------
7bbae4159b [HttpKernel] Add a ContainerControllerResolver (psr-11)
This PR was merged into the 3.3-dev branch.
Discussion
----------
[Form] allow form types + form type extensions + form type guessers to be private services
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
This pull request is about making internal form services (aka form types, form type extensions and form type guessers) private. They used to be public until Symfony 3.2 for one valid reason: lazyness. However, Symfony 3.3 now comes with built-in mechanism to support effective lazy loading of private services with service locators and proxies.
This PR makes the `DependencyInjectionExtension` class of the `Form` component leverage these new DI component mechanisms. Form types, form type extensions and form type guessers can now be declared private as a best practice. We decided to make these services private as of Symfony 3.3 and of course it would break BC. But this PR introduces a BC layer using a Symfony trick to keep internal form services public. The service container currently has a known issue where private services are not really private if they're referenced by at least two other services in the container. We use this trick to maintain the legacy services public even though the new API relies on private ones. This trick is done thanks to the `deprecated.form.registry` and `deprecated.form.registry.csrf` fake services that will be removed in Symfony 4.0.
Commits
-------
600e75ce88 [Form] use new service locator in DependencyInjectionExtension class, so that form types can be made private at some point.
* 3.2:
Revamped the README file
Fix missing namespace in AddConstraintValidatorPassTest
[SecurityBundle] simplified code
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
* 2.8:
Revamped the README file
Fix missing namespace in AddConstraintValidatorPassTest
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
* 2.7:
Revamped the README file
Fix missing namespace in AddConstraintValidatorPassTest
[ExpressionLanguage] Registering functions after calling evaluate(), compile() or parse() is not supported
* 3.2:
Refactored other PHPUnit method calls to work with namespaced PHPUnit 6
Refactored other PHPUnit method calls to work with namespaced PHPUnit 6
Further refactorings to PHPUnit namespaces
resolve parameters in definition classes
* 2.8:
Refactored other PHPUnit method calls to work with namespaced PHPUnit 6
Further refactorings to PHPUnit namespaces
resolve parameters in definition classes
This PR was merged into the 2.8 branch.
Discussion
----------
Refactored other PHPUnit method calls to work with namespaced PHPUnit 6
| Q | A
| ------------- | ---
| Branch? | 2.8
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | -
| License | MIT
| Doc PR | -
Continued work to make Symfony PHPUnit 6 compatible.
Commits
-------
dbe8898 Refactored other PHPUnit method calls to work with namespaced PHPUnit 6
This PR was squashed before being merged into the 2.7 branch (closes#21688).
Discussion
----------
Further refactorings to PHPUnit namespaces
| Q | A
| ------------- | ---
| Branch? | 2.7
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | -
| License | MIT
| Doc PR | -
Continued work to make Symfony PHPUnit 6 compatible
Commits
-------
de8106f Further refactorings to PHPUnit namespaces