PhpStorm language level vs. composer config.platform.php: which source of truth should inspections follow?
0 reputation · 20 Jan 2023, 16:33 UTC
Our project runs a newer PHP CLI locally than the version deployed in production, and composer.json pins config.platform.php to the older target. PhpStorm appears to derive its project language level from Composer metadata in some places and from the configured interpreter in others, so the same file can be flagged as incompatible in one inspection pass and accepted in another.
The concrete goal is to pick one authoritative PHP version for IDE analysis so that inspections, quick-fixes, and new-syntax intentions match what the production runtime actually supports. The uncertainty is precedence: does the project language level setting override the Composer platform value, does the selected interpreter override both, and does this differ between recent PhpStorm releases or when using a remote/Docker interpreter?
Assuming a current PhpStorm release with the bundled Composer support plugin:
- When
config.platform.php, the project language level, and the configured interpreter disagree, which value do PHP language-feature inspections actually use? - Is there a supported way to lock the IDE to the Composer platform version so new-syntax intentions are never offered for the older target?
- Does switching to a remote interpreter change this precedence, and how can the effective language level be verified deterministically?