Feature: php extensions

[rtm-ctrlz]

It would be great to add a way to install additional extensions.

For example: vimeo/php-mysql-engine have errors with PDO::MYSQL_ATTR_INIT_COMMAND, since it comes with pdo_mysql extension.

Base docker image (php:7.4-alpine) have docker-php-ext-install which will do the job, ex. docker-php-ext-install pdo_mysql will download tools, compile extension, install it and delete tools; also tests will pass ;)

I tried to do it by myself and found out some ways to get extension installed before running test:

• using custom docker image: use vimeo/psalm-github-actions as a base + install of some extensions
  as result every person/project will come with it's own custom image, think it's not a best way
• install some extensions during vimeo/psalm-github-actions docker image build
  also isn't correct way because many users would like to add many extensions, so resulting image will be full of php-extensions
• pass list of needed extensions to entrypoint.sh to install before running test
  this is will not make image huge, but running tests (ex. at CI of vimeo/php-mysql-engine) will be more time- and cpu-consuming; also it isn't that simple (at least for me) to pass "list of string to shell command as a set of arguments" without security issues (like globbing) with only sh manipulations.

[bravik]

Maybe passing some psalm stubs for extension can be a 4th option.

[orklah]

Psalm 5 can now have different stubs enabled depending on config or composer requirements so this should fix this issue

[chaseconey]

Psalm 5 can now have different stubs enabled depending on config or composer requirements so this should fix this issue

@orklah Can you explain a little bit more what you mean by stubs? Not seeing any way to control the PHP extensions still and this is something that we are running into.

Thanks!

[orklah]

stubs are php file that describe symbols (in this context, function, constants or class that are from core php or from extensions). In Psalm 5 we made some improvement allowing enabling or disabling extensions by having separate stubs that can each be enabled or not (through composer, or config file). Before that, every symbol was described in the same way and there was no possibility to disable an extension and most of the missing symbols had to be loaded through Reflection (so by having the extension installed)

It's possible that no stubs exists for a given extension (or it may be incomplete), so they may need some improvements. Here's the list we have so far: https://github.com/vimeo/psalm/tree/master/stubs/extensions

[chaseconey]

Gotcha - that makes sense.

So if there are missing stubs there for an extension the options are:

• Add a stub and get it merged in
• Create our own image with said extension

Any other options?

Also, what are the odds of a scan being inaccurate if a stub is missing and we are using an ignore-platform check?

[orklah]

Technically, Psalm allow you to add custom stubs so you wouldn't even need to get it merged first.

If you make a scan without a specific extension installed and we don't have a stub (and we don't have the methods in the callmaps either: https://github.com/vimeo/psalm/tree/master/dictionaries), then Psalm will be unable to know some symbols. If you use them anyway, you should see UndefinedClass or UndefinedFunction or errors like that