PHPStan Blog

PHPStan 1.12: Road to PHPStan 2.0

2024-08-27T00:00:00Z

After three years since the initial PHPStan 1.0 release, we’re getting closer to PHPStan 2.0. After sifting through my list of ideas for the new major version, I realized I can move some of them forward and release them in 1.x series and hide them behind the Bleeding Edge config toggle, so they can be enjoyed by PHPStan users sooner.

This isn’t true just for PHPStan 1.12 but ever since 1.0. If you enable Bleeding Edge, you basically live in the future. You get new rules and behavior changes that will be enabled for everyone in the next major version. That’s your reward as an early adopter.

Here’s an equation:

PHPStan 2.0 = PHPStan 1.12 + Bleeding Edge + BC breaks

When you upgrade to PHPStan 1.12 and enable Bleeding Edge, you can get mostly ready for PHPStan 2.0 today.

But enough about the future. Here’s what’s new in today’s 1.12 release.

General availability of precise type inference for regular expressions #

This is a rare example of a feature that began its life in Bleeding Edge but got out of it sooner than the next major version. Because of its complexity we needed a staged rollout to weed out the bugs.

First introduced in 1.11.6, and improved by dozens of pull requests since then, this feature is about figuring out the precise type for $matches by-ref argument coming from preg_match() and other related functions:

if (preg_match('/Price: (?<currency>£|€)\d+/', $s, $matches, PREG_UNMATCHED_AS_NULL)) {
	// array{0: string, currency: non-empty-string, 1: non-empty-string}
	\PHPStan\dumpType($matches);
}

Markus Staab and Jordi Boggiano of Composer fame worked really hard on this. It brings a whole new level of precision to PHPStan’s type inference.

From what I gathered, this ability is pretty unique and not many programming languages offer it. And now we have it in PHP!

PHPStan performs four categories of sanity checks on types in PHPDocs:

Missing types: performed on level 6 and up, it enforces specifying array value types, generic types, and optionally also callable signatures.
Existing classes: looks for nonexistent classes and also trait references
Unresolvable types: looks for never bottom type that resulted from impossible intersections like string&int, referencing undefined constants like Foo::BAR, etc.
Generics type checks: checks sanity of generic types. Compares the number of type variables in a type against the number of @template above the class declaration, checks the subtyping of bounds, etc.

These type checks weren’t performed consistently for all supported PHPDocs tags. We were missing most or all of these checks for these tags:

@param-out
@param-closure-this
@param-immediately-invoked-callable and @param-later-invoked-callable
@phpstan-self-out
@mixin
@property
@method
@extends, @implements, @use

PHPStan 1.12 fixes that. Wrong and corrupted types are checked consistently across the board. Because these are essentially new rules which would cause new errors reported for most codebases, they were added only to Bleeding Edge, and will be enabled for everyone in PHPStan 2.0.

Too wide private property type #

Another addition to Bleeding Edge checks if a type could be removed from a private property union type, without affecting anything.

// if string is never assigned to `$this->a`, we can remove it from the type
private int|string $a;

PHPStan already had this rule for function and method return types, and now we can enjoy it for properties too.

PHP 8.4 runtime support #

Implementing support for new PHP version in PHPStan comes in four phases:

Make sure PHPStan runs on the new PHP version and all tests pass.
Understand added functions and changed signatures of existing functions in the new PHP version.
Understand new syntax and features. This removes false errors when analysing code written against the new PHP version.
Implement new rules specific to new syntax and features. Discover which parts of the new PHP features are tricky and need to be checked with new static analysis rules.

PHPStan 1.12 implements the first two phases. It runs on PHP 8.4 without any deprecation notices, and new functions like array_find() are already known.

Because of new syntax, the rest is dependent on upgrading to nikic/PHP-Parser v5 which has to be done in a major version.

My plan for the upcoming months is straightforward: finish and release PHPStan 2.0, and then work on PHP 8.4-specific features.

Me and PHPStan contributors put a lot of hard work into this release. I hope that you’ll really enjoy it and take advantage of these new features! We’re going to be waiting for everyone’s feedback on GitHub.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

PHPStan Reports Different Errors Locally & in CI. What Should I Do?

2024-08-20T00:00:00Z

If you find that PHPStan reports different code on your machine and in continuous integration build system, here are the steps to follow to get rid of this problem.

Is it analysing the same code? #

Make sure you’re looking at the results of the same Git commit in CI as you have checked out locally, and that you have committed all the files in your working directory.

Run git rev-parse HEAD or look at git log to get the Git commit hash. CI systems usually print the current Git commit hash somewhere early in the build log.

Run git status to make sure there are no uncommitted changes you’re running the analysis against.

Is it running the same PHP version? #

Make sure to check that you’re running the same PHP version locally and in CI. You can check that with php -v.

Require PHPStan in your Composer project #

Do not run PHPStan installed somewhere globally in your operating system, nor locally, neither in CI. Install PHPStan in composer.json with your project dependencies with this command:

composer require --dev phpstan/phpstan

This way you will make sure everyone and everything is on the same PHPStan version - your machine, your teammates and most importantly, CI.

Make sure your `composer.lock` is committed in the Git repository #

Commit and version your composer.lock file in Git to make sure your dependencies are locked and always the same until you update them.

Run `composer install`, not `composer update` #

Even with composer.lock committed, make sure you run composer install to install dependencies in CI. Running composer update discards the contents of your composer.lock file and updates all dependencies. Which is something we don’t want.

Run PHPStan’s `diagnose` command to compare the environments #

Since release 1.11.8 PHPStan ships with a diagnose command. It prints useful information about its configuration and more. Do not forget to pass the correct configuration file and rule level when running the command.

The output looks like this:

PHP runtime version: 8.3.1
PHP version for analysis: 8.3.99 (from config.platform.php in composer.json)

PHPStan version: 1.11.11
PHPStan running from:
/var/www/project/vendor/phpstan/phpstan

Extension installer:
composer/pcre: 3.2.0
phpstan/phpstan-deprecation-rules: 1.2.0
phpstan/phpstan-doctrine: 1.4.8
phpstan/phpstan-nette: 1.3.5
phpstan/phpstan-phpunit: 1.4.0
phpstan/phpstan-strict-rules: 1.6.0
phpstan/phpstan-symfony: 1.4.6
phpstan/phpstan-webmozart-assert: 1.2.7
shipmonk/phpstan-rules: 3.1.0

Discovered Composer project root:
/var/www/project

Doctrine's objectManagerLoader: In use
Installed Doctrine packages:
doctrine/dbal: 3.8.6
doctrine/orm: 2.19.6
doctrine/common: 3.4.4
doctrine/collections: 2.2.2
doctrine/persistence: 3.3.3

Symfony's consoleApplicationLoader: No

Compare the output between your local machine and CI to find possible differences.

Check the config file path #

Make sure you’re running PHPStan analyse command with the same configuration file. If you’re passing a custom path with -c, make sure it’s the same one as locally.

If you’re letting PHPStan autodiscover phpstan.neon or phpstan.neon.dist file in the current working directory, it outputs this note at the beginning of the analysis:

Note: Using configuration file /var/www/project/phpstan.neon.

Make sure your local machine uses the same file as the CI environment.

Get rid of duplicate symbols #

If you have two or more different class or function definitions with the exact same name, PHPStan does not guarantee which one it’s going to give priority to. Your local machine might discover one definition first and your CI might discover a different definition first, leading to different analysis results.

Rename your classes and functions so that they are always unique to get rid of this problem.

Fix your custom non-deterministic autoloader #

Sometimes the difference in results comes down to the order of files during the analysis. Because the CI environment might have a different number of CPU cores, the files are going to be analysed in different groups and in different order than on your local machine.

If the difference is about what classes are known and unknown to PHPStan, it’s possible you’re using a custom autoloader to discover them.

A following scenario can occur:

You’re referencing a class name in your code with wrong case. For example. Your class name is AdminUser but you have adminUser somewhere in your code when referencing the same class.
On your local machine the first file that’s analysed refers to the class with the correct name - AdminUser. That makes other occurrences even with the wrong case let the class to be successfully found by PHPStan.
In CI the first file that’s analysed refers to the class with an incorrect name - adminUser. Your custom autoloader should still find the class successfully but maybe has a bug. This makes PHPStan report “unknown class” error and it also makes it memoize that this class does not exist.
When the second file that’s analysed in CI refers correctly to AdminUser, it still makes PHPStan report an error about unknown class which is a different behaviour than you’re experiencing locally.

To fix this problem, make your autoloader discover classes even with wrong case.

Open a discussion on PHPStan’s GitHub #

If none of the steps above helped you to get consistent results between running PHPStan locally and in CI, please open a discussion on GitHub, so we can help you figure out this problem.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

Debugging PHPStan Performance: Identify Slow Files

2024-07-05T00:00:00Z

If you feel like PHPStan could be faster when analysing your project, you can debug what’s actually making it slow. Usually the cause of slow analysis can be pinpointed to a single file or a handful of files in a project that make PHPStan’s analysis crawl to a halt.

Before you start debugging, try enabling Bleeding Edge. It makes analysis in huge codebases run much faster. It comes with a slight backward compatibility break with the advantage of breaking bidirectional memory references, making the job of garbage collector easier.

If that didn’t help, run PHPStan again but add -vvv --debug command line options. PHPStan will run in a single thread instead of in multiple processes at once, and it will print the elapsed time and consumed memory during the analysis of each file:

/var/www/src/Database/Eloquent/Relations/MorphToMany.php
--- consumed 6 MB, total 200 MB, took 0.11 s
/var/www/src/Database/Eloquent/Relations/HasOneThrough.php
--- consumed 0 B, total 200 MB, took 0.06 s
/var/www/src/Database/Eloquent/Relations/MorphPivot.php
--- consumed 0 B, total 200 MB, took 0.06 s
/var/www/src/Database/Eloquent/Relations/Pivot.php
--- consumed 2 MB, total 202 MB, took 0.09 s
/var/www/src/Database/Eloquent/Relations/HasOneOrMany.php
--- consumed 0 B, total 202 MB, took 0.15 s
/var/www/src/Database/Eloquent/Relations/BelongsTo.php
--- consumed 0 B, total 202 MB, took 0.15 s

You can either watch this log go by in realtime with your own eyes and spot files that took too much time or memory. Or you can redirect the output to a file:

vendor/bin/phpstan -vvv --debug > phpstan.log

And parse this file with a simple script by Ruud Kamphuis that sorts the file list and puts the files that took the most time on top:

<?php declare(strict_types=1);

$log = new SplFileObject("phpstan.log");

$logs = [];
$file = null;
while (!$log->eof()) {
    $line = trim($log->fgets());
    if ($line === '') {
        continue;
    }
    if ($file === null) {
        $file = $line;
        continue;
    }
    if (preg_match('/took (?<seconds>[\d.]+) s/', $line, $matches) !== 1) {
        continue;
    }

    $logs[] = [(float) $matches['seconds'], $file];
    $file = null;
}

usort($logs, fn(array $left, array $right) => $right[0] <=> $left[0]);
$logs = array_slice($logs, 0, 20);

echo "Slowest files" . PHP_EOL;
foreach ($logs as $log) {
    echo sprintf("%.2f seconds: %s", $log[0], $log[1]) . PHP_EOL;
}

Save this file into parse.php in the same directory where phpstan.log is and run it:

php parse.php

It will output 20 files that took the most time:

Slowest files
4.46 seconds: /var/www/src/Collections/LazyCollection.php
2.71 seconds: /var/www/src/Support/Str.php
2.56 seconds: /var/www/src/Console/Command.php
2.45 seconds: /var/www/src/Validation/Validator.php
2.44 seconds: /var/www/src/Database/Query/Builder.php
2.41 seconds: /var/www/src/Collections/Collection.php
2.12 seconds: /var/www/src/Database/Eloquent/Builder.php
2.10 seconds: /var/www/src/Foundation/Testing/TestCase.php
2.01 seconds: /var/www/src/Database/Eloquent/Model.php
...

What to do with this list? It’s up to you to decide. Maybe the slowest file is really large and maybe even auto-generated. Analysing it with PHPStan doesn’t probably bring too much value, so you can exclude it from the analysis and make PHPStan immediately faster.

But if the slowest file isn’t that large, you’ve just found a real bottleneck which is an opportunity to make PHPStan faster. Take this file and open a new bug report in PHPStan’s GitHub repository so we can take a look and use it to make PHPStan faster.

Happy debugging!

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

PHPStan 1.11 With Error Identifiers, PHPStan Pro Reboot and Much More

2024-05-13T00:00:00Z

This release has been in the works for a year. But it doesn’t mean there hasn’t been anything else released for a year. After starting the work on PHPStan 1.11 I continued working on 1.10.x series in parallel, bringing 54 releases into the world between April 2023 and 2024. But at some point earlier this year I said “enough!” and couldn’t resist finally bringing the awesome improvements in 1.11 over the finish line and into the world.

Error Identifiers #

When I decided to add error identifiers I knew it was going to be a lot of work. They’re a way of labeling and categorizing errors reported by PHPStan useful for ignoring errors of a certain category among other things.

I had to go through all PHPStan rules and decide how the identifier should look like for all of them. I’ve settled on two-part format category.subtype pretty early on as being easy to read and memorize. Other tools like TypeScript have settled on simple numbers like TS2322. In my opinion that’s as human-friendly as IP addresses. There are reasons why we need DNS to translate that to actual names.

Another easy way out would be to mark the rule’s implementation class name as its identifier. But I’ve never considered these to be user-facing and stable. They’re implementation details. To give them public meaning would really tie our hands when evolving PHPStan. Because some rule classes report very different issues resulting in multiple identifiers, and at the same time, different rules report very similar issues in PHP code resulting in a single identifier.

So a more flexible approach was needed. You can see for yourself how it turned out. There’s a catalogue on PHPStan’s website with all the identifiers. You can group them by identifier (and see all the rules where the same identifier is reported), or group them by the rule class (and see all the identifiers reported by the same class). This page is generated by analysing PHPStan sources with PHPStan to be used on PHPStan’s website. There’s probably an Inception or Yo Dawg joke somewhere in there.

So let’s say we have an error and we want to find out its identifier in order to ignore it. If we’re using the default table output formatter, we can run PHPStan with -v and see the identifiers right in the output:

Or we can run PHPStan Pro by launching PHPStan with --pro CLI option and see the identifier in the UI next to the reported error:

Once we know the identifier we can use it in the new @phpstan-ignore comment annotation that replaces the current pair of @phpstan-ignore-line and @phpstan-ignore-next-line annotations which ignore all errors on a certain line. With @phpstan-ignore PHPStan figures out if there’s some code besides the comment on the current line (and ignores an error in that code), or if we want to ignore an error in the code on the next line:

// Both variants work:
// @phpstan-ignore echo.nonString
echo [];

echo []; // @phpstan-ignore echo.nonString

In @phpstan-ignore specifying an identifier is always required.

If we want to ignore multiple errors on the same line, we can place multiple identifiers separated by a comma in the @phpstan-ignore annotation.

echo $foo, $bar;  // @phpstan-ignore variable.undefined, variable.undefined

Yes, we need to repeat the same identifier twice if we want to ignore two errors of the same type on the same line. Better safe than sorry!

We might also want to explain why an error is ignored. The description has to be put in parentheses after the identifier:

// @phpstan-ignore offsetAccess.notFound (exists, set by a reference)
data_set($target[$segment], $segments, $value, $overwrite);

We can also use identifiers in our configuration’s ignoreErrors section. This ignores all errors that match both the message and the identifier:

parameters:
	ignoreErrors:
		-
			message: '#Access to an undefined property Foo::\$[a-zA-Z0-9\\_]#'
			identifier: property.notFound

Or we can ignore all errors of a specific identifier:

parameters:
	ignoreErrors:
		-
			identifier: property.notFound

Across PHPStan core and 1^st extensions there’s a total of 728 identifiers in 364 rule classes. ^[1] I think I managed to strike a good middle ground with the granularity between being too coarse and being too fine.

PHPStan Pro Wizard #

I introduced PHPStan Pro in September 2020 as a paid addon for PHPStan that doesn’t remove anything from the beloved open-source version, but adds extra features that make PHPStan easier to use. Since that PHPStan Pro grew steadily and contributes about one third to my income from PHPStan. That made my open-source work sustainable and I’m really grateful for that.

I’ve had many ideas how to make PHPStan Pro more useful and interesting but I mostly sat on them for the first three years since the initial release, choosing to work on open-source PHPStan instead.

Error identifiers brought the perfect opportunity to turn to PHPStan Pro again. Right now your codebase is probably full of @phpstan-ignore-line and @phpstan-ignore-next-line comments. They ignore all errors on specific lines. All future errors introduced from the point you type out these comments are silently ignored without you ever seeing them. Which is dangerous.

What if you could snap your fingers and all of these comments magically turned into the new @phpstan-ignore with the right identifiers filled out?

- // @phpstan-ignore-next-line
+ // @phpstan-ignore argument.type
  $this->requireInt($string);

PHPStan Pro introduces a migration wizard that’s going to do this for you! Let’s run PHPStan with --pro CLI option and see it in action:

With just a few clicks your codebase can be modernized and made safer thanks to this wizard.

PHPStan Pro now ships with this single wizard, but I have a lot more ideas how wizards could be used to update various aspects of your codebases related to static analysis like typehints and PHPDocs and leave them in a better state. My plan is to do regular “wizard drops” (like feature drops). As the foundation has been laid out, it shouldn’t take long for more awesome wizards to appear!

PHPStan Pro UI Revamp #

But wizards are not the only thing that has changed about PHPStan Pro. Since the beginning PHPStan Pro has been about browsing errors in a web UI instead of a terminal.

You’re probably familiar with this saying:

If you’re not embarrassed by the first version of your product, you’ve launched too late.

Well I’m definitely not guilty of that 🤣 PHPStan Pro up until today did not have a good UI. Each error was rendered in a separate box so if you had multiple errors around neighbouring lines, you could quickly lose context. They weren’t presented in a clear and understandable way. Additionally, you could lose the focus on currently showing file if you reloaded the webpage. The sidebar panel wasn’t sticky so it shifted away if you scrolled a long file. It was not possible to remap Docker path to the host’s filesystem.

I could continue down this unending embarrassing list of shortcomings of the previous version, but let me put an end to that.

The new version you’ll get once you update to PHPStan 1.11 and launch Pro with --pro is much better. Let’s have a look:

The layout is more natural and resembles an IDE. Each file is rendered just once and errors are attached to lines where they are reported. You can expand hidden lines to see more context around an error. Docker paths can be remapped so that editor links lead to the correct file.

PHPStan lets you see ignored errors too. If you’ve inherited a project and want to see what errors the previous team ignored, or if you want to check the errors lurking in your huge baseline, PHPStan Pro lets you do that with ease. By default it will show a small pill button you can use to see ignored errors near normally reported errors, but you can also change the setting to show and browse all ignored errors:

PHPStan Pro analyzes your codebase in the background and refreshes the UI with the latest errors automatically. If you don’t want to keep your hands warm while your laptop struggles to keep up with too-frequent analysis, you can choose to run it only when the PHPStan Pro window is in focus, or pause it altogether:

PHPStan Pro costs €7/month for individuals and €70/month for teams. If you decide to pay annually, you’ll get PHPStan Pro for 12 months for the price of 10 months – that’s €70/year for individual developers, €700/year for teams.

There’s a 30-day free trial period for all the plans. And there’s no limit on the number of projects - you can run PHPStan Pro on any code you have on your computer.

Start by running PHPStan with --pro or by going to account.phpstan.com and creating an account.

Is this function really pure? #

We’re not even close to the end of the list of what’s new in PHPStan 1.11.

The @phpstan-pure annotation has been supported for a long time to mark functions that don’t have any side effects. That’s useful for remembering and forgetting returned values among other things.

But PHPStan didn’t enforce the truthiness of this annotation. It always obeyed it. This release changes that. I went through the trouble of deciding what language construct is pure or not for all statement and expression types. PHPStan now understands for example that $a + $b is always pure but calling sleep(5) or assigning a property outside of constructor is impure.

Once we have that information we can use it for multiple opportunities as marking some pieces code as wrong. Pure expressions always have to be used so it doesn’t make sense to have these on a separate line without using the results:

$a + $b;
new ClassWithNoConstructor();
$cb = static function () {
    return 1 + 1;
};
$cb(); // does not do anything

Besides reporting functions annotated with @phpstan-pure but having side effects as wrong, we can now also afford marking functions with @phpstan-impure without any side effects also as wrong. And finally, void-returning functions (which are understood as impure implicitly) that do not have any side effects are also reported as wrong. What would be a point of calling a function that doesn’t have a side effect and doesn’t return any value?

Clamping this problem space from all sides allowed us to weed out some bugs by testing development versions on real-world projects.

For all of this to be applicable to real-world situations, we also added new pure-callable and pure-Closure PHPDoc types that can be called even in pure functions.

Make sure to enable bleeding edge to take advantage of these new rules.

When is a passed callable called? #

Callables are severely underdocumented in PHP projects. You could already type and enforce the signature of a callable to make it more useful for static analysis:

/**
 * @param callable(int, int): string $cb
 */

But other aspects of callables remained mysterious for PHPStan. What happens to a callback when it’s passed to another function? Is it called immediately or later? This information can become handy for purity checks described in previous section, and also for bringing exceptions under control.

$this->doFoo(function () {
    if (rand(0, 1)) {
        throw new MyException();
    }
});

It would be useful for PHPStan to know if this call to method doFoo should be surrounded with a try-catch or if the thrown MyException should be documented in @throws PHPDoc tag. But it needs to know if this callback is called immediately, or saved for later invocation.

PHPStan 1.11 introduces a new pair of PHPDoc tags for this purpose:

@param-immediately-invoked-callable
@param-later-invoked-callable

The default reasonable convention if these tags are not present is that callables passed to functions are invoked immediately, and callables passed to class methods are invoked later.

You need these PHPDoc tags only to override the defaults, so you’ll use @param-immediately-invoked-callable above methods and @param-later-invoked-callable above functions.

What is a passed closure bound to? #

PHP’s methods Closure::bind and Closure::bindTo are used to change what $this refers to in a non-static closure. Doing that can lead to confusing PHPStan:

// we're in class Foo
// $this is Foo here
$this->doSomething(function () {
    // PHPStan still thinks $this is Foo here
    // but it could be something different
});

If your function binds passed closure to some other object, you can now use new PHPDoc tag @param-closure-this to inform PHPStan about it:

/**
 * @param-closure-this \stdClass $cb
 */
function doFoo(callable $cb): void
{
    $cb->bindTo(new \stdClass());
    // ...
}

It fully works with generics and conditional types so you can really go crazy in there!

New options for possibly nonexistent offsets in arrays #

PHPStan by default tries not to complain too much about code that might be totally fine. One example is accessing offsets of arrays without checking that these offsets actually exist first.

/**
 * @param array<string, Item> $items
 */
function doFoo(array $items, string $key): void
{
    // this might exist but might not
    $selectedItem = $items[$key];
}

Tom De Wit kindly contributed a pair of new configuration options to have potential these issues reported.

To have the error reported in the example above, turn on reportPossiblyNonexistentGeneralArrayOffset.

To have the same error reported for constant arrays, also known as array shapes, turn on reportPossiblyNonexistentConstantArrayOffset.

public function doFoo(string $s): void
{
    $a = ['foo' => 1];
    echo $a[$s];
}

My personal preference is to only turn on the latter option, but your experience may vary.

Do you like PHPStan and use it every day? Consider sponsoring further development of PHPStan on GitHub Sponsors and also subscribe to PHPStan Pro! I’d really appreciate it!

The fact there are exactly two identifiers per rule class on average is a total coincidence. It made me re-check my algorithm that counts them. ↩︎

Enhancements in Handling Parameters Passed by Reference in PHPStan 1.10.60

2024-03-07T00:00:00Z

PHPStan 1.10.60 introduces enhancements in handling parameters passed by reference. These parameters, besides typical returned values, also serve as a form of output that a called function can produce:

function foo(&$p): void
{
	$p = true;
}

$v = false;
foo($v);
var_dump($v); // bool(true)

You might be surprised to learn that you can set a type for a parameter passed by reference, but it doesn’t limit the output type:

function foo(string &$p): void
{
	$p = 1;
}

$v = 'foo';
foo($v);
var_dump($v); // int(1)

Previously, PHPStan’s type inference discarded the type of a variable passed into such a parameter:

function foo(string &$p): void
{
	$p = 1;
}

$v = 'foo';
foo($v);
\PHPStan\dumpType($v); // mixed

When analysing code that calls a function, PHPStan relies on function’s signature and PHPDoc to understand what’s going to happen. It does not dive into the function implementation because it’d hurt the performance of the analyser. So changing the type of the variable to mixed was a sensible solution - we didn’t know what’s going on inside the function so we could not assume anything.

In the latest release, this behavior has changed.

All of the following changes are part of Bleeding Edge because we intend to keep our generous backward compatibility promise. You can get them in PHPStan 1.10.60 today if you include the Bleeding Edge config. Everybody else will get them as part of the next major release, PHPStan 2.0.

Checking the Type of Argument Passed into a Parameter by Reference #

The recent pull request by Lincoln Maskey initiated the development of these enhancements.

Previously, PHPStan skipped type checking for all parameters passed by reference. Consequently, code like the following did not trigger any warnings:

function foo(string &$p): void
{
	// ...
}

$v = 1;
foo($v);

This was because some internal built-in PHP functions have parameters passed by reference in their signature, but the type enforcement didn’t match that of userland functions.

However, PHPStan is now equipped to check the type in such cases, ensuring more comprehensive type validation moving forward.

Assumption of Output Type #

Instead of setting the type of the passed variable to mixed, we now assume that the user does not intend to change the type entirely:

function foo(string &$p): void
{
	// ...
}

$v = 'foo';
foo($v);
\PHPStan\dumpType($v); // string

However, this creates a problem: what if we do want to change the type? You can still achieve this using @param-out PHPDoc tag:

/**
 * @param-out int $p
 */
function foo(string &$p): void
{
	$p = 1;
}

$v = 'foo';
foo($v);
\PHPStan\dumpType($v); // int

Enforcing Assigned Type #

Psst, I’ll let you in on a little secret. Not all extra PHPDoc features static analysers offer are actually enforced by their rules. @param-out was one example. You could have assigned anything to the variable and PHPStan would not complain.

That changes today. These assignments are now checked by new set of rules:

function foo(string &$p): void
{
	// Parameter &$p by-ref type of function foo() expects string, int given.
	// Tip: You can change the parameter out type with @param-out PHPDoc tag.
	$p = 1;
}

Yes, PHPStan will even contextually hint to you that you can write a @param-out PHPDoc tag if the assignment to an integer is intentional. These tips can be seen next to a 💡 in the CLI output, and also as a small grey text on the on-line playground.

If @param-out is already involved, the message is a little bit different:

/**
 * @param-out string $p
 */
function foo(string &$p): void
{
	// Parameter &$p @param-out type of function foo() expects string, int given.
	$p = 1;
}

And if the type of @param-out is different to the input type, but we don’t reassign the variable, PHPStan is also able to notice it:

/**
 * @param-out int $p
 */
function foo(string &$p): void // Parameter &$p @param-out type of function foo() expects int, string given.
{

}

Detecting Overly Broad `@param-out` Type #

Similar to how PHPStan handles return types, it now detects when a union type in the output parameter type includes unused parts:

function foo(?string &$p): void
{
	// Function foo() never assigns null to &$p so it can be removed from the by-ref type.
	// Tip: You can narrow the parameter out type with @param-out PHPDoc tag.
	$p = 'foo';
}

If your function accepts null but the variable never leaves the function as null anymore, you should inform the caller with the @param-out tag as well:

/**
 * @param-out string $p
 */
function foo(?string &$p): void
{
	// No errors
	$p = 'foo';
}

Do you like PHPStan and use it every day? Consider supporting further development of PHPStan. I’d really appreciate it!

A guide to call-site generic variance

2023-09-19T00:00:00Z

PHPStan has supported what is called declaration-site variance for a long time. An example you might be familiar with is the infamous @template-covariant. And although not as often useful, it also has a contravariant counterpart.

To freshen your memory: you can mark a template type as covariant:

/** @template-covariant ItemType */
interface Collection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;

	/** @return ItemType|null */
	public function get(int $index): mixed;
}

This allows you to pass Collection<Cat> into functions where Collection<Animal> is expected. But it comes at a cost:

/** @param Collection<Animal> $animals */
function foo(Collection $animals): void
{
	$animals->add(new Dog());
}

By itself, this is a perfectly valid code. But with Collection being covariant over its template type, we can now mix cats with dogs. That’s why PHPStan prevents us from using the ItemType in Collection::add() method’s parameter:

Template type ItemType is declared as covariant, but occurs in contravariant position in parameter item of method Collection::add().

That’s the trade-off: if you want the Collection to be covariant, it can only have the get method. If you want it to have the add method too, it has to be invariant in its ItemType.

Until now, there has not been an easy way around this. You could split the interface into a read-only one that can safely be covariant, and an invariant one:

/** @template-covariant ItemType */
interface ReadonlyCollection
{
	/** @return ItemType|null */
	public function get(int $index): mixed;
}

/**
 * @template ItemType
 * @extends ReadonlyCollection<ItemType>
 */
interface Collection extends ReadonlyCollection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;
}

But that is a lot of work and can quickly get tedious. Call-site variance is a way of having PHPStan do this work for you.

Call-site variance #

As the name suggests, call-site variance (or type projections, if you prefer fancier words) moves the variance annotation from the declaration to the call site. This means that the declaration of the interface can remain invariant, and therefore contain both get and add methods:

/** @template ItemType */
interface Collection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;

	/** @return ItemType|null */
	public function get(int $index): mixed;
}

If you need a specific function to accept Collection<Cat> in place of Collection<Animal>, you can instruct it so by attaching the covariant keyword to the generic type argument:

/** @param Collection<covariant Animal> $animals */
function foo(Collection $animals): void
{
	$animals->add(new Dog());
}

Correspondingly, the error has moved from the declaration to the call-site: if the implementation does something that would break type safety, like adding a Dog into the collection above, PHPStan will tell us:

Parameter #1 $item of method Collection<covariant Animal>::add() expects never, Dog given.

Call-site contravariance #

Although not as useful, it’s worth mentioning that you can also use contravariant type projections. For example, if we wanted a happy little function that fills a collection with dogs, we could make it so that it accepts not only Collection<Dog>, but also Collection<Animal>, or even Collection<mixed>:

/** @param Collection<contravariant Dog> $collection */
function fill(Collection $collection)
{
	while (true) {
		$collection->add(new Dog);
	}
}

This too has a limitation, but at least this time it’s not so drastic: if we wanted to get a value from the collection, we can:

/** @param Collection<contravariant Dog> $collection */
function fill(Collection $collection)
{
	while ($collection->get(42) === null) {
		$collection->add(new Dog);
	}
}

But because a contravariant type is not bounded from the top, we cannot make any assumption about the type of the retrieved item, and neither can PHPStan, therefore the type of $collection->get(42) would be mixed.

Star projections #

Sometimes, you just don’t care about the type of the values you’re working with. Let’s add a count() method to the Collection:

/** @template ItemType */
interface Collection
{
	/** @param ItemType $item */
	public function add(mixed $item): void;

	/** @return ItemType|null */
	public function get(int $index): mixed;

	public function count(): int;
}

This method doesn’t reference the ItemType template type at all. We are using it in a function printSize that prints the size of a collection. In this case, the function can accept a collection of anything. Inspired by other languages such as Kotlin, PHPStan provides an idiomatic way of writing this, using an asterisk:

/** @param Collection<*> $collection */
function printSize(Collection $collection): int
{
	echo $collection->count();
}

Obviously, we cannot make any assumptions about the collection’s item type whatsoever. In other words, star projections combine the limitations of covariant and contravariant projections. If we were to add() anything into the collection inside this printSize function, we would get a similar error as above:

Parameter #1 $item of method Collection<*>::add() expects never, Dog given.

And if we wanted to get a value from the collection, it would be mixed:

/** @param Collection<*> $collection */
function printSize(Collection $collection): int
{
	$item = $collection->get(0);
	// $item is mixed
}

Using RuleErrorBuilder to enrich reported errors in custom rules

2023-07-12T00:00:00Z

When writing custom rules for PHPStan, developers can either return plain strings or RuleError instances.

/**
 * @phpstan-param TNodeType $node
 * @return (string|RuleError)[] errors
 */
public function processNode(Node $node, Scope $scope): array;

The latter is a way to attach additional information to the reported errors.

RuleError is just an interface. The way you create an instance is through RuleErrorBuilder:

return [
	RuleErrorBuilder::message('This is an error message.')
		->build(),
];

Besides setting an error message RuleErrorBuilder offers the following capabilities:

->line(int $line): Set a different file line. Useful when you want to report a different line than the node which the rule was called for
->file(string $file): Set a different file path. Useful for collector rules.
->tip(string $tip): Shows an additional text next to a 💡 emoji on the command line. You can tell the user why the error is reported or how to solve it.
->nonIgnorable(): Makes the error non-ignorable by any means.
->metadata(array<mixed> $metadata): Attach additional metadata to the error that can later be read in the error formatter.
->identifier(string $identifier): Sets an error identifier. More about this below.

Error identifiers #

The flagship feature of the upcoming PHPStan 1.11 release are error identifiers. You will be able to use them to ignore specific errors:

function () {
	// @phpstan-ignore argument.type
	$this->foo->doSomethingWithString(1);

	$this->foo->doSomethingWithString(2); // @phpstan-ignore argument.type
};

There’s a generated catalogue of all the identifiers in PHPStan itself and 1^st party extensions. Each identifier links to source code where it’s reported so this serves as a great educational resource about PHPStan internals.

To ensure great experience for all users, custom rules will also be required to provide their own identifiers. At first it will only be soft-enforced in Bleeding Edge, and in PHPStan 2.0 it will be hard-enforced with a native return type.

This means that the ability to return plain strings from custom rules will eventually go away. I recommend you to switch to RuleErrorBuilder sooner rather than later.

PHPStan 1.11 with Bleeding Edge enabled will require custom rules to return errors with identifiers. As a first step, remove any PHPDoc above your processNode method. If your rule does not yet have @implements Rule<...> generic PHPDoc tag, add it:

+/**
+ * @implements Rule<StaticCall>
+ */
 class MyRule implements Rule
 {
 	public function getNodeType(): string
 	{
 		return StaticCall::class;
 	}

-	/**
-	 * @param StaticCall $node
-	 * @param Scope $scope
-	 * @return string[]
-	 */
 	public function processNode(Node $node, Scope $scope): array
 	{
 		// ...
 	}

Even without the PHPDoc both PHPStan and PhpStorm will understand that the parameter $node coming into the processNode method is a StaticCall.

After that migrate the plain strings to RuleErrorBuilder, and add error identifiers for each of them:

 	public function processNode(Node $node, Scope $scope): array
 	{
 		return [
-			'This is an error message.',
+			RuleErrorBuilder::message('This is an error message.')
+				->identifier('some.problem')
+				->build(),
 		];
 	}

For an inspiration how the identifiers should look like check out the catalogue.

The identifier must consist of lowercase and uppercase ASCII letters, and optionally can have one or more dots in the middle. See the tests for examples of valid and invalid identifiers.

PHPStan 1.11 will be released at some time in the coming months. Don’t worry, your old rules will not break with that release, but it would be great to modernize them to take advantage (and let your users take advantage) of the latest PHPStan features. Thanks!

Solving PHPStan error "Access to an undefined property"

2023-03-31T00:00:00Z

“Access to an undefined property Foo::$x” is one of the most common errors you will encounter when running PHPStan. Here are all the ways you can solve it.

Fix the name #

The easiest situation you can find yourself in is that there’s a typo in the source code, and the property access needs to be corrected to the right name:

 	public function getName(): string
 	{
-		return $this->nama;
+		return $this->name;
 	}

Narrow the type the property is accessed on #

If you encounter errors like:

Access to an undefined property object::$a. Cannot access property $a on mixed.

The problem isn’t the name of the property but the type we’re accessing the property on:

// $object is object
echo $object->a;

We can’t be sure the property exists on this type because it can be an object of any class. The solution is to narrow the type first and only then access the property.

Declare the property #

In older versions of PHP you weren’t required to declare the property, and the code might have actually run fine. But for obvious type safety reasons it’s better to declare the property if it’s missing:

 class HelloWorld
 {

+	private string $name;
+
 	public function setName(string $name): void
 	{
 		$this->name = $name;

PHP 8.2: Add `#[AllowDynamicProperties]` #

If the class is meant to have dynamic properties (when they vary from object to object), it needs to meet one of the following conditions:

Have __get and/or __set magic methods for handling dynamic properties
Be stdClass or extend stdClass
Have #[AllowDynamicProperties] class attribute

This is because dynamic properties have been deprecated in PHP 8.2+.

Addressing these requirements will not make the PHPStan error go away, but it will allow the following solutions to work if you use PHP 8.2 or later.

Universal object crates #

Classes without predefined structure are common in PHP applications. They are used as universal holders of data - any property can be set and read on them. Notable examples include stdClass, SimpleXMLElement (these are enabled by default), objects with results of database queries etc. Use universalObjectCratesClasses key to let PHPStan know which classes with these characteristics are used in your codebase by setting them in your configuration file:

parameters:
	universalObjectCratesClasses:
		- Dibi\Row
		- Ratchet\ConnectionInterface

See also object shape PHPDoc type for a better alternative that lets you describe types of properties of such objects.

Add `@property` PHPDoc #

If the class features magic properties but these properties are always the same, you can declare them with @property PHPDocs:

/**
 * @property int $foo
 * @property-read string $bar
 * @property-write \stdClass $baz
 */
class Foo { ... }

Making `@property` PHPDoc above interfaces work on PHP 8.2+ #

Available in PHPStan 1.10.56

You might find that the following code is not sufficient to declare a property on an interface when you analyse code in PHP 8.2 and newer:

/**
 * @property string $bar
 */
interface Foo
{
}

function (Foo $foo): void {
    // Error: Access to an undefined property Foo::$bar.
    echo $foo->bar;
};

That’s because PHP 8.2 requires extra steps to allow dynamic properties. And there’s actually no way in the language to make these extra steps work on interfaces.

Fortunately there’s a PHPDoc feature that helps you get rid of this error. It’s @phpstan-require-extends. Class implementing an interface that uses this PHPDoc tag is required to extend a parent referenced in this tag. If this parent class allows dynamic properties, it makes this error go away. Additionally, it makes all properties and methods from this parent class also available when working with the interface.

/**
 * @property string $bar
 * @phpstan-require-extends Model
 */
interface Foo
{
}

class Model
{
    public function __get(string $name): mixed
    {
        // some magic logic for dynamic properties
    }
}

function (Foo $foo): void {
    // OK - No error
    echo $foo->bar;
};

Learn more about @phpstan-require-extends and @phpstan-require-implements »

Mixin #

When a class delegates unknown method calls and property accesses to a different class using __call and __get/__set, we can describe the relationship using @mixin PHPDoc tag:

class A
{
	public string $name = 'Class A';
}

/**
 * @mixin A
 */
class B
{
	public function __get(string $name): mixed
	{
		return (new A())->$name;
	}
}

$b = new B();
echo $b->name; // No error

Extensions for popular frameworks #

If you use a popular framework like Laravel, where model properties are often not declared on class, you can use framework-specific extensions to make PHPStan understand your code properly.

Check out the extension library and search for PHPStan extensions on Packagist.

Write your own extension #

You can write your own class reflection extension to let PHPStan know which properties exist on your classes.

This solution works best if there’s custom logic in your __get() and __set() magic methods. For example if you can say “Property $name on class Foo exists if there’s a getter called getName()”, writing a custom class reflection extension to describe this lets you solve this PHPStan error in a nice and easy way.

Do you like PHPStan and use it every day? Consider supporting further development of PHPStan on GitHub Sponsors. I’d really appreciate it!

Website Improvement: Social Post Preview Image

2023-03-13T00:00:00Z

PHPStan’s website is statically generated thanks to this stack:

Eleventy - think Jekyll, but for the modern JavaScript age
Parcel - my favourite bundler ^[1]

There’s also plenty of other cool technologies like TailwindCSS, Markdown, Mermaid, and Prism.

Being statically generated means I can host it on S3 & Cloudfront CDN and serve 120k+ views a month for literally pennies. But it makes implementing some features… not straightforward.

One day I noticed that Tomáš Votruba has nice custom previews for his articles when he shares them on Twitter.

Want to ensure your codebase is rock-solid? 💪

Measure your type coverage and improve your code's reliability! 🚀 https://t.co/d3ZU1bXyek
— Tomas Votruba (@VotrubaT) March 12, 2023

And I wanted the same thing! I checked out some Eleventy plugins, but didn’t fall in love with any of them. I wanted to define how the image will look in HTML & TailwindCSS, screenshot it in a headless browser, and save the image to be uploaded alongside other regular website images.

So I’ve spent a few hours figuring it out, and designing the image. I love the result, both the code that achieved that, and the look. See for yourself:

A short tale about how @VotrubaT's tweet inspired me to improve PHPStan's statically generated website.https://t.co/ivmHJeGCze
— Ondřej Mirtes (@OndrejMirtes) March 13, 2023

Do you like PHPStan and use it every day? Consider supporting further development of PHPStan on GitHub Sponsors. I’d really appreciate it!

It might as well mean “I can’t configure Webpack and I’m not ashamed!” ↩︎

PHPStan 1.10 Comes With a Lie Detector

2023-02-21T00:00:00Z

I’ve been looking forward to implementing and releasing the ideas present in PHPStan 1.10 for a long time.

Validate inline PHPDoc `@var` tag type #

My personal mission after PHPStan 1.0 is to eradicate inline @var tags from existence. Developers reach for it as an immediate remedy for their problems but it's the worst solution ever.

With @var tags you're giving up all the type safety static analysis offers. pic.twitter.com/WvRvFooce4
— Ondřej Mirtes (@OndrejMirtes) November 9, 2021

There are multiple problems with inline @var PHPDoc tag. PHP developers use it for two main reasons:

To fix wrong 3rd party PHPDocs. A dependency ^[1] might have @return string in a PHPDoc but in reality can return null as well.
To narrow down the returned type. When a function returns string but we know that in this case it can only return non-empty-string.

By looking at the analysed code we can’t really tell which scenario it is. That’s why PHPStan always trusted the type in @var and didn’t report any possible mistakes. Obviously that’s dangerous because the type in @var can get out of sync and be wrong really easily. But I came up with an idea what we could report without any false positives, keeping existing use-cases in mind.

With the latest release and bleeding edge enabled, PHPStan validates the inline @var tag type against the native type of the assigned expression. It finds the lies spread around in @var tags:

function doFoo(): string
{
    // ...
}

/** @var string|null $a */
$a = doFoo();

// PHPDoc tag @var with type string|null is not subtype of native type string.

It doesn’t make sense to allow string|null, because the type can never be null. PHPStan says “string|null is not subtype of native type string”, implying that only subtypes are allowed. Subtype is the same type or narrower, meaning that string or non-empty-string would be okay.

By default PHPStan isn’t going to report anything about the following code:

/** @return string */
function doFoo()
{
    // ...
}

/** @var string|null $a */
$a = doFoo();

Because the @return PHPDoc might be wrong and that’s what the @var tag might be trying to fix. If you want this scenario to be reported too, enable reportWrongPhpDocTypeInVarTag, or install phpstan-strict-rules.

I’d like the PHP community to use inline @var tags less and less over time. There are many great alternatives that promote good practices and code deduplication: Conditional return types, @phpstan-assert, generics, stub files for overriding 3rd party PHPDocs, or dynamic return type extensions.

Encourage handling of all enum cases #

What’s wrong with the following example?

enum Foo
{
	case ONE;
	case TWO;

	public function getLabel(): string
	{
		return match ($this) {
			self::ONE => 'One',
			self::TWO => 'Two',
			default => throw new \Exception('Unexpected case'),
		};
	}
}

PHPStan 1.9 didn’t complain about anything in that code. But it has problems:

The default arm isn’t really needed.
When we add case THREE in the enum, PHPStan will not tell us about an unhandled case, but in runtime the application will throw exceptions in our face.

PHPStan 1.10 reports “Match arm is unreachable because previous comparison is always true.” for the line with the default case. It encourages removing the default case, which solves both problems at once.

When we add case THREE, PHPStan will now report: “Match expression does not handle remaining value: Foo::THREE”. Which would not happen if the default case was still there.

Changes to “always true” expressions and unreachable code #

There’s a few more related changes spawned from the previous section. For a long time PHPStan reported inconsistently “always true” and “always false” conditions. But there was some logic to it. I didn’t want you to have dead code.

function doFoo(\Exception $o): void
{
	// not reported
	if ($o instanceof \Exception) {
		// code inside always executed
	}
}

If there was an else branch involved, PHPStan would report:

function doFoo(\Exception $o): void {
	if ($o instanceof \Exception) {
	} else {
		// dead code here
		// reports:
		// Else branch is unreachable because previous condition is always true.
	}
}

You could turn on a few specific options, or install phpstan-strict-rules, to also have the instanceof reported as “always true”.

I chose this way because I didn’t want to discourage writing “safe” code like this, because some developers prefer it:

// $foo is One|Two
if ($foo instanceof One) {

} elseif ($foo instanceof Two) {
    // PHPStan reports "instanceof always true", wants you to write "else {" instead
}

Very similar to the match example above, right? I also noticed and realized that people expect PHPStan to report “always true” out of the box more often than not, except for these examples.

With bleeding edge enabled and for everyone in the next major version, PHPStan will report “always true” by default, no extra options needed. To support the “last elseif” use-case, “always true” will not be reported for the last elseif condition and for the last arm in a match expression. You can override that with reportAlwaysTrueInLastCondition.

We no longer need unreachable branches reported at all - we’ll find out about them thanks to “always true” errors from previous branches. These rules are now completely disabled in bleeding edge.

Thanks to these changes, the error reported for the enum with the default case are different with and without bleeding edge on PHPStan 1.10:

enum Foo
{
	case ONE;
	case TWO;

	public function getLabel(): string
	{
		return match ($this) {
			self::ONE => 'One',
			self::TWO => 'Two',
			default => throw new \Exception('Unexpected case'),
		};
	}
}

-13     Match arm is unreachable because previous comparison is always true.
+12     Match arm comparison between $this(aaa\Foo)&aaa\Foo::TWO and aaa\Foo::TWO is always true.
+       💡 Remove remaining cases below this one and this error will disappear too.

PHPStan tries to be helpful and shows a tip next to the 💡 emoji on the command line. These tips are now incorporated into the playground as well. If you remove the default case, PHPStan will no longer complain about this piece of code. Until you add a new enum case.

Why my type isn’t accepted here? #

It’s not always obvious what is PHPStan complaining about. Type safety is of the most importance, it really doesn’t want to leave any gap for possible runtime errors. The developer might not know what situation it’s trying to avoid with certain checks, and might not know why they should fix it and how.

PHPStan 1.10 includes helpful contextual tips in these less intuitive scenarios. My favourites are:

Deprecation of `instanceof *Type` #

PHPStan 1.10 also comes with deprecations of less-than-ideal code patterns in custom rules and other extensions. I’ve written a separate article about those two weeks ago: Why Is instanceof *Type Wrong and Getting Deprecated?

Do you like PHPStan and use it every day? Consider supporting further development of PHPStan on GitHub Sponsors. I’d really appreciate it!

That probably doesn’t use static analysis. ↩︎

PHPStan Blog

PHPStan 1.12: Road to PHPStan 2.0

General availability of precise type inference for regular expressions #

Fix blind spots in PHPDoc tags type checks #

Too wide private property type #

PHP 8.4 runtime support #

PHPStan Reports Different Errors Locally & in CI. What Should I Do?

Is it analysing the same code? #

Is it running the same PHP version? #

Require PHPStan in your Composer project #

Make sure your composer.lock is committed in the Git repository #

Run composer install, not composer update #

Run PHPStan’s diagnose command to compare the environments #

Check the config file path #

Get rid of duplicate symbols #

Fix your custom non-deterministic autoloader #

Open a discussion on PHPStan’s GitHub #

Debugging PHPStan Performance: Identify Slow Files

PHPStan 1.11 With Error Identifiers, PHPStan Pro Reboot and Much More

Error Identifiers #

PHPStan Pro Wizard #

PHPStan Pro UI Revamp #

Is this function really pure? #

When is a passed callable called? #

What is a passed closure bound to? #

New options for possibly nonexistent offsets in arrays #

Enhancements in Handling Parameters Passed by Reference in PHPStan 1.10.60

Checking the Type of Argument Passed into a Parameter by Reference #

Assumption of Output Type #

Enforcing Assigned Type #

Detecting Overly Broad @param-out Type #

A guide to call-site generic variance

Call-site variance #

Call-site contravariance #

Star projections #

Using RuleErrorBuilder to enrich reported errors in custom rules

Error identifiers #

Solving PHPStan error "Access to an undefined property"

Fix the name #

Narrow the type the property is accessed on #

Declare the property #

PHP 8.2: Add #[AllowDynamicProperties] #

Universal object crates #

Add @property PHPDoc #

Making @property PHPDoc above interfaces work on PHP 8.2+ #

Mixin #

Extensions for popular frameworks #

Write your own extension #

Website Improvement: Social Post Preview Image

PHPStan 1.10 Comes With a Lie Detector

Validate inline PHPDoc @var tag type #

Encourage handling of all enum cases #

Changes to “always true” expressions and unreachable code #

Why my type isn’t accepted here? #

Deprecation of instanceof *Type #

Make sure your `composer.lock` is committed in the Git repository #

Run `composer install`, not `composer update` #

Run PHPStan’s `diagnose` command to compare the environments #

Detecting Overly Broad `@param-out` Type #

PHP 8.2: Add `#[AllowDynamicProperties]` #

Add `@property` PHPDoc #

Making `@property` PHPDoc above interfaces work on PHP 8.2+ #

Validate inline PHPDoc `@var` tag type #

Deprecation of `instanceof *Type` #