-
-
Notifications
You must be signed in to change notification settings - Fork 30
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 static analysis using Psalm, and fix reported issues #26
Conversation
composer.json
Outdated
@@ -9,7 +9,8 @@ | |||
], | |||
"license": "MIT", | |||
"require": { | |||
"php": "^7.1|^8.0" | |||
"php": "^7.1|^8.0", | |||
"psalm/phar": "^3.13" |
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.
Psalm should be a dev
dependency.
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.
Thanks, you're right of course. Having it in require
would cause conflicts with projects that use this library and require a different version of psalm/phar
. Fixed in b4f457b
Hi, thanks for your PR! I'm waiting for brick/math#43 to be merged, then I'll come back to you 👍 |
Hi Ben. I hadn't seen brick/math#43 . Is there are a dependency between that and this PR? Or you want to learn from that one before you decide what what to do here? Let me know if you'd like me to rebase this on the latest master. If you think it would be useful I'd be up for adding more checking tools like PHPStan or perhaps Infection, and maybe increasing the Psalm strictness level and making it cover tests as well as source. |
This is using the second strictest set of checks in Psalm default configs. It might be interesting to get the library working on the strictest level, which would mean resolving all the issues with mixed types
I went ahead and rebased on latest master ( 3d29c70 ) to make sure it still passes. |
Exactly.
+1 for maximum strictness, if that doesn’t affect legitimate code (example: in the other PR, adding a method was suggested, just to make Psalm happy - I’m not OK with that). I’m still not sure if I want to use both Psalm and phpstan (what about phan?), I’ll be happy to hear your thoughts about this. I’m also willing to add a coding style, with phpcs and/or php-cs-fixer (see brick/math#44). Infection, why not. But I’ll be using brick/math (my most popular library) as a testing ground before deploying this to all my libraries, to try and keep them consistent with each other! I appreciate to have 2 separate contributions for code quality though, and would be grateful if you can participate to brick/math#43! |
Ok, I'll try and find time to take a good look at brick/math#43 soon and I can try and answer some of your questions about it if @alexeyshockov hasn't answered them first, and maybe also join the discussion about the coding style tool over at brick/math. About phpstan, I think it has several types of issues it can catch that Psalm doesn't, and vice versa, so you find the most possible issues by using both. I only have experience with Psalm personally. |
@BenMorel Do you want to take another look at this now that brick/math#43 (comment) is closed and Psalm is working in brick/math ? |
* | ||
* Looks like Psalm might have a wrong return type for \DateTimeInterface::getTimeZone - it should | ||
* be \DateTimeZone|false . Psalm seems to think it's just \DateTimeZone | ||
*/ |
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.
Reported here: vimeo/psalm#4515
Please add a link in the comment!
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.
Done
src/Duration.php
Outdated
|
||
if ($nanoseconds < 0) { | ||
$nanoseconds += LocalTime::NANOS_PER_SECOND; | ||
$seconds--; | ||
} | ||
|
||
|
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.
Please remove this extra line
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.
done
composer.json
Outdated
@@ -13,7 +13,8 @@ | |||
}, | |||
"require-dev": { | |||
"phpunit/phpunit": "^7.5.15", | |||
"php-coveralls/php-coveralls": "^2.2" | |||
"php-coveralls/php-coveralls": "^2.2", | |||
"psalm/phar": "^3.13" |
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.
Could you please upgrade to Psalm ^4.1?
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.
Done
@@ -11,6 +11,7 @@ before_script: | |||
|
|||
script: | |||
- mkdir -p build/logs | |||
- vendor/bin/psalm.phar |
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.
Instead of running Psalm with every build, it would be nice to create a separate job for it.
You can take inspiration from brick/math: https://github.com/brick/math/blob/master/.travis.yml
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 not clear on what the benefit of the separate job would be at this stage. Psalm only seems to take 1.15 seconds to run, so the overheads of setting up a separate job probably wouldn't be justified by the potential savings of running it in parallel with other things. I'm also not very familiar with Travis.
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.
You have a point here, though it's more of a matter of proper job separation, so that when a job fails, you know that it's because of a failed test and not because of a Psalm issue. This also gives the ability to use Psalm as one of the "smoke tests" that prevent other tests from running if it doesn't pass. Let's merge it this way for now, I'll come back to this later.
@bdsl Please check my comments, and it will be good to go! 👍 |
@BenMorel Thanks, I've applied all your suggestions apart from the one about travis. I was going to consider that next, but maybe Travis is having problems - the job for building 0777a78 seems to have been queued for several minutes. I'm not sure how long it should normally take. I'll take another look later and see if it's run. |
Thanks, @bdsl! |
This is using the second strictest set of checks in Psalm default
configs. It might be interesting to get the library working on
the strictest level, which would mean resolving all the issues with
mixed types