* 3.4:
Made some SecurityBundle tests case-insensitive to prepare for future Symfony versions
[Console] Added a case-insensitive fallback for console command names
fix merge
[DI] Fix dumping abstract with YamlDumper
restrict reflection doc block
[DI] Fix YamlDumper not dumping abstract and autoconfigure
* 3.4: (23 commits)
[DI] Allow dumping inline services in Yaml
fixed CS
[2.8] Modify 2.8 upgrade doc - key option is deprecated.
Fix lock failling test
[Debug] Correctly detect methods not from the same vendor
[HttpKernel] Deprecated commands auto-registration
Fix minors in date caster
[FrameworkBundle] Catch Fatal errors in commands registration
[Debug] Detect internal and deprecated methods
[Profiler] Make the validator toolbar item consistent with the form one
[DebugBundle] Reword an outdated comment about var dumper wiring
updated CHANGELOG
[HttpFoundation] Remove length limit on ETag
[DI] Fix some docblocks
[DI] Fix some docblocks
Fixed the exception page design in responsive mode
[Console] Log exit codes as debug messages instead of errors
Fixed UPGRADE-4.0 about Container::set
Ignore memcached missing key error on dession destroy
[FrameworkBundle] Allow micro kernel to subscribe events easily
...
This PR was squashed before being merged into the 3.4 branch (closes#22187).
Discussion
----------
[DependencyInjection] Support local binding
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/22167, #23718
| License | MIT
| Doc PR |
> A great idea came out on Slack about local bindings.
> We could allow injecting services based on type hints on a per service/file basis:
> ```yml
> services:
> _defaults:
> bind:
> BarInterface: '@usual_bar'
>
> Foo:
> bind:
> BarInterface: '@alternative_bar'
> $quz: 'quzvalue'
> ```
>
> This way, `@usual_bar` will be injected in any parameter type hinted as `BarInterface` (in a constructor or a method signature), but only for this service/file.
> Note that bindings could be unused, giving a better solution than https://github.com/symfony/symfony/pull/22152 to https://github.com/symfony/symfony/pull/21711.
>
> As named parameters are usable in arguments, bindings could be usable in arguments too:
> ```yml
> services:
> Foo:
> arguments:
> BarInterface: '@bar'
> ```
~Named parameters aren't supported yet.~
Edit:
> Note that bindings could be unused
Current behavior is throwing an exception when a binding is not used at all, in no services of a file if it was inherited from `_defaults` or in no services created from a prototype.
It will pass if the bindings are all used in at least one service.
Commits
-------
81f2652 [DependencyInjection] Support local binding
This PR was squashed before being merged into the 3.4 branch (closes#22913).
Discussion
----------
[Yaml] Deprecate tags using colon
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
Using a colon in a tag doesn't look like yaml and causes trouble (see https://github.com/symfony/symfony/pull/22878), so I propose to just deprecate these tags in favor of more consistent tags.
```yml
- !php/const:PHP_INT_MAX
- !php/object:O:30:"Symfony\Component\Yaml\Tests\A":1:{s:1:"a";s:3:"foo";}
```
would become
```yml
- !php/const PHP_INT_MAX
- !php/object O:30:"Symfony\Component\Yaml\Tests\A":1:{s:1:"a";s:3:"foo";}
```
Commits
-------
9815af3 [Yaml] Deprecate tags using colon
* 3.4:
[Yaml] Recommend using quotes instead of PARSE_KEYS_AS_STRINGS
[DependencyInjection] Deprecate autowiring service auto-registration
Removed useless argument $definition
[DI] Generate shorter method names for class-based ids
Fix comment
[Config] Fix checking class existence freshness
bumped Symfony version to 3.3.7
updated VERSION for 3.3.6
updated CHANGELOG for 3.3.6
Autoconfigure instances of ArgumentValueResolverInterface
Deprecate Filesystem/LockHandler
improve sql explain table display
Bump minimal PHP version to ^5.5.9|>=7.0.8
* 3.4:
[DI] Remove unused props from the PhpDumper
[VarDumper] Keep and reuse array stubs in memory
[DI][ProxyManager] Pass the factory code to execute to DumperInterface::getProxyFactoryCode()
[Workflow] Adding workflow name to the announce event
[ProxyManager] Cleanup fixtures
[Console][WebServerBundle] Use "exec" when possible
[Debug] HTML-escape array key
Add some phpdocs for IDE autocompletion and better SCA
Fixed typo in docblock
* 3.4:
minor fix
[DI] Make dumped docblocks less verbose
[VarDumper] Dont use Stub objects for arrays
[Form] Allow pass filter callback to delete_empty option.
* 3.4:
[DI] use assertStringEqualsFile when possible
[VarDumper] Adapt to php 7.2 changes
[DI] Fix using private services in expressions
[Form][TwigBridge] Don't render _method in form_rest() for a child form
[Form] Static call TimezoneType::getTimezones
Removed references for non existent validator constraints
Suggest using quotes instead of Yaml::PARSE_KEYS_AS_STRINGS
[DI] Fix test
[Cache] Handle unserialization failures for Memcached
Remove unused prop + added @deprecated
Remove unused mocks/vars
feature #22317 [Console] Make SymfonyQuestionHelper::ask optional by default (ro0NL)
[DoctrineBridge][PropertyInfo] Added support for Doctrine Embeddables
[Validator] Fix IbanValidator for ukrainian IBANs
Router: allow HEAD method to be defined first
[WebProfilerBundle] Display trace and context in the logger profiler
Fixing a bug where if a core class was autowired, autowiring tried to autowire optional args as if they were required
* 3.3:
[DI] use assertStringEqualsFile when possible
[VarDumper] Adapt to php 7.2 changes
[DI] Fix using private services in expressions
[Form][TwigBridge] Don't render _method in form_rest() for a child form
[Form] Static call TimezoneType::getTimezones
Removed references for non existent validator constraints
Suggest using quotes instead of Yaml::PARSE_KEYS_AS_STRINGS
[DI] Fix test
[Cache] Handle unserialization failures for Memcached
Remove unused prop + added @deprecated
Remove unused mocks/vars
[DoctrineBridge][PropertyInfo] Added support for Doctrine Embeddables
[Validator] Fix IbanValidator for ukrainian IBANs
Router: allow HEAD method to be defined first
[WebProfilerBundle] Display trace and context in the logger profiler
Fixing a bug where if a core class was autowired, autowiring tried to autowire optional args as if they were required
* 3.2:
[DI] use assertStringEqualsFile when possible
[VarDumper] Adapt to php 7.2 changes
[DI] Fix using private services in expressions
[Form][TwigBridge] Don't render _method in form_rest() for a child form
[Form] Static call TimezoneType::getTimezones
Removed references for non existent validator constraints
Remove unused mocks/vars
[DoctrineBridge][PropertyInfo] Added support for Doctrine Embeddables
[Validator] Fix IbanValidator for ukrainian IBANs
* 3.4: (22 commits)
Fix lazy commands registration
[TwigBridge] deprecate TwigRenderer
[FrameworkBundle] Set default public directory on install assets
[Security] Fix wrong term in UserProviderInterface
[HttpFoundation] Set meta refresh time to 0 in RedirectResponse content
disable inlining deprecated services
[Stopwatch] Fix precision for root section
[Cache] add constructor docblocks for clarity
[WebServerBundle] allowed public/ root directory to be auto-discovered along side web/
[WebServerBundle] remove duplicate code
[SecurityBundle] Clarify deprecation in UserPasswordEncoderCommand::getContainer
[Profiler][Validator] ValidatorDataCollector: use new DataCollector::getCasters() method
[Profiler] Fix data collector getCasters() call
[VarDumper] Added setMinDepth to VarCloner
remove symfony/process suggestion
[DI] Remove unused dynamic property
[Cache] add constructor docblocks for clarity
[Security] validate empty passwords again
[Process] Fixed issue between process builder and exec
non-conflicting anonymous service ids across files
...
* 3.3:
[Profiler] Fix data collector getCasters() call
remove symfony/process suggestion
[DI] Remove unused dynamic property
[Process] Fixed issue between process builder and exec
non-conflicting anonymous service ids across files
This PR was merged into the 4.0-dev branch.
Discussion
----------
[DI] Remove remaining deprecated features
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
* removed autowiring services based on the types they implement
* removed the `DefinitionDecorator` class, replaced by `ChildDefinition`
* removed the `AutowireServiceResource` class and related `AutowirePass::createResourceForClass()` method
* removed `LoggingFormatter`, `Compiler::getLoggingFormatter()` and `addLogMessage()` class and methods, use the `ContainerBuilder::log()` method instead
* removed `FactoryReturnTypePass`
* removed `ContainerBuilder::addClassResource()`, use the `addObjectResource()` or the `getReflectionClass()` method instead.
* removed support for top-level anonymous services
* removed silent behavior for unused attributes and elements
* Removed the "framework.validation.cache" configuration option. Configure the "cache.validator" service under "framework.cache.pools" instead.
Commits
-------
4bd7b921f4 [DI] Remove remaining deprecated features
* 3.4:
Add TokenProcessor
[DI] Handle root namespace in service definitions
Add support for command lazy-loading
Use rawurlencode() to transform the Cookie into a string
[TwigBundle] Added a RuntimeExtensionInterface to take advantage of autoconfigure
[Process] Fix parsing args on Windows
Add exculde verbosity test
[HttpKernel][VarDumper] Truncate profiler data & optim perf
[DI] Allow imports in string format for YAML
[Validator] Allow to use a property path to get value to compare in comparison constraints
[Security] Fix authentication.failure event not dispatched on AccountStatusException
add option to define the access decision manager
Add support for doctrin/dbal 2.6 types
* 3.4: (83 commits)
add missing version attribute
Show exception is checked twice in ExceptionController of twig
allow SSI fragments configuration in XML files
Display a better error message when the toolbar cannot be displayed
[SecurityBundle] Add user impersonation info and exit action to the profiler
render hidden _method field in form_rest()
Add Doctrine Cache to dev dependencies to fix failing unit tests.
return fallback locales whenever possible
Fix Predis client cluster with pipeline
[Dotenv] Test load() with multiple paths
[Console] Fix catching exception type in QuestionHelper
Improved the exception page when there is no message
[WebProfilerBundle] Eliminate line wrap on count columnt (routing)
[Profiler][Validator] Add a validator panel in profiler
[Validator] replace hardcoded service id
[Routing] Fix XmlFileLoader exception message
Remove duplicate changelog entries
[DI] Dedup tags when using instanceof/autoconfigure
[Translation] Fix FileLoader::loadResource() php doc
[Serializer] Fix workaround min php version
...
* 3.4:
Fix optional cache warmers are always instantiated whereas they should be lazy-loaded
add some \ on PHP_VERSION_ID for 2.8
[Di] Remove closure-proxy arguments
[PropertyInfo][DoctrineBridge] The bigint Doctrine's type must be converted to string
* 3.3:
Fix optional cache warmers are always instantiated whereas they should be lazy-loaded
add some \ on PHP_VERSION_ID for 2.8
[Di] Remove closure-proxy arguments
[PropertyInfo][DoctrineBridge] The bigint Doctrine's type must be converted to string
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] Deprecate XML services without ID
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no, confusing though
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
On slack someone had a issue with class named services;
> So, probably should have done this sooner, I stepped through with a debugger and it looks like \Symfony\Component\DependencyInjection\Loader\XmlFileLoader::processAnonymousServices assigns a sha256 to services that don't have any IDs
> When my manually wired service is registered, it has an ID that looks like 1_344b468f6069ffe8c32092409d99c59abc218f41071ce4c4230c198876129bc0, so it doesn't override the auto-loaded one
> I swear I read that IDs default to the class name now...
The fix was easy; doing `<service id="ClassName"/>` instead of `<service class="ClassName"/>`. However the thing is... i made the exact same mistake trying to reproduce 😅
I think given the recent developments (dropping type based autowiring and class named services) it makes sense to force XML service to specify an ID attribute (the top level ones). This would be consistent with YAML and PHP as well.
Fixing deprecations is also easy, just change `class` attribute to `id` like i've done for the frameworkbundle in this PR.
Any thoughts?
Commits
-------
b8c68da010 [DI] Deprecate XML services without ID
* 3.4:
[HttpFoundation] Add Request::HEADER_X_FORWARDED_AWS_ELB const
[DI] Avoid private call to Container::has()
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
[Yaml] parse PHP constants in mapping keys
don't call getTrustedHeaderName() if possible
Fix file perms
Fixed filename in help text for update-data.php
* 3.2:
[DI] Avoid private call to Container::has()
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 2.8:
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 2.7:
Fixing missing abstract attribute in XmlDumper
[Form] Remove DateTimeToStringTransformer $parseUsingPipe option
Fix file perms
Fixed filename in help text for update-data.php
* 3.4:
[DI] prepare for signature change in 4.0
[DI] Add missing deprecation on Extension::getClassesToCompile
[Lock] Re-add the Lock component in 3.4
[Routing] remove an unused routing fixture
[Yaml] fix multiline block handling
[WebProfilerBundle] Fix sub-requests display in time profiler panel
[FrameworkBundle] Handle project dir in cache:clear command
[WebServerBundle] Mark ServerCommand as internal
[DI] Fix autowire error for inlined services
Close PHP code in phpt file
[Profiler][VarDumper] Fix searchbar css when in toolbar
Prevent auto-registration of UserPasswordEncoderCommand
[Process] Fixed incorrectly escaping arguments on Windows when inheritEnvironmentVariables is set to false
avoid double blanks while rendering form attributes
use getProjectDir() when possible
[PhpUnitBridge] add a changelog file
[FrameworkBundle][Validator] Deprecate passing validator instances/aliases over using the service locator
This PR was squashed before being merged into the 4.0-dev branch (closes#22763).
Discussion
----------
[DI] Remove deprecated isFrozen()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | should be
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!--highly recommended for new features-->
See #19673
Test failure seems unrelated.
Commits
-------
04b39a3 [DI] Remove deprecated isFrozen()
This PR was merged into the 3.3-dev branch.
Discussion
----------
Fixing a bug where abstract classes were wired with the prototype loader
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | n/a
The prototype/PSR-4 loader currently tries to wire abstract classes. The problem is if, for example, you have, for example:
```php
abstract class BaseCommand extends Command
{
}
```
If this is registered as a service, and you have `autoconfigure`, then the console `Application` will try to use this a command.
Was there some reason abstract classes were originally allowed to be registered as services with the PSR4/prototype loader? I don't know if there is a real use-case for registering abstract classes. If you wanted to use that service as a parent service... then you'll probably be configuring it yourself anyways. We could also fix this by changing all tags compiler passes to skip classes that are abstract... *if* there is a use-case for Abstract classes being auto-registered.
Cheers!
Commits
-------
5326bab10a Fixing a bug where abstract classes were wired
* 3.2:
[Console] Do not duplicate Helper::strlen() code
[FrameworkBundle] Adding the extension XML
[Form] Minor: Fix comment in ChoiceType
[FrameworkBundle] AbstractConfigCommand: do not try registering bundles twice
fixed CS
fixed CS
[DI] Fix PhpDumper blank lines around namespace
fixed CS
[Workflow] fix use directives
[Workflow] Move twig extension registration to twig bundle
Filesystem: annotate the one network test with a "network" group.
[DependencyInjection] Don't store default deprecation template in every service definition instance
* 2.8:
fixed CS
[DI] Fix PhpDumper blank lines around namespace
fixed CS
Filesystem: annotate the one network test with a "network" group.
[DependencyInjection] Don't store default deprecation template in every service definition instance
Now that inherit_tags has been removed, 3.3 has the same functionality as 3.2: tags
are *never* cascaded from parent to child (but you tags do inherit from defaults
to a service and instanceof to a service).
This PR was merged into the 3.3-dev branch.
Discussion
----------
Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes (removing risky behavior)
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | see #22530
| License | MIT
| Doc PR | n/a
This PR *prohibits* using `autoconfigure`, `_instanceof` and `_defaults` for ChildDefinition.
Additionally, I added many "integration" test cases: we need to test and prove all edge cases. These are in the `integration/` directory: the `main.yml` file is parsed and compared to `expected.yml`. Both are in YAML to ease comparing the before/after. We need to check these out and make sure they're right and we're not missing anything else.
This PR removes MANY of the "wtf" cases, but there are still 4 that I know of... and of course they all deal with parent-child stuff :).
A) [MAJOR] [autoconfigure_parent_child_tags](https://github.com/symfony/symfony/pull/22563/files#diff-fd6cf15470c5abd40156e4e7dc4e7f6d) `instanceof` tags from autoconfigure are NEVER applied to the child (you can't set `autoconfigure` directly on a Child, but you still can set it on a parent and inherit it... sneaky). We could throw an Exception I suppose to prevent this `autoconfigure` from cascading from parent to child... but it's tricky due to `instanceof`.
B( [MAJOR] [instanceof_parent_child](https://github.com/symfony/symfony/pull/22563/files#diff-14666e9a25322d44b3c2c583b6814dc2) `instanceof` tags that are applied to the parent, are not applied to the child. Again, you can't set `instanceof` directly on a Child, but you *can* set it on a parent, and have that cascade to the child. Like before, we could maybe throw an exception to prevent this.
C) [MINOR] ([autoconfigure_child_not_applied](https://github.com/symfony/symfony/pull/22563/files#diff-3372a1dcaf3af30d14a7d0a6c8bfa988)) automatic `instanceof` will not be applied to the child when the parent class has a different (non-instanceof-ed) class. If we could throw an exception for (A), then it would cover this too.
D) `_tags` from defaults are never used (unless you have inherit_tags) - fixed in #22530
A, B & C are effectively caused by there being a "sneaky" way to re-enable `autoconfigure` and `instanceof` for ChildDefinition... which opens up wtf cases.
## Wait, why not support `_defaults`, `autoconfigure` and `_instanceof` for child definitions?
1 big reason: reduction of wtf moments where we arbitrarily decide override logic. PLUS, since `_defaults`, `instanceof` and `autoconfigure` *are* applied to parent definitions, in practice (other than tags), this makes no difference: the configuration will still pass from parent down to child.
Also, using parent-child definitions is already an edge case, and this *simply* prevents *just* those services from using the new features.
## Longer reasons why
The reason behind this is that parent-child definitions are a different mechanism for "inheritance"
than `_instanceof` and `_defaults`... creating some edge cases when trying to figure out which settings "win". For example:
```yml
# file1.yml
services:
_defaults:
public: false
ChildService:
parent: parent_service
# file2.yml
services:
_defaults:
public: true
ParentService: ~
```
Is `ChildDefinition` `public: true` (so the parent
overrides the child, even though it only came from _defaults) or `public: false` (where
the child wins... even though it was only set from its _defaults)?
Or, if ParentService is explicitly set to `public: true`, should that override the `public: false` of ChildService (which it got from its `_defaults`)? On one hand, ParentService is being explicitly
set. On the other hand, ChildService is explicitly in a file settings `_defaults` `public: false`
There's no correct answer.
There are also problems with `_instanceof`. The importance goes:
> defaults < instanceof < service definition
But how do parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
Commits
-------
a943b96d42 Not allowing autoconfigure, instanceofConditionals or defaults for ChildDefinition
Also, not allowing arguments or method calls for autoconfigure. This is a safety
mechanism, since we don't have merging logic. It will allow us to add this in the
future if we want to.
The reason is that parent-child definitions are a different mechanism for "inheritance"
than instanceofConditionas and defaults... creating some edge cases when trying to
figure out which settings "win". For example:
Suppose a child and parent definitions are defined in different YAML files. The
child receives public: false from its _defaults, and the parent receives public: true
from its _defaults. Should the final child definition be public: true (so the parent
overrides the child, even though it only came from _defaults) or public: false (where
the child wins... even though it was only set from its _defaults). Or, if the parent
is explicitly set to public: true, should that override the public: false of the
child (which it got from its _defaults)? On one hand, the parent is being explicitly
set. On the other hand, the child is explicitly in a file settings _defaults public
to false. There's no correct answer.
There are also problems with instanceof. The importance goes:
defaults < instanceof < service definition
But how does parent-child relationships fit into that? If a child has public: false
from an _instanceof, but the parent explicitly sets public: true, which wins? Should
we assume the parent definition wins because it's explicitly set? Or would the
_instanceof win, because that's being explicitly applied to the child definition's
class by an _instanceof that lives in the same file as that class (whereas the parent
definition may live in a different file).
Because of this, @nicolas-grekas and I (we also talked a bit to Fabien) decided that
the complexity was growing too much. The solution is to not allow any of these
new feature to be used by ChildDefinition objects. In other words, when you want some
sort of "inheritance" for your service, you should *either* giving your service a
parent *or* using defaults and instanceof. And instead of silently not applying
defaults and instanceof to child definitions, I think it's better to scream that it's
not supported.
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Fix inlining conflict by restricting IteratorArgument to Reference[]
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
`Reference` found in `ArgumentInterface::getValue()` are currently not inlined.
While trying to do so (hint: I failed), I noticed that the current code is broken for `IteratorArgument` which can contain anonymous `Definition` for now, which are then not inlined correctly.
This PR restricts `IteratorArgument` to arrays of `Reference`, and improves a few related things found while doing it.
(fabbot failure is false positive)
Commits
-------
4d3dce1c0f [DI] Fix inlining conflict by restricting IteratorArgument to Reference[]
This PR was squashed before being merged into the 3.3-dev branch (closes#22234).
Discussion
----------
[DI] Introducing autoconfigure: automatic _instanceof configuration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes (mostly, a continuation of a new feature)
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/issues/7538
This is a proposal to allow the user to opt into some automatic `_instanceof` config. Suppose I want to auto-tag all of my voters and event subscribers
```yml
# current
services:
_defaults:
autowire: true
_instanceof:
Symfony\Component\Security\Core\Authorization\Voter\VoterInterface:
tags: [security.voter]
Symfony\Component\EventDispatcher\EventSubscriberInterface:
tags: [kernel.event_subscriber]
# services using the above tags
AppBundle\Security\PostVoter: ~
AppBundle\EventListener\CheckRequirementsSubscriber: ~
```
If I'm registering a service with a class that implements `VoterInterface`, when would I ever *not* want that to be tagged with `security.voter`? Here's the proposed code:
```yml
# proposed
services:
_defaults:
autowire: true
autoconfigure: true
# services using the auto_configure_instanceof functionality
AppBundle\Security\PostVoter: ~
AppBundle\EventListener\CheckRequirementsSubscriber: ~
```
The user must opt into this and it only applies locally to this configuration file. It works because each enabled bundle would have the opportunity to add one or more "automatic instanceof" definitions - e.g. SecurityBundle would add the `security.voter` instanceof config, FrameworkBundle would add the `kernel.event_subscriber` instanceof config, etc.
For another example, you can check out the proposed changes to `symfony-demo` - symfony/symfony-demo#483 - the `_instanceof` section is pretty heavy: 81694ac21e/app/config/services.yml (L20)
Thanks!
Commits
-------
18627bf9f6 [DI] Introducing autoconfigure: automatic _instanceof configuration
* 3.2:
move provider after test
update dataProvider function name
cast substr result to string and remove empty function use
rename dataset provider
Add a test to prevent future regressions
Switch to `empty` native function to check emptiness
remove non relevant test case
Switch to `is_string` native method
Remove unnecessary parentheses
Add a test case to prevent future regressions
Move empty condition in return statement
Use LF line separator
fix coding standard to comply with fabbot
Remove malformed EmailValidatorTest + Update UrlValidator test
Add empty check on host in other methods + add unit tests
[Validator] Allow checkMX() to return false when $host is empty
[DI] Prevent AutowirePass from triggering irrelevant deprecations
[DI] Fix the xml schema
[Translation] avoid creating cache files for fallback locales.
* 2.8:
move provider after test
update dataProvider function name
cast substr result to string and remove empty function use
rename dataset provider
Add a test to prevent future regressions
Switch to `empty` native function to check emptiness
remove non relevant test case
Switch to `is_string` native method
Remove unnecessary parentheses
Add a test case to prevent future regressions
Move empty condition in return statement
Use LF line separator
fix coding standard to comply with fabbot
Remove malformed EmailValidatorTest + Update UrlValidator test
Add empty check on host in other methods + add unit tests
[Validator] Allow checkMX() to return false when $host is empty
[DI] Prevent AutowirePass from triggering irrelevant deprecations
[DI] Fix the xml schema
[Translation] avoid creating cache files for fallback locales.
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Add "by-id" autowiring: a side-effect free variant of it based on the class<>id convention
| 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 PR adds a new autowiring mode, based only on the class <> id convention.
This way of autowiring is free from any conflicting behavior, which is what I was looking for to begin with.
The expected DX is a bit more involving than the current way we do autowiring. But it's worth it to me, because it's plain predictable - a lot less "magic" imho.
So in this mode, for each `App\Foo` type hint, a reference to an "App\Foo" service will be created. If no such service exists, an exception will be thrown. To me, this opens a nice DX: when type hinting interfaces (which is the best practice), this will tell you when you need to create the explicit interface <> id mapping that is missing - thus encourage things to be made explicit, but only when required, and gradually, in a way that will favor discoverability by devs.
Of course, this is opt-in, and BC. You'd need to do eg in yaml: `autowire: by_id`.
For consistency, the current mode (`autowire: true`) can be configured using `autowire: by_type`.
Commits
-------
c298f2a90c [DI] Add "by-id" autowiring: a side-effect free variant of it based on the class<>id convention
* 3.2:
[Yaml] CS
[DI] Fix PhpDumper generated doc block
#20411 fix Yaml parsing for very long quoted strings
[Workflow] add Phpdoc for better IDE support
fix package name in conflict rule
improve message when workflows are missing
[Doctrine Bridge] fix priority for doctrine event listeners
Use PHP functions as array_map callbacks when possible
[Validator] revert wrong Phpdoc change
Use proper line endings
* 2.8:
[DI] Fix PhpDumper generated doc block
#20411 fix Yaml parsing for very long quoted strings
[Doctrine Bridge] fix priority for doctrine event listeners
Use PHP functions as array_map callbacks when possible
[Validator] revert wrong Phpdoc change
Use proper line endings
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Remove skipping magic for autowired methods
| 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 | -
Wildcard based autowiring made it required to auto-skip methods that were not wireable.
Now that things need to be explicit (ie via the `@required` annotation, or via configuration), this "automagic" behavior is not required anymore.
Since it can lead to wtf moments ("*I* did *put that `@required` annotation, why is it ignored by autowiring?*"), I think we should remove it.
This also fixes another issue where configured method calls had their optional arguments wired, while we want only the constructor's to behave as such.
Commits
-------
a6bfe1c [DI] Remove skipping magic for autowired methods
This PR was squashed before being merged into the 3.3-dev branch (closes#21937).
Discussion
----------
[DependencyInjection] Handle void return types in closure-proxy
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | N/A
| License | MIT
| Doc PR | N/A
I recently got an error when registering an event listener that specifies a `void` return type. Dumping the container generates a closure proxy that always returns a value, which then conflicts with the return type hint.
E.G the following code is generated (some class names removed for readability)
```
$instance->addListener('kernel.view', /** @closure-proxy ... */ function (...\GetResponseForControllerResultEvent $event): void {
return ${($_ = isset($this->services[listener']) ? $this->services['listener'] : $this->get('listener')) && false ?: '_'}->onKernelView($event);
}, 128);
```
This then causes the error `A void function must not return a value in ...`
So void return types should be handled by removing the `return` inside the closure
Commits
-------
a5c5ad1 [DependencyInjection] Handle void return types in closure-proxy
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
----------
Fix DI test
| Q | A
| ------------- | ---
| Branch? | master
| Tests pass? | yes
Should fix appveyor/travis builds
Commits
-------
8740e44086 Fix DI test
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection] make the service container builder register its own self referencing definition
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Commits
-------
9c97496b5f [DependencyInjection] make the service container builder register the definition of its related service container service (and aliases) in order to make compiler passes be able to reference the special service_container service.
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Always consider abstract getters as autowiring candidates
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes (a missing part of getter autowiring really)
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
When a definition is set to be autowired with no method explicitly configured, we already wire the constructor.
We should also autowire abstract getters - with the same reasoning that makes us autowire the constructor: without concrete getters, the class is unusable. This just makes it usable again.
Commits
-------
8f246bde1d [DI] Always consider abstract getters as autowiring candidates
* 3.2:
Permit empty suffix on Windows
fixed CS
[FrameworkBundle] Remove unused import
[Console][Table] fixed render when using multiple rowspans.
add docblocks for Twig url and path function to improve ide completion
check for circular refs caused by method calls
[Serializer] fix upper camel case conversion (see #21399)
[DI] Auto register extension configuration classes as a resource
[Console] Updated phpdoc on return types
* 2.8:
Permit empty suffix on Windows
[Console][Table] fixed render when using multiple rowspans.
add docblocks for Twig url and path function to improve ide completion
check for circular refs caused by method calls
[Serializer] fix upper camel case conversion (see #21399)
[DI] Auto register extension configuration classes as a resource
[Console] Updated phpdoc on return types
* 2.7:
Permit empty suffix on Windows
[Console][Table] fixed render when using multiple rowspans.
add docblocks for Twig url and path function to improve ide completion
check for circular refs caused by method calls
[Serializer] fix upper camel case conversion (see #21399)
[DI] Auto register extension configuration classes as a resource
[Console] Updated phpdoc on return types
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Deprecate underscore-services in YamlFileLoader
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | no
| Fixed tickets | -
| License | MIT
| Doc PR | -
As discussed when introducing `_defaults`
Commits
-------
7781082587 [DI] Deprecate underscore-services in YamlFileLoader
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection] Add support for named arguments
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | todo
This PR introduces named arguments for services definitions. It's especially useful to inject parameters in an autowired service. It is (at least partially) an alternative to #21376 and #20738.
Usage:
```yml
services:
_defaults: { autowire: true }
Acme\NewsletterManager: { $apiKey: "%mandrill_api_key%" }
# Alternative (traditional) syntax
services:
newsletter_manager:
class: Acme\NewsletterManager
arguments:
$apiKey: "%mandrill_api_key%"
autowire: true
```
```php
use Doctrine\ORM\EntityManager;
use Psr\Log\LoggerInterface;
namespace Acme;
class NewsletterManager
{
private $logger;
private $em;
private $apiKey;
public function __construct(LoggerInterface $logger, EntityManager $em, $apiKey)
{
$this->logger = $logger;
$this->em = $em;
$this->apiKey = $apiKey;
}
}
```
Commits
-------
8a126c8537 [DI] Deprecate string keys in arguments
2ce36a6074 [DependencyInjection] Add a new pass to check arguments validity
6e501296f9 [DependencyInjection] Add support for named arguments
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Add prototype services for PSR4-based discovery and registration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | to be done
Talking with @dunglas, we wondered if this could be a good idea, as a more general approach to folder-based service registration as done in [DunglasActionBundle](https://github.com/dunglas/DunglasActionBundle/blob/master/DependencyInjection/DunglasActionExtension.php).
So here is the implementation.
This allows one to define a set of services as such:
```yaml
services:
App\:
resources: ../src/{Controller,Command} # relative to the current file as usual
autowire: true # or any other attributes really
```
This looks for php files in the "src" folder, derivates PSR-4 class names from them, and uses `class_exists` for final discovery. The resulting services are named after the classes found this way.
The "resource" attribute can be a glob to select only a subset of the classes/files.
This approach has several advantages over [DunglasActionBundle](https://github.com/dunglas/DunglasActionBundle/blob/master/DependencyInjection/DunglasActionExtension.php):
- it is resilient to missing parent classes (see test case)
- it loads classes using the normal code path (the autoloader), thus play well with them (e.g. if one registered a special autoloader).
- it is more predictable, because it uses discovered paths as the only source of ids/classes to register - vs relying on `get_declared_classes`, which would make things context sensitive.
Fits well with current initiatives to me.
Commits
-------
03470b788e [DI] Add "psr4" service attribute for PSR4-based discovery and registration
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI] Deprecate (un)setting pre-defined services
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | no
| Fixed tickets | #19192
| License | MIT
| Doc PR | -
This PR is the subset of #19668 that fixes#19192: it deprecates (un)setting pre-defined services.
This opens the path to some optimizations in the dumped container in 4.0.
Commits
-------
fdb2140b81 [DI] Deprecate (un)setting pre-defined services
This PR was squashed before being merged into the 3.3-dev branch (closes#21194).
Discussion
----------
[Yaml] Add tags support
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/symfony/issues/21185
| License | MIT
| Doc PR |
This PR adds custom tags support to the Yaml component.
Symfony tags (`!!binary`, `!str`, etc.) are still managed in the parser to have a lighter diff but we'll be able to convert them later if we want to.
The primary addition of this PR is the `TagInterface`:
```php
interface TagInterface
{
public function construct(mixed $value): mixed;
}
```
It can be used to register custom tags. An example that could be used to convert [the syntax `=iterator`](https://github.com/symfony/symfony/pull/20907#issuecomment-270728216) to a tag:
```php
final class IteratorTag implements TagInterface
{
public function construct(mixed $value): mixed
{
return new IteratorArgument($value);
}
}
$parser = new Parser(['iterator' => new IteratorTag()]);
```
If you think this is too complex, @nicolas-grekas [proposed an alternative](https://github.com/symfony/symfony/issues/21185#issuecomment-271074840) to my proposal externalizing this support by introducing a new class `TaggedValue`.
Commits
-------
4744107 [Yaml] Add tags support