-
Notifications
You must be signed in to change notification settings - Fork 107
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
Enhance code quality by adding PHPStan and fixing level 0 issues #730
Changes from all commits
7456d9d
1e298c3
0e5afc1
4be88c6
45b4573
216985b
bcb4963
69630a0
dd72fff
07c43e7
c0db055
916dd25
5e498d1
4554f6a
bd1c378
93ec3dc
789f317
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -14,17 +14,23 @@ | |||||
"require-dev": { | ||||||
"dealerdirect/phpcodesniffer-composer-installer": "^0.7", | ||||||
"phpcompatibility/php-compatibility": "^9.3", | ||||||
"phpstan/extension-installer": "^1.3.0", | ||||||
"phpstan/phpstan": "^1.10", | ||||||
"phpunit/phpunit": "^4|^5|^6|^7|^8|^9", | ||||||
"squizlabs/php_codesniffer": "^3.5", | ||||||
"szepeviktor/phpstan-wordpress": "^1.3.0", | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not that this package and PHPStan itself require PHP 7.2. So when we start running tests against PHP 5.6 (see #399), The plugin itself wouldn't break, as it doesn't use the autoloader. Same discussion as in #729 really. Check out WordPress/plugin-check#166 for a workaround by moving these deps to a separate There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great point @swissspidy, let's apply the same approach here as we want to support PHP 5.6 too for our test suite as we should preferably run the tests on that version too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As I understand, there are three possible ways to about this:
I think the third option is ideal, since all normal development environments would be running PHP 7.2+. It's only the exception case, specifically on GHA, where PHP 5.6 is needed. This would allow a developer to have all packages installed normally. The first option doesn't seem ideal since there would be a separate composer file to maintain, and Dependabot wouldn't automatically be aware of it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about we address back-compat with PHP 5.6 as part of #399? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Downsides of (2) and (3) are that it's a less reproducible setup for developers, and that it's cumbersome to do for other packages as well (think all the PHPStan extensions or the Slevomat CS package). I did something like that in the past for downgrading/upgrading PHPUnit in CI, but it's not more maintainable than (1). I wish (1) wasn't needed, but when dealing with such version requirements it's a necessary evil.
FWIW this is easily solved with another entry in the Dependabot config. Example: - package-ecosystem: "composer"
directory: "/"
schedule:
interval: "daily"
- package-ecosystem: "composer"
directory: "/build-cs"
schedule:
interval: "daily" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I just noticed that Gutenberg actually takes this approach instead of maintaining a separate There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How is this less maintainable than maintaining a separate There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can also highly recommend https://packagist.org/packages/swissspidy/phpstan-no-private to catch calls of seemingly private functions. Plus https://packagist.org/packages/phpstan/phpstan-phpunit and https://packagist.org/packages/php-stubs/wordpress-tests-stubs to run PHPStan against tests as well. Believe me, it really improves the quality of the tests! https://packagist.org/packages/phpstan/phpstan-deprecation-rules is also nice to prevent usage of deprecated functions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I love this package, but I wonder if this is the best for Performance Lab considering that the code in question will end up in core and thus it is expected that many calls to internal/private functions will be made? As it stands right now... There are 73 instances of this
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Do we need the test subs since we're already installing Lines 14 to 15 in 5e498d1
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Good point! 😃 I think it can't hurt to use it anyway, since not everything will land in core. Places where usage is OK can be ignored in the PHPStan config accordingly. But maybe in another PR :-) All the
Probably not in that case. Counter question: why is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, also if our code here follows PHPStan, I don't think it would violate anything that core requires - we'd effectively have stricter requirements than core, which I think should work fine as long as it's in that direction and not the opposite :)
I believe that is for additional flexibility. We don't want to dictate anyone to use |
||||||
"wp-coding-standards/wpcs": "^2.2", | ||||||
"wp-phpunit/wp-phpunit": "^5.8", | ||||||
"yoast/phpunit-polyfills": "^1.0" | ||||||
"yoast/phpunit-polyfills": "^1.0", | ||||||
"phpstan/phpstan-phpunit": "^1.3", | ||||||
"phpstan/phpstan-deprecation-rules": "^1.1" | ||||||
}, | ||||||
"require": { | ||||||
"composer/installers": "~1.0", | ||||||
"php": ">=5.6|^7|^8" | ||||||
}, | ||||||
"scripts": { | ||||||
"phpstan": "phpstan analyze --ansi", | ||||||
"format": "phpcbf --standard=phpcs.xml.dist --report-summary --report-source", | ||||||
"lint": "phpcs --standard=phpcs.xml.dist", | ||||||
"test": "phpunit -c phpunit.xml.dist --verbose", | ||||||
|
@@ -33,7 +39,8 @@ | |||||
"config": { | ||||||
"allow-plugins": { | ||||||
"dealerdirect/phpcodesniffer-composer-installer": true, | ||||||
"composer/installers": true | ||||||
"composer/installers": true, | ||||||
"phpstan/extension-installer": true | ||||||
} | ||||||
}, | ||||||
"autoload-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.
Technically not needed because it's a dependency of
szepeviktor/phpstan-wordpress
alreadyThere 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 thought about that. But I thought this might get us PHPStan updates more quickly by being an explicit dependency. Otherwise we'd need to wait for the package to update, AFAIK.