This PR was merged into the 3.3-dev branch.
Discussion
----------
[Config] Fix resource tracking with new GlobResource
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Right now, resource tracking is done via tracking of directories mtimes, which means a container is rebuilt each time a file is either removed or added, but not when an existing file is modified.
This looks nice on the surface.
BUT.
Most code editors do create a temporary file when you open your code, thus change the parent dir mtime, thus trigger a container rebuild.
When working with PSR-4 loaders, this means each time you just open a file, most of you will trigger a container rebuild.
This is bad :(
Here is a new GlobResource to fix this issue.
Commits
-------
9190e108c1 [Config] Fix resource tracking with new GlobResource
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
----------
[DI] Throw useful exception on bad XML argument tags
| Q | A
| ------------- | ---
| Branch? | 3.3
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #22525
| License | MIT
| Doc PR | -
I still think that the feature request in #22525 would make things better.
But at least, let's make thing fail loudly, instead of silently today, with the associated usual wtfs :)
Commits
-------
91828ecd17 [DI] Throw useful exception on bad XML argument tags
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[]
* 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.
* 2.7:
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] Fix the xml schema
[Translation] avoid creating cache files for fallback locales.
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DI/Yaml] Remove `@experimental` flag from "instanceof" and "prototype"
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
We don't need this flag on these features: the implementation is stable, and regular deprecations should be the way to go in the event where we decide to remove this later on.
That would leave only one single `@experimental` feature in 3.3: `CacheItem::getPreviousTags()`, which looks legitimate to me (since this method is aiming at interop).
Commits
-------
e8723df28a [DI/Yaml] Remove `@experimental` flag from "instanceof" and "prototype"
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:
Fixes a typo in the form collector styles
[WebProfilerBundle] Fix content-security-policy compatibility
[WebProfilerBundle] Drop dead code
[HttpKernel] Fixed bug with purging of HTTPS URLs
fix some risky tests
[DI] [YamlFileLoader] change error message of a non existing file
[WebProfilerBundle] Handle Content-Security-Policy-Report-Only header correctly
[Security] Added option to return true in the method isRememberMeRequested
* 2.8:
Fixes a typo in the form collector styles
[HttpKernel] Fixed bug with purging of HTTPS URLs
fix some risky tests
[DI] [YamlFileLoader] change error message of a non existing file
[Security] Added option to return true in the method isRememberMeRequested
* 2.7:
[HttpKernel] Fixed bug with purging of HTTPS URLs
fix some risky tests
[DI] [YamlFileLoader] change error message of a non existing file
[Security] Added option to return true in the method isRememberMeRequested
This PR was merged into the 3.3-dev branch.
Discussion
----------
[DependencyInjection] Remove the "id" attribute of "callable"
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks? | ?
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass? | yes
| Fixed tickets | <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR |
It seems like this attribute was added by mistake as it's used nowhere.
It should be removed but I don't think it's worth adding a bc layer.
Commits
-------
19547a2639 [DependencyInjection] Remove the "id" attribute of "callable"
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
----------
[DI] Simplify AutowirePass and other master-only cleanups
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
A few minor cleanups and fixes, and an overall simplification of AutowirePass.
Commits
-------
34e5cc7698 [DI] Simplify AutowirePass and other master-only cleanups
