SanderRonde
commented
3 months ago Alright I've looked into it some more and managed to (in a very hacky way) figure out which files are actually being used by PHPStan. I'm using the new Diagnose API to load a custom extension into PHPStan that then calculates the included files in the same way PHPStan would. Essentially dumping the files PHPStan would use without having to run it. I can then add a watcher for those files and effectively achieve what you're asking for. (and yes it does include a couple of required /vendor files indeed)
Will look into this some more when I've got time but I can definitely see the value in this so this is definitely on "the roadmap" as far as I've got one.
To be a bit clearer as to why I changed my mind: there are 2 ways to tackle this. From "outside" PHPStan (by reading config files) and from "inside" (by using a plugin/extension of some sort). The first option is kind of bad as I described. The second option was basically unusable since running PHPStan with an extension would invalidate the result cache, which really sucked for the user. Now that there's a separate diagnose command (albeit only in v1.11.8+) it's actually possible to do so without invalidating cache, which opens up a bunch of possibilities.
Hmm this is actually surprisingly hard to fix. What the extension currently does is that watches all open editors and, if VSCode signals that one of them changed, queues a new check if it's a PHP file.
I could switch this to watching for file changes workspace-wide, but then the issue becomes when to trigger a check and when not to. For example a change in
vendor/shouldn't trigger one, but one inindex.phpshould. You'd probably say "just read it from the phpstan config" but that's first of all relatively hard to parse (.neonis a file-format that's barely being used) and it's not trivial to match 1:1 what PHPStan's known list of files is. It's probably an imperfect solution but I'd suggest for now to either run a manual full-project check (> PHPStan: scan project for errors) or to usePHPStan Pro, which does include such features since it runs inside of PHPStan.(for the future: maybe nicer to open a separate issue for this, that also allows people who have the same question to find it, while allowing me to more clearly signal the status of the issue by marking it as closed/completed etc)
Originally posted by @SanderRonde in https://github.com/SanderRonde/phpstan-vscode/issues/80#issuecomment-2317404015
Response: Actually, when you modify /vendor, the signature of the methods on the vendor libraries could change, and the code could not be valid anymore ;)