Why?

[janopae]

What are the benefits of running Psalm, along with extensions, in a Docker image, instead of declaring it as a dev dependency of the application we analyse with Psalm (like the documentation proposes)?

[janopae]

Some disadvantages of the Docker approach are

• Allow loading Psalm plugins from the application source code #5
• automatic Psalm detection: Some libraries and frameworks offer automatic detection of whether a source repository uses Psalm an acts accordingly (such as https://github.com/zenstruck/foundry/, which adds specific type information in that case: https://github.com/zenstruck/foundry/blob/1.x/src/Bundle/Maker/Factory/FactoryGenerator.php#L144-L151). This doesn't work if psalm is not declared as a dependency nor installed in the source repository checkout

[tedsalmon]

For me, I don't have PHP installed outside of Docker because my workflows require multiple versions of PHP to be available for different projects.

[janopae]

For me, I don't have PHP installed outside of Docker because my workflows require multiple versions of PHP to be available for different projects.

Wouldn't multiple PHP versions actually be a reason against having psalm strictly attached to one PHP version in a Docker image seperate to the ones you use for other PHP commands? How do you ensure the PHP version in the Psalm docker image is among the ones you want to support?

You could use the same Docker image that you use for all of your other PHP related commands in that project for executing Psalm.

I still don't get the benefit of having psalm installed in that image with a custom PHP version and a fixed set of plugins, rather than using the version installed with composer with the PHP interpreter(s) you use for everything else.

CC @mpdude