Next up, let's integrate StyleCI into the project. This is very cool. It can inspect any pull request, any code coming in, for formatting inconsistencies. So maybe I want to adopt PSR2, but a PR comes in that does not conform to that at all. Well, this tool can automatically detect that, and even fix those inconsistencies automatically. Alright, so let's set it up. And by the way, for any open source project, this service is free. So I will authorize it. Alright, so let's go to my account, repos, where is console? There it is.

Alright, so let's go to my account, repos, where is console? There it is. We will enable StyleCI. Alright, show analyses. Now if we take a look at the settings, it looks like we can configure it right here, but we also have a pull request that will set it up, let me take a look, as a .styleci.yaml file within the project. So it seems we can do either or. As we see here, there are two ways to configure your repo. You can commit a .styleci.yaml, and you'll see that this is exactly what has been submitted.

As we see here, there are two ways to configure your repo. You can commit a .styleci.yaml, and you'll see that this is exactly what has been submitted. Or by visiting the settings page for your repo. And I think actually I'd prefer to do it there. It's one less file in our project. Now let's configure a preset, and we should have some out of the box. So we could use PSR2 if we want. I think there's even a Laravel specific one, because Laravel mostly follows PSR2 with just a handful of differences. But in our case, I think PSR2 is probably going to be fine.

a handful of differences. But in our case, I think PSR2 is probably going to be fine. So you'll see if we go to configuration, it's very easy. We can just say preset, PSR2. And do note, in certain situations, you will want to exclude certain directories. So for example, my phpunit tests do not conform to PSR2. I don't think it's necessary. I think it's more readable to use a different style there. So we can exclude it if we need to. Anyways, we'll take a look at that when we need to.

So let's take a look at the details. And we can see any of the issues here along with the fixes. 54 files have changed. Often it's little things like, in this case, it looks like quotes. Now in this case, yeah, remember, you can configure anything you need to. So in this case, it will automatically add a comma to the last item of an array. If you don't want that, you can configure it. Here we're removing a space. This is just a typo there to use bool instead. You get the idea, right?

Settings and now disabled is that one. But now while we're here, let's also exclude our tests. So we can see in the configuration, we can say finder, exclude, and this is a very common example, so we can grab that. And let's use spaces. Okay, so now we're saying exclude the tests directory in any file that ends in .php. All right, so let's save our configuration, head on back, and I'm going to force another analysis. Okay, that's done. So the previous one, we can see there were 54 changed files.

Okay, that's done. So the previous one, we can see there were 54 changed files. But if we head back, this one should be less, 19, because once again, it's not adding things like trailing commas. So if we quickly scan this, some comma changes. But this is useful. Now if we scroll to the top, you can see create a fix PR. And remember, you can do this manually or you can automate the process. But anyways, let's go ahead and run that. Done.

So let's go ahead and squash and merge. And there we go. We're all set. So finally, if you quickly want to see how this works with a PR, why don't we quickly prepare one. So let me pull in any changes, okay. And then, once again, I'm going to make a PR that I will ultimately reset and force push. It's only for the screencast. But yeah, maybe they make a change like this, name equals someVar.

It's only for the screencast. But yeah, maybe they make a change like this, name equals some var. You get the idea. This is going to represent some kind of feature, some kind of PR. However, they didn't follow our formatting the way we wanted. Okay. So we will get status. Now we can do this as a commit or as an incoming PR. Why don't we first do it as a commit. And we will push it up.

Why don't we first do it as a commit. And we will push it up. All right. So now, let's give this a refresh. We can take a look at the commit, and you'll see right there, the style CI analysis has failed. One file needs addressing. So if we click through, and we can create a fix PR. And remember, we can automate this entire thing so that you don't have to manually do it.

And remember, we can automate this entire thing so that you don't have to manually do it. You'll just enable that from your settings area, which is what I would recommend. But anyways, if we come back, view the changed files, it's going to fix the issue. So let's do this. I'm going to do a git log, git reset --hard. So I'm just getting rid of that commit entirely. So we'll push it back up and do a git push --force to reflect that change. So finally, we're going to come back to our settings here, scroll all the way down, and we will adjust the automation level.

So finally, we're going to come back to our settings here, scroll all the way down, and we will adjust the automation level. Why don't we start with this one, automatically send fixes as pull requests only. All right. So now, let's simulate a PR. So I'm going to check out a branch called example. And we will make some kind of change that simulates a feature once again, $who equals bar. Yeah, that's some feature that does not conform to our style guide, which is PSR 2. So I'm going to do a git status, add that commit with some feature for video.

Yeah, that's some feature that does not conform to our style guide, which is PSR 2. So I'm going to do a git status, git add, git commit with some feature for video. Just to be clear. Otherwise, if somebody's looking at this commit coming in in real time, they're like, what the hell are you doing, Jeff? Anyways, we'll git push to origin to GitHub our example branch. All right. So now if we come back to our repo and give this a refresh, we should see our example branch, and we do. Let's go ahead and make a pull request.

It has failed. So if we scroll back, we should now have an additional pull request that will fix those changes. So if we take a look here, this was an automated PR that repairs that. All right. Does that make sense? So that would be the second option, or we can automatically send and then squash a fix down as a pull request. So it's just a matter of what you want here. But anyways, this was just an example.