Psalm: Feature Request: Level 9

Created on 11 Feb 2020  Â·  11Comments  Â·  Source: vimeo/psalm

How can initialize a psalm.xml with all available issues?

As far as I can see, level 8 does not include all issues, and it would be great if all other issues (with an implicit errorLevel="error") could be added to be more explicit (and make it easier to start working on a legacy code basis incrementally):

        <!-- level 9 issues - very fatal errors -->
        <UndefinedConstant errorLevel="error" />
        <UndefinedFunction errorLevel="error" />
        <UndefinedMethod errorLevel="error" />
        <UndefinedClass errorLevel="error" />
        <InvalidParamDefault errorLevel="error" />
        <UndefinedVariable errorLevel="error" />
        <NullPropertyFetch errorLevel="error" />
        <MismatchingDocblockParamType errorLevel="error" />
        <MismatchingDocblockReturnType errorLevel="error" />
        <InvalidClass errorLevel="error" />
        <LoopInvalidation errorLevel="error" />
        <TooFewArguments errorLevel="error" />
        <InvalidIterator errorLevel="error" />
        <UndefinedDocblockClass errorLevel="error" />
        <ParadoxicalCondition errorLevel="error" />
        <InvalidThrow errorLevel="error" />

Most helpful comment

I think "all info" is more usefully just "run Psalm but ignore non-zero exit code". With Psalm 3.9 the error levels are more explicit – all the things that are always treated as errors should in my view, always be treated as errors.

All 11 comments

Hey @caugner, can you reproduce the issue on https://psalm.dev ?

This is sort of the value of the baseline file, though

@muglug is that not what an empty <issueHandlers></issueHandlers> does ?

@SignpostMarv No, afaik any issue type not specified in the config is treated as an error. (Which means that any new issue type will pop up as errors for everyone.)

@caugner that's what I mean; it'll give you all available issues

@caugner You can get machine-readable list of all available issues from config.xsd (documented in IssueHandlersType element). It lists all the issues you can specify in <issueHandlers>, and is always up to date.

I would very much prefer to be specific and aware about which issue handler types I have enabled.

Initialising the config with a level 9 that has all issue handlers set to "info" would be my preferred way.

(The workaround by @SignpostMarv doesn't solve this.)

@caugner blank IssueHandler listing + @muglug's suggestion to use the baseline = equivalent of keeping IssueHandler up-to-date & setting everything to info.

Sorry, I don't see how this creates a psalm.xml that explicitly lists all issue handler types as "info".

How exactly does a baseline file help here? If I add code that causes a new issue, that issue will still show up as an error even though I haven't decided yet whether I want to treat that specific issue handler type as an error.

PS: If you want to ditch the levels altogether, I would understand this, but I don't understand why the levels go only from 3 to 8 and that there is no explicit level 9 for "all info" (like a level 1 or 2 for "all error".)

If I add code that causes a new issue, that issue will still show up as an error even though I haven't decided yet whether I want to treat that specific issue handler type as an error.

the same problem will occur if a new issue type gets added

the issue is not so much "all the things" as being able to conveniently re-initialise a psalm config?

I think "all info" is more usefully just "run Psalm but ignore non-zero exit code". With Psalm 3.9 the error levels are more explicit – all the things that are always treated as errors should in my view, always be treated as errors.

Was this page helpful?
0 / 5 - 0 ratings