-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DependencyInjection] Make YamlFileLoader raise a deprecation notice if a service definition contains unsupported keywords. #17133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
To me this PR should be opened against the Should we consider it a new feature and keep the PR opened against the @nicolas-grekas @stof @fabpot any ideas please? |
97d979b
to
505089b
Compare
private static function checkDefinition($id, array $definition) | ||
{ | ||
foreach ($definition as $key => $value) { | ||
if (!in_array($key, static::$keywords)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can make supported properties keys of static::$keywords
and use isset
, it will reduce the complexity from O(n) to O(1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
505089b
to
188ab3b
Compare
if (!isset(static::$keywords[$key])) { | ||
throw new InvalidArgumentException(sprintf( | ||
'The "%s" key in "%s" service definition is not valid. It must be one of "%s".', | ||
(string) $key, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need to cast here, and usually, we prefer putting exceptions on one single (long) line
I agree with @Ener-Getick here. Throwing an exception on unsupported keys in the service definition is indeed a BC break as it might break existing working config files. |
I've changed the PR to raise a deprecation notice instead. Shall we also introduce an |
898e9b8
to
4a3ab07
Compare
I think that we should have an upgrade file for |
31a98fc
to
6f398da
Compare
I guess this time, it's ok for another round of review. |
@@ -32,6 +32,30 @@ | |||
*/ | |||
class YamlFileLoader extends FileLoader | |||
{ | |||
private static $keywords = array( | |||
'alias' => 'alias', | |||
'parent' => 'parent', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about removing this array values as the code only uses its keys?
Ping @dunglas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
values are used when constructing the message (see implode)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops didn't see that
54ea34c
to
4a67241
Compare
…if a service definition contains unsupported keywords.
4a67241
to
bb5f118
Compare
👍 |
We should add a way to add additional custom keys. For example, the FOSRestBundle adds additional keys for defining REST related routes. With the current implementation we would have overridde the complete |
@xabbuh it's for service definitions routing. Does |
@hhamon Sorry, forget about my comment. |
Any news on this? @xabbuh @stof @nicolas-grekas @dunglas @weaverryan @webmozart |
// @deprecated Uncomment the following statement in Symfony 4.0 | ||
// and also update the corresponding unit test to make it expect | ||
// an InvalidArgumentException exception. | ||
//throw new InvalidArgumentException(sprintf('The configuration key "%s" is unsupported for service definition "%s" in "%s". Allowed configuration keys are "%s".', $key, $id, $file, implode('", "', static::$keywords))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about creating the 4.0 branch now to avoid having to make such updates later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 would avoid to forget some deprecations/updates of the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm 100% for creating for 4.0 branch already if @fabpot agrees.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As one of the happy few doing the merges from 2.3 up to master, I'm 👎. This is tedious enough to not add one more branch. I hope you understand...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nicolas-grekas this branch would not need to have merges as often as the others and should also not receive as much commits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The drawback would be that we would have to maintain it already, and people would start using it in their composer projects. So I'm -1 on it.
When we start the 4.0 development, we will look at any existing @trigger_error
to convert them to the new code (either removing code, or doing other actions).
I would even remove the commented exception and just put a comment saying it should be converted to an exception in 4.0. This way, the exception message will be written at the 4.0 time, not now, and so using the uptodate deprecation message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thus, merges into newer major versions are the worse branch merges, as they often trigger merge conflicts (due to the removal of BC layers), so it is better to avoid doing them during the whole 3.x lifetime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and creating 4.0 would require creating 3.1, 3.2, 3.3 and 3.4 also, because that's how we merge things. 👎 👎 👎
👍, very useful when using autowiring (I often use the key |
👍 |
Thank you @hhamon. |
…ecation notice if a service definition contains unsupported keywords. (hhamon) This PR was merged into the 3.1-dev branch. Discussion ---------- [DependencyInjection] Make YamlFileLoader raise a deprecation notice if a service definition contains unsupported keywords. | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | ~ | License | MIT | Doc PR | ~ Merry Christmas Symfony!!! Commits ------- bb5f118 [DependencyInjection] make YamlFileLoader raise a deprecation notice if a service definition contains unsupported keywords.
…/elements for alias (Ener-Getick) This PR was squashed before being merged into the 3.1-dev branch (closes #17323). Discussion ---------- [DependencyInjection] Deprecate unsupported attributes/elements for alias | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #17256 | License | MIT Following #17133, this PR deprecates using unsupported keywords on alias definition. For example the following examples will trigger deprecations: ```xml <?xml version="1.0" encoding="utf-8"?> <container> <services> <service id="bar" alias="foo" class="Foo"> <tag name="foo.bar" /> </service> </services> </container> ``` ```yml services: bar: alias: foo parent: quz ``` Commits ------- 49eb65c [DependencyInjection] Deprecate unsupported attributes/elements for alias
…/elements for alias (Ener-Getick) This PR was squashed before being merged into the 3.1-dev branch (closes #17323). Discussion ---------- [DependencyInjection] Deprecate unsupported attributes/elements for alias | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #17256 | License | MIT Following symfony/symfony#17133, this PR deprecates using unsupported keywords on alias definition. For example the following examples will trigger deprecations: ```xml <?xml version="1.0" encoding="utf-8"?> <container> <services> <service id="bar" alias="foo" class="Foo"> <tag name="foo.bar" /> </service> </services> </container> ``` ```yml services: bar: alias: foo parent: quz ``` Commits ------- 49eb65c [DependencyInjection] Deprecate unsupported attributes/elements for alias
Merry Christmas Symfony!!!