Giters

overtrue / phplint

:bug: A tool that can speed up linting of php files by running several lint processes at once.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Good faith question - How is the PHP linter valuable for you?

fredericgboutin-yapla opened this issue · comments

commented

Hi,
Please bear with me for a moment, I'm really just asking a question seriously.

Since I've bootstrapped this component in our CI several months ago, we never ever got any errors or warnings. NEVER.

I mean, I have not a single recall of a moment where the CI flagged a linter issue with the code. And we are talking about multiple repos, some relatively big, several hundred thousands of LoCs, a team of devs pushing new code daily.

How do you guys / girls use this linter in a valuable way? I know this component is basically just a wrapper around php -l - see https://www.php.net/manual/en/features.commandline.options.php - but still.

Am I missing something or you basically experience more or less the same thing?

Thanks!

commented

Hi, this is a good question, as you said, our code has been running online for two years without any syntax errors until one day, one of our colleagues was trying to fix an urgent bug on line, he was very sure that a small change could fix the problem, so it took him less than a minute to submit the change, but for various reasons our test cases did not fully cover the change file, and the CI process did not find the error, resulting in a large number of fault alarms on line. However, for various reasons our test cases did not fully cover the changed file, and the CI process did not find that the change contained a syntax error, resulting in a large number of trouble alarms immediately after the release. I don't know if it was the IDE or mouse dragging or just a hand error that caused the character splice to match "." was written as ".." resulting in a syntax error.

So I made this very small tool to make sure such errors don't happen again, and then shared it on GitHub, and like you, I haven't encountered a single error or warning after using it for so long.

Also, it's not much different from running php -l manually, but if the project is complex enough, this package will speed up the check, that's all.

Thanks!

Translated with www.DeepL.com/Translator (free version)

commented

An honest answer to an honest question.

Thanks for shedding some light in here!

The problem I see with php -l is that, like you said, it is basically a very barebone syntax checker but not really a linter per-say. In my book, at least, it doesn't qualify as a linter.

It has been several months and we tried at least 4 or 5 different "real" PHP linters and unfortunately, none of them made it to production. I'm talking about,

  • Qodana - way too much ressource intensive. Simply "opening" the project takes 20 something minutes on the CI with caching, baseline and all
  • PHPStan - performs erroneously even with only "level 0" requirements in a project with a very large generated baseline
  • noverify - extremely promising performance wise until you realize it is only a glorified version of phpgrep and not really a linter - better than php -i in my opinion though
  • PHP_CodeSniffer - doesn't really focus that much on detecting logical errors than making sure the code "looks good"
  • Psalm - similar reliability problems to PHPStan

I would be interested to hear about people's experiences on different PHP Linters. I know this is not really the purpose of this issue, you can always close it and I will understand, since I feel you properly answered my initial issue.

commented

@fredericgboutin-yapla Thank you for sharing.