Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DependencyInjection] Add CheckAliasValidityPass to check interface compatibility #50745

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Feb 6, 2024
Merged

[DependencyInjection] Add CheckAliasValidityPass to check interface compatibility #50745

merged 1 commit into from
Feb 6, 2024

Conversation

n-valverde
Copy link
Contributor

@n-valverde n-valverde commented Jun 22, 2023 •
edited
Loading

Q A
Branch? 7.1
Bug fix? no
New feature? yes
Deprecations? no
Tickets /
License MIT
Doc PR TODO

Hello, I would like to propose adding a pass to the compiler, to make sure that when defining an alias which happens to be an interface, the resolved service actually implements that interface. See example below.

<services>

    <service id="a_vendor.service" class="Foo\Bar" />
    <service id="Foo\BarInterface" alias="a_vendor.service" />

</services>
namespace Foo;

interface BarInterface {}
interface BazInterface {}

class Bar implements BazInterface
{
}
public function __construct(private BarInterface $bar) // Type error, $bar must be of type BarInterface

Currently the above situation is allowed, and will ultimately lead to a type error at runtime when trying to inject BarInterface, because Bar is not compatible. I think this situation should be raised as a configuration error, as I can't think of any valid use case for this.

I might be missing some use cases, and this might have been already discussed in some way, so any input appreciated, even if you think this is a bad idea for some reason 🙃
Thanks!

@carsonbot
Copy link

Hey!

To help keep things organized, we don't allow "Draft" pull requests. Could you please click the "ready for review" button or close this PR and open a new one when you are done?

Note that a pull request does not have to be "perfect" or "ready for merge" when you first open it. We just want it to be ready for a first review.

Cheers!

Carsonbot

@n-valverde n-valverde marked this pull request as ready for review June 22, 2023 15:48
@carsonbot carsonbot added this to the 6.4 milestone Jun 22, 2023
@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.4 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@n-valverde n-valverde force-pushed the feat/check-alias-validity-pass branch 2 times, most recently from 41b5f63 to 810f7e9 Compare June 23, 2023 08:51
@n-valverde
Copy link
Contributor Author

Few more thoughts for people coming here:

  • There is the lint:container command which could be useful, but I think does not match exactly this use case. As far as I understand it, it only checks type compatibility of arguments, so that leaves the possibility of defining a bad service from a lib developer side, and the issue will only be spotted by end user when trying to inject the badly configured service (Which is why I came here: api-platform/core:^2.7 is severely affected by this, and running lint:container does not spot the issue)
  • I am also thinking that adding a flag like --all to the lint:container command, to make the CheckTypeDeclarationPass run before removals could be a good addition, any thought on this?
  • I understand that this proposal could be a dead end, with autoload, performance concern, or whatever, so maybe that could just be added to the lint:container checks
  • Failing tests are due to reflection going through the trigger_deprecation calls, and same happens if autoload triggers, so I'm not sure there is any way to deal with that

Friendly ping @nicolas-grekas since you've worked on the initial lint:container command 😇

@nicolas-grekas
Copy link
Member

For sure this shouldn't be part of the always-on passes but if adding this to lint:container helps, why not.

@nicolas-grekas nicolas-grekas modified the milestones: 6.4, 7.1 Nov 15, 2023
@fabpot
Copy link
Member

fabpot commented Feb 3, 2024

@n-valverde Can you work on the change suggested by @nicolas-grekas

@n-valverde n-valverde force-pushed the feat/check-alias-validity-pass branch 2 times, most recently from ee18b9c to 4aebb69 Compare February 4, 2024 11:11
@n-valverde
Copy link
Contributor Author

Hello, sorry for the delay, I rebased on 7.1 and made the change so the pass is only applied to lint:container but I have additional questions/concerns:

  • I have to register this pass before removals, that makes sense for me because of the situation described above, but I'm not sure if this could trigger false positives
  • Was about to update the changelog, but I am wondering if this pass should remain in the DependencyInjection component since it is only used by the lint:container from FrameworkBundle (but it is the same for CheckTypeDeclarationsPass)

@fabpot
Copy link
Member

fabpot commented Feb 4, 2024

Hello, sorry for the delay, I rebased on 7.1 and made the change so the pass is only applied to lint:container but I have additional questions/concerns:

* I have to register this pass before removals, that makes sense for me because of the situation described above, but I'm not sure if this could trigger false positives

* Was about to update the changelog, but I am wondering if this pass should remain in the DependencyInjection component since it is only used by the `lint:container` from FrameworkBundle (but it is the same for `CheckTypeDeclarationsPass`)

That makes sense to me as it allows developers not using the full stack framework to still use the pass.

@fabpot fabpot force-pushed the feat/check-alias-validity-pass branch from d598f13 to c5dff26 Compare February 6, 2024 17:51
@fabpot
Copy link
Member

fabpot commented Feb 6, 2024

Thank you @n-valverde.

@fabpot fabpot mentioned this pull request Feb 6, 2024
Closed
@fabpot fabpot merged commit f233668 into symfony:7.1 Feb 6, 2024
@fabpot fabpot mentioned this pull request May 2, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@fabpot fabpot fabpot approved these changes

Assignees
No one assigned
Labels
DependencyInjection Feature Status: Reviewed
Projects
None yet
Milestone
7.1
Development

Successfully merging this pull request may close these issues.
4 participants
@n-valverde @carsonbot @nicolas-grekas @fabpot