This fixes the problem for psalm/phar, but leaves it unresolved for standalone phars (and phive, probably).

Other possible solutions would be:

1. Find a way to reference the XSD stored in a phar file itself
2. During the init, extract the XSD and reference the extracted file. This would require checking if XSD is up to date on every run, to account for future upgrades.

@zonuexe would you mind checking if referencing the XSD using relative phar path works? E.g. something like xsi:schemaLocation="https://getpsalm.org/schema/config phar://vendor/psalm/phar/psalm.phar/config.xsd"

Workaround, when using the latest version

https://github.com/ghostwriter/coding-standard/blob/ce354936ea46efae53de148e03e75d738628057f/resource/psalm.xml.dist#L1-L4

@weirdan

would you mind checking if referencing the XSD using relative phar path works? E.g. something like xsi:schemaLocation="https://getpsalm.org/schema/config phar://vendor/psalm/phar/psalm.phar/config.xsd"

Since xsi:schemaLocation is a hint to access the schema, tools like xmllint do not dynamically load xsi:schemaLocation, but instead validate the XML document using the schema specified with the --schema option.

The path phar://vendor/psalm/phar/psalm.phar/config.xsd is not really useful because it is different from the path PHP reads the contents from the Phar file.

There is no need to actually rewrite xsi:schemaLocation, and it works as follows in a project with psalm/phar installed.

% ./vendor/bin/psalm.phar --init
Calculating best config level based on project files
Calculating best config level based on project files
Target PHP version: 8.2 (inferred from composer.json).
Scanning files...
Analyzing files...

E░

Detected level 2 as a suitable initial default
Config file created successfully. Please re-run psalm.

% cat psalm.xml
<?xml version="1.0"?>
<psalm
    errorLevel="2"
    resolveFromConfigFile="true"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="https://getpsalm.org/schema/config"
    xsi:schemaLocation="https://getpsalm.org/schema/config vendor/vimeo/psalm/config.xsd"
    findUnusedBaselineEntry="true"
    findUnusedCode="true"
>
    <projectFiles>
        <directory name="src" />
        <ignoreFiles>
            <directory name="vendor" />
        </ignoreFiles>
    </projectFiles>
</psalm>

# Extract config.xsd from psalm.phar
% php -r '$p = new Phar("vendor/psalm/phar/psalm.phar", 0); copy("phar://{$p->getAlias()}/config.xsd", "psalm-config.xsd");'

% xmllint --noout --load-trace --schema psalm-config.xsd psalm.xml
Loaded URL="psalm-config.xsd" ID="(null)"
Loaded URL="psalm.xml" ID="(null)"
psalm.xml validates

It is possible to extract the config.xsd with simple PHP one-liner code, but it seems like a hack that should be avoided.

@ghostwriter

Workaround, when using the latest version

What will your workaround solve? Change xsi:schemaLocation of psalm.xml generated when executed as psalm.phar --init to vendor/psalm/phar/psalm.phar/config.xsd or https:// Replacing getpsalm.org/schema/config may be a useful next step for improvement.

There is no need to change the content of psalm.xml just to validate XML in CI.

@zonuexe

What will your workaround solve?

enables auto-completion, syntax error reporting, schema validation, and several additional features, depending on the IDE's capabilities or available extensions/plugins.

For CI, “Extract” the schema from the tagged source URL.

latest:

curl https://getpsalm.org/schema/config

versioned:

curl https://raw.githubusercontent.com/vimeo/psalm/{version}/config.xsd
curl https://raw.githubusercontent.com/vimeo/psalm/5.24.0/config.xsd

P.s. If you plan to create a script with a range of versions, figure out when config.xsd was first tagged.

What will your workaround solve?

this issue laminas/laminas-ci-matrix-action#301