-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
Add support for Symfony 6 #509
Conversation
08406f7
to
8d968f8
Compare
This one is strange:
|
dfc9c94
to
31d379e
Compare
IMO the contents of this commit: 31d379e should be reverted, because it makes this bundle not compatible with php < 8.0 (that commits belongs to this PR). Currently without that commit this PR do not pass the new build I added for Symfony 6 @wouterj do you agree? Should I open one PR to revert this return typehint on the main Symfony repository? Are multiple PRs needed or just one (IMO it should be better in one, because all of them have to be accepted for this PR to continue, otherwise php < 8 have to be dropped to accept Symfony 6)? |
@@ -86,7 +86,7 @@ public function addNode(\DOMNode $node): void | |||
throw $this->createNotSupportedException(__METHOD__); | |||
} | |||
|
|||
public function eq($position): self | |||
public function eq($position): static |
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.
This is another spot where we can't do this... unless we're planning to drop support for PHP 7. But... maybe we are??? In order to support Symfony 6?
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 guess the core team of Symfony should take a decision on this. I can work on both implementations. Keeping support for older php version needs main Symfony repository to be adapted before 6.0 comes out. Removing support for older php versions might need a major version of this package.
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.
But indeed this one I missed when reporting here: symfony/symfony#43021
This will be a ton of changes, because all of. this class changed its return types. 😱
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.
Either we remove the return types from core, or we add some conditional classes/traits declarations in this bundle.
I'm personally ok to revert the addition of these type declarations, we can re-add them 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.
So, should we revert these in core? If we're going to do that, I guess we should do it as quickly as we can.
(I'm still very unfamiliar with the typing situation - so apologies for not having anything intelligent to add)
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.
Yes, I am trying to fix everything here to know what types exactly should be reverted, because I wasn't taking care of static.
My idea is:
- Prepare this PR to be able to ensure that changes on Symfony will make this PR pass
- Make a PR on Symfony core to change all types needed here
- Adapt this PR when the PR on the main repo is merged
For the moment I am having some trouble with PHPStan, since it is not a dependency of this project it got upgraded to 1.0 without notice and now it reports more errors.
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.
This makes sense to me - thank you and keep us posted :)
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.
Im trying a little trick to patch symfony to remove its return types so we can ensure that those changes applied to Symfony 6.0 will make build pass with all versions here.
So far I think it will work, but I am having some last troubles with PHPStan. No more problems with PHPStan, it is working.
The idea is to remove the last 2 commits from this PR once I do the Symfony PR to remove the return typehints
wdyt?
9e65672
to
698ced4
Compare
I don't think the failure is related to my changes. Edit: A restart fixed the build |
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'll need someone more familiar with the "types" topic on the Symfony core to take a look, but this makes sense to me - very nice work!
What about bumping panther to v2? |
The work to be done is mostly the same, removing only the last commit cleans up the return types to be compatible only with php 8 and sf 6. There are some things to consider
Maybe there are more things that I cant see because I dont know a lot of this bundle. |
For this bundle I agree. For for Symfony that'd allow withdrawing symfony/symfony#44005, which could be nice. |
Works for me. Should we maintain a 1.x branch? |
I've no strong opinion about this. I'm ok with both options. |
So, which are the next steps? |
I’m hearing a slight preference to make a v2 of this bundle. That would be my vote as well so we can move things forward. As far as a 1.x branch? We could decide on that later, but there is little harm to create one. |
@jordisala1991 Could you revert the DomCrawler patch to make the code PHP8+ only, then mark this PR as ready? |
2e57792
to
e5e7ed6
Compare
Done @chalasr |
restore-keys: ${{ runner.os }}-composer- | ||
|
||
- name: Allow dev dependencies | ||
run: composer config minimum-stability dev |
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.
Normally we have minimum-stability: "dev"
in composer.json
by default... and that's what we always use. If we did that, then we wouldn't need this second job, I think. For example: /~https://github.com/symfony/string/blob/d70c35bb20bbca71fc4ab7921e3c6bda1a82a60c/composer.json#L39
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.
A little more info. What we normally do is:
- Put
"minimum-stability": "dev"
directly incomposer.json
- For "normal" builds (e.g. released versions like Symfony 5.3), we use
--prefer-stable
withcomposer update
. - For non-released builds (e.g. Symfony 6), we would omit the
--prefer-stable
.
BUT, I think these are not-important details. The current builds DO test the correct stuff. I vote we merge this, and then we could potentially optimize this build file later to reduce duplication.
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 think it would be nice to have a better testing of different symfony versions, as you said it can be done on another Pr. I can bring some of the workflows we use at Sonata if you dont have a standard way for all sf repositories.
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 good with this - for a 2.0 release.
A CHANGELOG entry for 2.0 would be great.
@dunglas I believe you're needed to merge and tag? I would love that - it would unblock a Symfony6 release for symfony/ux... which would unblock some other symfony/ux stuff :). |
Merged! Thanks @jordisala1991! @weaverryan I'll try to craft a release on Monday. |
It is required to run with dev dependencies, otherwise it wont be installed. I didn't found a dev dependencies build so I added one (if it is not correct this way, I can revert it or change to another one)