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
Automatically extract fixture dependencies #421
Conversation
I'd appreciate some feedback on the behaviour change before I do any more work making this suitable to be merged. |
I don't know much about this bundle, but I don't see a problem with this, please go ahead. |
eeb35dc
to
73c2923
Compare
@greg0ire 👍 updated |
It seems there are CI jobs failing. Please take a look at this guide for more on how to handle those. |
PHPStan is failing but it seems to be it doesn't understand what the parent class is so it thinks the methods are undefined, it's doing the same on the |
Are you sure? Here is a 12 hours old build not exhibiting any issue: https://github.com/doctrine/DoctrineFixturesBundle/actions/runs/8513966759 |
Here is another PR I just made: #429 |
Apologies, I merged from the wrong remote which meant I didn't have b83a046 I've ignored the PHPStan error I've introduced which is the same class as the existing ignored problems. |
Retargeting on 3.6.x since this is no bugfix. Please rebase and force push. |
@greg0ire updated |
I don't think it makes sense to have 2 commits here: we're never going to want to revert one and keep the other, right? If so, please squash them, preserving the excellent commit message body. |
It is now no longer required to declare groups on all dependent fixtures, the fixture loader will now automatically find the required dependencies and load them without them being explicitly added to the groups being loaded. Before you were forced to declare groups all the way down the dependency chain, for example: ``` TopLevelFixture (groups: default) ├─ SecondLevelFixture1 (groups: default, alternative) │ ├─ ThirdLevelFixture1 (groups: default, alternative) ├─ SecondLevelFixture2 (groups: default) │ ├─ ThridLevelFixture2 (groups: default) │ ├─ ThirdLevelFixture3 (groups: default, alternative) ``` Now you only need to specify the groups at the highest level: ``` TopLevelFixture (groups: default) ├─ SecondLevelFixture1 (groups: alternative) │ ├─ ThirdLevelFixture1 (groups: none) ├─ SecondLevelFixture2 (groups: none) │ ├─ ThridLevelFixture2 (groups: none) │ ├─ ThirdLevelFixture3 (groups: alternative) ``` In both examples the groups `default` and `alternative` will load the same fixtures. Adds an additional PHPStan error to the baseline which appears to be caused by the backwards compatibility layer.
Thanks @cs278 ! |
Thanks for your assistance in getting this merged @greg0ire 😃 |
Fixes #371
This improves the cooperation between the native fixture dependencies and the bundle provided groups. It is now no longer necessary to add the dependencies of fixtures in a group into the group as well.
I've not tested this extensively, or added tests for this yet but if the maintainers are happy with the change in behaviour I can do that.