durable-dev/psalm-magento.xml at main · gplanchat/durable-dev · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<?xml version="1.0"?>
<!--
    The Magento module's analysis, kept apart.

    ⚠ It cannot join `psalm.xml`: the module talks to classes this repository does not install —
    the distribution weighs close to a gigabyte and has no business in the component's
    dependencies. So it runs in the job that installs it already, the one that starts the bench,
    and reads the real classes through the bench's autoloader rather than through hand-written
    stubs. An approximate stub does not make an error: it hides one.

    The rest — level, issue handling, dead code — is copied from `psalm.xml` verbatim: two
    severities for one repository would make a package's cleanliness a matter of configuration.
-->
<psalm
    errorLevel="4"
    resolveFromConfigFile="true"
    autoloader="magento/vendor/autoload.php"
    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="false"
>
    <projectFiles>
        <directory name="src/DurableModule" />
        <ignoreFiles allowMissingFiles="true">
            <directory name="vendor" />
            <!-- ⚠ Only the module's **copy** is set aside, not the whole bench vendor: what
                 `ignoreFiles` sets aside is not merely left unanalysed, it is skipped at scan time
                 — and the rest of the bench is precisely what carries the Magento classes.
                 `allowMissingFiles` because a changing installation layout must not end in a
                 configuration read failure.
                 ⚠ Two copies of the core stay reachable — the root autoloader leads to
                 `src/Durable`, the bench's to `magento/vendor/gplanchat/durable` — and that is
                 safe **only because both come from the same commit**: the bench's `path`
                 repository reads `../src`. A bench installed earlier makes the analysis say that
                 properties added since do not exist, which was verified the hard way. -->
            <directory name="magento/vendor/gplanchat/durable-magento" />
        </ignoreFiles>
    </projectFiles>

    <issueHandlers>
        <!-- Same suppressions as `psalm.xml`, for the same reasons. -->
        <UndefinedMethod errorLevel="suppress" />
        <DocblockTypeContradiction errorLevel="suppress" />
        <RedundantConditionGivenDocblockType errorLevel="suppress" />
        <PossiblyInvalidMethodCall errorLevel="suppress" />
        <UnusedClass errorLevel="suppress" />
        <MissingOverrideAttribute errorLevel="suppress" />
        <!-- ⚠ Reported **in Magento's code**, not in ours: `AbstractDataProvider` annotates
             `@return null` on a method whose interface promises a `SearchCriteriaInterface`. This
             repository does not fix upstream, and leaving it red would fail the module's analysis
             on a line nobody here can touch. The suppression is therefore **bounded to the bench
             vendor**: the same rule stays active on `src/DurableModule`. -->
        <ImplementedReturnTypeMismatch>
            <errorLevel type="suppress">
                <directory name="magento/vendor" />
            </errorLevel>
        </ImplementedReturnTypeMismatch>
    </issueHandlers>
</psalm>