search

SanderRonde / phpstan-vscode

PHPStan plugin for VSCode
https://marketplace.visualstudio.com/items?itemName=SanderRonde.phpstan-vscode
MIT License
37 stars 7 forks source link

Improve support for multiple open VS Code projects #81

Closed lkrms closed 3 weeks ago

lkrms commented 3 weeks ago

This issue isn't directly related to multi-root workspaces, but solving it will probably allow the extension's first-workspace-folder-only restriction to be removed.

I'm often working on multiple PHP projects in multiple VS Code windows at the same time. If a PHPStan scan triggered in one window finishes before another is triggered in a different window, this works well enough (aside from the performance hit caused by the constant cache flushing, which is pretty significant for one of my projects).

If multiple scans are triggered simultaneously, the best-case scenario is that they cancel each other out, flushing each other's caches (as already mentioned) and leaving issues unreported, but if VS Code opens multiple PHP workspaces simultaneously, I've found they can trigger a worst-case scenario: VS Code repeatedly crashing on startup (exiting without explanation shortly after the first window appears).

I've observed this on Linux but can't replicate it on the Mac I'm currently using. The last file touched in ~/.vscode at the time was in ./extensions/sanderronde.phpstan-vscode-3.1.9, which tipped me off that I should try opening PHP projects one at a time, which got things working again.

I've since noticed the extension services every project via one configuration file and cache directory, which explains these issues/limitations. Instead of creating one _config directory for all projects, can I suggest generating a hash of each workspace folder path and creating multiple _config/<hash> directories? This would prevent projects in different windows disrupting each other and significantly improve the extension's performance (with quantifiable power consumption savings in some cases!)

The only potential issue I can think of is cache bloat, i.e. _config directories outliving the projects they were created for, but the extension wouldn't be alone in this and it could be mitigated easily enough with a "delete configurations not used in X days" task at extension startup if it becomes a problem.

I don't have time/headspace to create a PR for this at the moment but am happy to have a go in a couple of months if there's any interest.

Thanks again for creating this excellent extension!

SanderRonde commented 3 weeks ago

Oh wow I don't know how I didn't think of this myself when choosing to use the extension folder as the cache dir. I'll definitely do this, thanks for bringing it to my attention :)

SanderRonde commented 3 weeks ago

Should be fixed in version 3.1.10

lkrms commented 3 weeks ago

Amazing turnaround! Works perfectly. Thanks so much!