JakubMisek Since we're working with WordPress plugins, we keep our linting configs (ESLint, PHPCS, PHPStan, etc.) in the root of each plugin we maintain.
While phpstan.dist.neon / phpstan.neon.dist is the recommended file to check into VCS, we currently use phpstan.neon as the file as we haven't had a need for overriding a dist file.
To recap, we have our workspace root in VS Code as the webroot of a WordPress site which contains folders such as index.php, wp-content, wp-includes, etc.
Then, in wp-content/plugins, we have our plugins each containing their own configs.
Ideally whichever file you have open, it would try to find the closest phpstan.neon file, but this hasn't really been a pattern I've seen in VS Code outside of maybe ES Lint. For PHP_CodeSniffer, we just use a fairly loose config in the workspace root and let CI/CD catch more specific errors.
If that's the direction you have to go with the PHPStan config, I can understand. We'd still get a ton of value out of being able to plop a config in the workspace root containing a bunch of type aliases.
