2018-02-18 01:53:17 +01:00
# Dealing with code issues
2018-02-27 23:25:35 +01:00
Psalm has a large number of [code issues ](issues.md ). Each project can specify its own reporting level for a given issue.
Code issue levels in Psalm fall into three categories:
2020-11-23 23:25:30 +01:00
- `error` < br >
This will cause Psalm to print a message, and to ultimately terminate with a non-zero exit status
- `info` < br >
This will cause Psalm to print a message
- `suppress` < br >
This will cause Psalm to ignore the code issue entirely
2018-02-18 01:53:17 +01:00
The third category, `suppress` , is the one you will probably be most interested in, especially when introducing Psalm to a large codebase.
## Suppressing issues
There are two ways to suppress an issue – via the Psalm config or via a function docblock.
### Config suppression
You can use the `<issueHandlers>` tag in the config file to influence how issues are treated.
2020-07-21 20:02:23 +02:00
Some issue types allow the use of `referencedMethod` , `referencedClass` or `referencedVariable` to isolate known trouble spots.
2018-03-21 16:56:43 +01:00
2018-02-18 01:53:17 +01:00
```xml
< issueHandlers >
< MissingPropertyType errorLevel = "suppress" / >
< InvalidReturnType >
< errorLevel type = "suppress" >
< directory name = "some_bad_directory" / > <!-- all InvalidReturnType issues in this directory are suppressed -->
< file name = "some_bad_file.php" / > <!-- all InvalidReturnType issues in this file are suppressed -->
< / errorLevel >
< / InvalidReturnType >
2018-03-21 16:56:43 +01:00
< UndefinedMethod >
< errorLevel type = "suppress" >
< referencedMethod name = "Bar \Bat::bar" />
< file name = "some_bad_file.php" / >
< / errorLevel >
< / UndefinedMethod >
< UndefinedClass >
< errorLevel type = "suppress" >
< referencedClass name = "Bar \Bat \Baz" />
< / errorLevel >
2018-05-30 13:08:15 +02:00
< / UndefinedClass >
2020-02-20 19:36:54 +01:00
< PropertyNotSetInConstructor >
< errorLevel type = "suppress" >
< referencedProperty name = "Symfony \Component \Validator \ConstraintValidator::$context" />
< / errorLevel >
< / PropertyNotSetInConstructor >
2020-07-21 20:02:23 +02:00
< UndefinedGlobalVariable >
< errorLevel type = "suppress" >
2020-08-14 20:02:41 +02:00
< referencedVariable name = "$fooBar" / > <!-- if your variable is "$fooBar" -->
2020-07-21 20:02:23 +02:00
< / errorLevel >
2020-12-29 12:43:07 +01:00
< / UndefinedGlobalVariable >
< PluginIssue name = "IssueNameEmittedByPlugin" errorLevel = "info" / > <!-- this is a special case to handle issues emitted by plugins -->
2018-02-18 01:53:17 +01:00
< / issueHandlers >
```
### Docblock suppression
You can also use `@psalm-suppress IssueName` on a function's docblock to suppress Psalm issues e.g.
```php
2020-03-21 14:24:41 +01:00
< ?php
2018-02-18 01:53:17 +01:00
/**
* @psalm -suppress InvalidReturnType
*/
function (int $a) : string {
return $a;
}
```
You can also suppress issues at the line level e.g.
```php
2020-03-21 14:24:41 +01:00
< ?php
2018-02-18 01:53:17 +01:00
/**
* @psalm -suppress InvalidReturnType
*/
function (int $a) : string {
/**
* @psalm -suppress InvalidReturnStatement
*/
return $a;
}
```
2019-01-03 14:58:54 +01:00
2020-01-12 16:38:32 +01:00
If you wish to suppress all issues, you can use `@psalm-suppress all` instead of multiple annotations.
2019-01-03 14:58:54 +01:00
## Using a baseline file
2020-11-23 23:25:30 +01:00
If you have a bunch of errors and you don't want to fix them all at once, Psalm can grandfather-in errors in existing code, while ensuring that new code doesn't have those same sorts of errors.
2019-01-03 14:58:54 +01:00
```
vendor/bin/psalm --set-baseline=your-baseline.xml
```
will generate a file containing the current errors. You can commit that generated file so that Psalm running in other places (e.g. CI) won't complain about those errors either, and you can update that baseline file (to remove references to things that have been fixed) with
```
vendor/bin/psalm --update-baseline
```
2020-11-23 23:25:30 +01:00
Baseline files are a great way to gradually improve a codebase.
## Using a plugin
If you want something more custom, like suppressing a certain type of error on classes that implement a particular interface, you can use a plugin that implements `AfterClassLikeVisitInterface`
```php
< ?php
namespace Foo\Bar;
2021-01-06 15:05:53 +01:00
use Psalm\Plugin\EventHandler\AfterClassLikeVisitInterface;
use Psalm\Plugin\EventHandler\Event\AfterClassLikeVisitEvent;
2020-11-23 23:25:30 +01:00
use ReflectionClass;
/**
* Suppress issues dynamically based on interface implementation
*/
class DynamicallySuppressClassIssueBasedOnInterface implements AfterClassLikeVisitInterface
{
2021-01-06 15:05:53 +01:00
public static function afterClassLikeVisit(AfterClassLikeVisitEvent $event)
2020-11-23 23:25:30 +01:00
{
2021-01-06 15:05:53 +01:00
$storage = $event->getStorage();
2020-11-23 23:25:30 +01:00
if ($storage->user_defined
& & !$storage->is_interface
&& \class_exists($storage->name)
&& (new ReflectionClass($storage->name))->implementsInterface(\Your\Interface::class)
) {
$storage->suppressed_issues[-1] = 'PropertyNotSetInConstructor';
}
}
}
```