Psalm should load extensions based on composer.json instead of local configuration

[AndrolGenhald]

I was thinking about this recently although it hasn't directly affected me yet, but I saw it pop up for someone else so I thought I'd create an issue.

one of the purposes of the stubs is to enable the static analysis of the code that depends on an extension that is unavailable at runtime.

Oh, in that case you should instead provide your own stubs. If Psalm were to stub all classes it might miss situations where you're missing an extension.

Originally posted by @muglug in #5477 (comment)

With docker it's possible and probably even common for the local php configuration to be different from what's being used to run the code. If I have the PDO extension enabled locally, but composer doesn't require "ext-pdo" then psalm shouldn't load the PDO extension in case my local docker (or production!) environment doesn't use that extension.

It might also be a good idea to add a configuration option to enable or disable specific extensions in psalm.xml.

[orklah]

That's a comprehensible take by Matt, but I'm not sure I follow because I'm pretty sure Callmap will be loaded no matter what. So why loading simple functionlike definitions but not stubs? (for example: https://psalm.dev/r/097c2a2bf5)

If we wanted to go this far, we would need to identify what part of the callmap belong to which extension to be able to enable/disable them.

That seem far fetched. Honestly, I think we should enable all extensions from the start, loading only stubs conditionally is weird

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/097c2a2bf5

<?php

new Soapclient();

Psalm output (using commit b8a2ba2):

ERROR: TooFewArguments - 3:1 - Too few arguments for Soapclient::__construct - expecting 1 but saw 0

[AndrolGenhald]

Note to self: the decimal extension can be removed from CI if/when this is implemented (#7103). When running tests all extensions should be enabled.

[orklah]

This can be closed now