Make it work with multiple services in a monorepo

[finn-matti]

In our current project we have a setup similar to this:

• Root
  • services
  • app1
    • phpstan.neon
    • vendor
    • \<sourceCode>
  • app2
    • phpstan.neon
    • vendor
    • \<sourceCode>

At the moment I can't use the extension, because it can't work with a setup like this, it seems. I see two options:

1. Offer per folder configuration (e.g. .vscode/settings.json), then I could configure the phpstan.neon to use, etc. - workspaces are supported, but not folders within a workspace.
2. Offer direct monorepo-support, probably by letting us specify a configuration object similar to what we would provide in the per folder config.

Personally I would prefer option 2, but would be happy with either solution. :)

Thanks for this awesome plugin and your consideration.

[SanderRonde]

While I like the idea, I think it requires quite a bit of work to get this working, and quite some fundamental changes to the extension. I think the main problem is that it would probably complicate things for non-monorepo users, or complicate the code around that. So I'm unfortunately leaning towards not doing this. Also largely because I think there aren't that many people running multi-php-project monorepos. But if this gets enough interest I'm of course willing to reconsider. I'll close it for the time being.

Out of interest though, what do you think of the approach of turning individual services within the monorepo into workspaces and using a per-workspace .vscode/settings.json? It might make switching between services a lot harder, but it would fix the issue. Although that does do away with one of the biggest advantages to monorepos.

[finn-matti]

@SanderRonde Thanks for the quick answer! I'd love to see this, but I understand your concerns, too.

Out of interest though, what do you think of the approach of turning individual services within the monorepo into workspaces and using a per-workspace .vscode/settings.json? It might make switching between services a lot harder, but it would fix the issue. Although that does do away with one of the biggest advantages to monorepos.

I think you gave the answer yourself, I'll add another point: This monorepo project is not the only one, so I already deal with a variety of vs code windows and would rather not add even more for every service of every monorepo.

Everyone else: If you're interested in such a feature, please add your thumbs up, to the first post. 👍

[SanderRonde]

Ah that makes sense. Thanks for the answer!

[finn-matti]

For anyone looking for a workaround: In my case it was possible to provide a global phpstan.neon that was not checked in to source control but added and excluded the paths by hand. As an example (I put this file inside .vscode, because it is not part of our repo. Beware! The .vscode folder is normally meant to share settings, etc. and may well be checked in in your case):

parameters:
    # ... other stuff
    paths:
        - ../services/app1/src
        - ../services/app2/src
        - ../libraries/util/src
    bootstrapFiles:
        - ../services/app1/vendor/autoload.php
        - ../services/app2/vendor/autoload.php
        - ../libraries/util/vendor/autoload.php
    excludePaths:
        analyse:
            - ../services/app1/vendor
            - ../services/app2/vendor
            - ../libraries/util/vendor

With this and the following config for the extension I got it to work:

"phpstan.configFile": ".vscode/phpstan.neon",
"phpstan.binCommand": ["phpstan"] //I installed phpstan globally