-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
QA: standards should not have conflicting rules / fix fixer conflicts #152
Comments
To prevent confusion/wasting people's time I reiterate that the task is not to get the conflict check running. I have the set up for that ready already. Also note that if you would try to run the mentioned command without limiting them to an individual conflict which you want to investigate, there are three PHP notices which will crash the runs.
|
For the |
I've looked into the PSR12 conflict with PHP_CodeSniffer/src/Standards/PSR12/ruleset.xml Lines 294 to 300 in 071344b
However, there's an inconsistency within For "space before close", the two branches report the same error code: For "space after open", the two branches report different error codes: PHP_CodeSniffer/src/Standards/Squiz/Sniffs/ControlStructures/ForEachLoopDeclarationSniff.php Lines 75 to 133 in 071344b
To fix this, I can see several options. I'd like an opinion about what is the "best" way forward here.
I'd like to proceed with option 2 (or maybe 4), but recognise that this can be seen as a backwards-incompatible change. For reference, these are all the codes reported by this sniff: @jrfnl what are your thoughts on this? |
@fredden We've looked at this together today and in my opinion, option 2 is the way to go. If I look at both the Squiz If I then look at the While this removes an error code, I would not consider this a breaking change which needs to be in a major, though I would put it in a minor.
|
Premise
A standard should be able to be used without leading to fixer conflicts.
Now, as code can be written in lots of different ways, it is not always straight forward to anticipate potential conflicts, however, PHPCS contains a wealth of test code, so by running the fixers for a standard over all test case files, we should be able to detect a lot of potential fixer conflicts.
Current status
While I have the workflow and the set up for this check ready, it cannot currently be turned on as all standards, except PSR1, lead to fixer conflicts.
Last update date for the "current status": 2024-07-29
Please feel free to ping @jrfnl for an update if the list is outdated.
Details of current fixer conflicts for the PEAR standard
Command:
Test case files leading to fixer conflicts
Details of current fixer conflicts for the PSR2 standard
Command:
Test case files leading to fixer conflicts
Details of current fixer conflicts for the PSR12 standard
Command:
Test case files leading to fixer conflicts
Details of current fixer conflicts for the Squiz standard
Command:
Test case files leading to fixer conflicts
Details of current fixer conflicts for the Zend standard
Command:
Test case files leading to fixer conflicts
Caveat
There are some files which should probably be excluded from a fixer conflict check like this ticket proposes. Most notably test case files which contain git merge conflict markers.
For the above lists in the fold-outs, this was already done.
What needs to be done
For each of the files listed above leading to a fixer conflict, it needs to be determined whether:
How to go about this
*.conflictcheck
to your.git/info/exclude
(will be added to.gitignore
when the fixer conflict check will be added for real).-vvv
flag.When in doubt, share your findings and discuss the options for the conflict you are working on in a comment on this ticket or create a separate ticket to discuss solution directions if the conflict is a complex one (and link that ticket to this one).
PRs for this task should only contain the solution for one fixer conflict per PR and if the conflict can be isolated enough, the PR should be limited to fixing the issue for only one of the sniffs involved, with, if necessary, separate PRs for the other sniff(s) involved.
The text was updated successfully, but these errors were encountered: