All right, let's go ahead and discuss all the options that phpStan provides for ignoring a set of errors. I'm going to remove this line here, and now when we run vendor/bin/phpstan again, well, I would expect that we'd get the same six errors as before, and sure enough, we do. Now, the first thing you can do to ignore an error is ignore the entire line. So, if I go down to somewhere where I'm accessing a property, like name, here's one, I can say, at phpStan, in a comment, ignore line, like so. So, phpstan-ignore-line. And when we run vendor/bin/phpstan again, you'll note that we now only have five errors. It's ignored line number 28. If I don't want to place the comment on the same line, I can ignore the next line. So, above the line I want to ignore, I can say, at phpStan, ignore next line, like so. And again, if we run vendor/bin/phpstan, we should see that that error has once more been ignored.

So, above the line I want to ignore, I can say, at phpStan, ignore next line, like so. And again, if we run vendor/bin/phpstan, we should see that that error has once more been ignored. This is great for one-off errors, but it doesn't really make sense for our use case. Let's think about it for a second. Taking a look at the error messages, you can see that they're all basically the same kind of thing. Cannot access property something on user or null. That is going to happen across all of our controllers whenever we access the user via the request. It would make much more sense to just ignore this type of error inside our code base. And you can do that from the phpstan.neon configuration file. In our phpstan.neon file, under parameters, we need to add a new key called ignoreErrors.

And you can do that from the phpStan.neon configuration file. In our phpStan.neon file, under parameters, we need to add a new key called ignoreErrors. And this is actually an array of regex messages. Now, it can be difficult to understand how you should format that regex to make it valid, but phpStan actually has a great tool on their site for calculating the correct regex for any given message. So, I'll start by copying this message from the console output, cannot access property config of user or null. And then inside the tool that phpStan provides, and I'll make sure to put a link to this in the comments below, we can paste the error message. And you'll see here at the bottom it appears as a regex formatted error message.

we can paste the error message. And you'll see here at the bottom it appears as a regex formatted error message that we can now copy and put into our phpStan.neon file. I'll paste that in. And you can see it's taken care of making sure that this is the start of the string, this is the end of the string. It escaped any backward slashes so that they're correctly formatted. Hopefully, if we were in vendor/bin/phpStan again, yeah, now we only have three errors instead of the five that we had before. But why do we still have three errors?

yeah, now we only have three errors instead of the five that we had before. But why do we still have three errors? Well, once more, take a look at the regex that we added to our ignoreErrors array. Cannot access property config on User or null. Whereas in the console, well, this is cannot access property name on User or null. So, of course, we could go into the neon file and we could duplicate this line and we could change config for name. And sure enough, when we were in vendor/bin/phpstan again, now we have no errors. But having to change the variable name, the property name, each and every time we access a new property in a controller, it is terrible.

But having to change the $variable name, the property name, each and every time we access a new property in a controller, it is terrible. That's not a good idea. That's not sustainable. And you will get annoyed with phpStan and eventually likely stop using it. That is exactly why these are formatted using regex because we can make use of regex to capture multiple errors in one. So instead of adding each error as a separate line, why don't we just update the config here to instead check for any word character that is one or more characters in length after the $ sign. And hopefully now when we run vendor/bin/phpStan, we receive no errors.

that is one or more characters in length after the $ sign. And hopefully now when we run vendor/bin/phpstan, we receive no errors. We've captured all of those errors in this single ignore line. So you don't have to do this manually. You can let phpstan do the heavy lifting for you using the tool online. And then you can slightly tweak the regex to capture any edge cases that phpstan doesn't really know about. Of course, now with our configuration updated, we could remove phpstan ignore next line. We no longer need that comment there.

we could remove phpStan ignore next line. We no longer need that comment there. And if I wanted to, well, I could select all instances of User and I could replace those instances with the request User instead and remove this temporary variable up here. That's completely a stylistic choice, but the end result should be exactly the same. No errors inside the console. Now, of course, currently this will apply across our application. Anywhere where User or null is accessing the property, well, it will be ignored because of this particular line.

Anywhere where user or null is accessing the property, well, it will be ignored because of this particular line. But you likely don't want that. You probably want to limit this to a set of files. Perhaps in our case, we only want this to be ignored if it happens inside a controller where it's obvious we're going to be accessing the user via the request. So you can absolutely scope errors like this by specifying a path along with the message that you've added. So I'm going to drop this down onto its own line.

by specifying a path along with the message that you've added. So I'm going to drop this down onto its own line and I'm going to add a message key. And then underneath, I'll add a path key. And here I'll say I only want to search in the app/Http/Controllers directory. And I'll use a * here to check for any file within that directory. So if we run our code again, vendor/bin/phpstan, we still receive no errors in the code base. But if this error were to pop up outside of the controllers directory,

we still receive no errors in the code base. But if this error were to pop up outside of the controllers directory, in a service class where you're not accessing the User via the request object, then, yeah, phpstan would still complain about it. You'd see that there was an error, that there's likely a bug in your code, and you could go ahead and fix it. There's one more method for ignoring errors that I want to show you. And this is definitely the nuclear option, but it has some clear benefits. Let's take a look. I'm going to undo all of this work that we've just done,

Let's take a look. I'm going to undo all of this work that we've just done, and I'm going to run vendor/bin/phpstan again. And, of course, I'm expecting six errors. I'm now going to rerun vendor/bin/phpstan, but I'm going to tag on a flag called generate-baseline. And when I do so, well, you can see it tells us that the baseline has been generated with six errors. You can find this baseline file at the root of your project under phpstan-baseline, and you'll see that it's basically auto-generated the errors.

You can find this baseline file at the root of your project under php.stan-baseline, and you'll see that it's basically auto-generated the errors that were thrown in the last run of phpstan. Now, before we talk about why you'd want to use this, if I run vendor/bin/phpstan again, you'll see that we still get six errors. We have to tell phpstan that we want to use this baseline file. So if I jump back into the phpstan.neon file, at the top here in the includes array, I'm going to add phpstan-baseline.neon. And now, when we run once more, that baseline will be included, and we have no errors.

And now, when we run once more, that baseline will be included, and we have no errors. Now, let's talk about why you'd actually want this. Well, for one, you may come across situations where you have a bunch of new errors pop up, but you know there are no actual problems, in which case you could just baseline them for now until you have more time to come back and fix them at a later date. Here's the best example, though. You want to start using phpstan in an existing project, a large project. When you first install phpstan and run it, you might have thousands of errors,

You want to start using phpstan in an existing project, a large project. When you first install phpstan and run it, you might have thousands of errors, and nobody has the time to go and fix all of those errors in one chunk before they PR it. If you have multiple people working on a project, it can be almost impossible to keep up with things because people are merging in new code all the time, and you're just trying to get phpstan to zero errors. Instead, install phpstan, baseline all of the errors, and start from scratch. Use phpstan from that point forward. Of course, if you want to dedicate the time,

Use php.stan from that point forward. Of course, if you want to dedicate the time, then you can slowly work backwards and fix some of those baseline errors. Another use case for the baseline file is mentioned in the php.stan docs here. It allows you to upgrade to new versions of php.stan immediately, and this also extends to larastan. The reason that php.stan and larastan will receive upgrades is because they're now able to check for new issues in your code base. When you do upgrade, when you run php.stan, you'll see perhaps 10, 20 new errors that weren't there before.

When you do upgrade, when you run php stan, you'll see perhaps 10, 20 new errors that weren't there before, and it can be annoying if you want to just quickly update your composer.json file to have to fix a load of errors that you really don't have time for at the moment. Instead, you upgrade, you baseline, and you fix them as and when it's necessary. They weren't causing a problem before, so they're probably not going to be causing a problem now. So yes, the php stan baseline file is the nuclear option, but it's cleaner than having to write php stan ignore next line in 30 different places across a class.

but it's cleaner than having to write phpstan ignore next line in 30 different places across a class, and it's also a lot simpler than having to handcraft these error messages in your phpstan.neon configuration file. I have yet to have a project where I don't have a baseline file with at least a couple of errors, so it's a great option to know about. Now that we've discussed how to ignore errors in phpstan, why don't we move on to some of the more advanced features that phpstan has to offer.