Deprecation message on loading php-ext stubs without explicitly declaring them as dependency or in a config

[alies-dev]

This PR replaces #8881, based on #8879 (comment).

In this PR we keep existing Psalm 5 behaviour to load some stubs for PHP ext using extension_loaded, but additionally we display a deprecation note. Example for redis:

Target PHP version: 8.1 (inferred from composer.json) Extensions enabled: dom, pdo (unsupported extensions: bcmath, curl, filter, gd, hash, iconv, intl, json, mbstring, openssl, pcntl, pdo_mysql, tokenizer, zip)
Scanning files...
Deprecation: Psalm stubs for ext-redis loaded using legacy way. Instead, please declare ext-redis as dependency in composer.json or use <enableExtensions> directive in Psalm config.
Analyzing files...

[orklah]

Thanks! As I was saying in the discussion, I'd also like if the psalm.xml creation came with loaded extension configured. Could you take a look?

[alies-dev]

@orklah

Thanks! As I was saying in the discussion, I'd also like if the psalm.xml creation came with loaded extension configured. Could you take a look?

Do you think this is a task for this PR or ok to create it in a separate?

Note, get_loaded_extensions(true) returns pretty short list, typically something like:

array(3) {
  [0]=>
  string(12) "Zend OPcache"
  [1]=>
  string(6) "Xdebug"
  [2]=>
  string(9) "blackfire"
}

while get_loaded_extensions(false) returns like:

array(44) {
  [0]=>
  string(4) "Core"
  [1]=>
  string(4) "date"
  [2]=>
  string(6) "libxml"
  [3]=>
  string(7) "openssl"
  [4]=>
  string(4) "pcre"
  [5]=>
  string(7) "sqlite3"
  [6]=>
  string(4) "zlib"
  [7]=>
  string(5) "ctype"
  [8]=>
  string(4) "curl"
  [9]=>
  string(3) "dom"
  [10]=>
  string(8) "fileinfo"
  [11]=>
  string(6) "filter"
  [12]=>
  string(3) "ftp"
  [13]=>
  string(4) "hash"
  [14]=>
  string(5) "iconv"
  [15]=>
  string(4) "json"
  [16]=>
  string(8) "mbstring"
  [17]=>
  string(3) "SPL"
  [18]=>
  string(7) "session"
  [19]=>
  string(3) "PDO"
  [20]=>
  string(10) "pdo_sqlite"
  [21]=>
  string(8) "standard"
  [22]=>
  string(5) "posix"
  [23]=>
  string(6) "random"
  [24]=>
  string(8) "readline"
  [25]=>
  string(10) "Reflection"
  [26]=>
  string(4) "Phar"
  [27]=>
  string(9) "SimpleXML"
  [28]=>
  string(9) "tokenizer"
  [29]=>
  string(3) "xml"
  [30]=>
  string(9) "xmlreader"
  [31]=>
  string(9) "xmlwriter"
  [32]=>
  string(7) "mysqlnd"
  [33]=>
  string(6) "bcmath"
  [34]=>
  string(2) "gd"
  [35]=>
  string(4) "intl"
  [36]=>
  string(5) "pcntl"
  [37]=>
  string(9) "pdo_mysql"
  [38]=>
  string(5) "redis"
  [39]=>
  string(6) "sodium"
  [40]=>
  string(3) "zip"
  [41]=>
  string(9) "blackfire"
  [42]=>
  string(12) "Zend OPcache"
  [43]=>
  string(6) "xdebug"
}

Or do you want to run that check only for a specific list for ext?

[alies-dev]

On this topic, @nikic recently classified PHP ext by 3 types, I think we can use this classification for Psalm also: https://wiki.php.net/rfc/namespaces_in_bundled_extensions :

• Required extensions (including Core and standard). These extensions are always present, and PHP cannot be built without them.
• Bundled extensions (including ctype and mbstring). These extensions are part of the php-src distribution, but PHP can be built without them. Bundled extensions can be either enabled or disabled by default.
• 3rd-party extensions (including apcu and igbinary). These extensions are not part of the php-src distribution, and either available through PECL, or simply on GitHub.

[orklah]

It seems unnecessary to have special stubs for the first category. For the two others, we can handle the way we do now.

Thanks! Please check if you can add the automatic loading in psalm's config, it would be weird to release without it (as we would create a config and complain that things are missing in the config on the first run!

[alies-dev]

Thanks! Please check if you can add the automatic loading in psalm's config, it would be weird to release without it (as we would create a config and complain that things are missing in the config on the first run!

Note, Psalm init command often runs on developer's machine that may have more ext than needed (e.g. for another project you needed gd and it's available on your system). This way this ext will be added to the initial psalm config, what can be confusing. So, for me it's not so straightforward what is the best approach of generating psalm.xml.

I can create a new PR to update \Psalm\Config\Creator::createBareConfig and related code, but please give me a green light before it taking into account my concerns from above. Thanks!

[orklah]

Well, it's not really a big deal if we get more extensions than needed though.

Worst case scenario:

• the psalm config (which is pretty short on creation) will have a few extensions that were on the developer machine and not on the production machine
• the file is committed as is without verification
• the developer end up using a function from an extension that he doesn't have on production
• The tests fails to catch it

If all those conditions are true, we could have a faulty code on production. But even then, it was just the behavior of Psalm until 5.0 (we assumed every extension was enabled)

[kenjis]

Is this a bug?

Deprecation: Psalm stubs for ext-redis loaded using legacy way. Instead, please declare ext-redis as dependency in composer.json or use <enableExtensions> directive in Psalm config.

--- a/psalm.xml
+++ b/psalm.xml
@@ -16,4 +17,7 @@
             <directory name="app/Views" />
         </ignoreFiles>
     </projectFiles>
+    <enableExtensions>
+        <extension name="redis"/>
+    </enableExtensions>
 </psalm>

$ vendor/bin/psalm 
Problem parsing /.../psalm.xml:
  Error on line 21:
    Element '{https://getpsalm.org/schema/config}extension', attribute 'name': [facet 'enumeration'] The value 'redis' is not an element of the set {'decimal', 'dom', 'ds', 'geos', 'gmp', 'mongodb', 'mysqli', 'pdo', 'simplexml', 'soap', 'xdebug'}.

[alies-dev]

@kenjis
Thanks for reporting. Yes, this is a bug. I've created a quick-fix for it: #8971