If you remember back to my first video, I was able to switch between tests and implementations really quickly as long as they followed a predictable structure. This was using a plugin called Projectionist, which has a concept of alternate files. It also has a few other neat tricks, so let's dive in. Once again, we'll jump back into our plugins.lua file, and we'll come down to after our last plugin and paste in a project definition for Projectionist. This one optionally requires another plugin called vimdispatch, which will help us with a feature I'll show you shortly. And then I've gone ahead and set up a custom module for the configuration. So let's go and create that one in nvim lua user plugins projectionist.lua.

And then I've gone ahead and set up a custom module for the configuration. So let's go and create that one in nvim lua user plugins projectionist.lua. I'll paste in my personal configuration for this, and then let's walk through it. So Projectionist has this concept of heuristics, and this is how it will know what settings to apply to what project. So in this case, the heuristic is artisan. As long as there's a file in the root of the project called artisan, then it knows that we're dealing with a Laravel project, and everything inside this object will apply. The first two options here apply to any file we're inside, and it sets up a start and a console command.

The first two options here apply to any file we're inside, and it sets up a start and a console command. So the start command would access using colon start, and that will automatically run php artisan serve for us, and with vim dispatch it'll automatically open that in a new tmux tab for us. The console option we've bound to open up php artisan tinker, but if we come down we get to the more interesting stuff. So here I'm specifying that for any files inside the app directory that end in .php, that these are of the type source, so this is the source code. I've then specified what the alternate paths for this file are. So in this case I've said that there are two alternate paths, and one is tests/unit, and

I've then specified what the alternate paths for this file are. So in this case I've said that there are two alternate paths, and one is tests/unit, and then these little squirrely braces here are a wildcard, so whatever was in our asterisk in up here will come down and be in here. So if we have app/models/user.php, then this would be tests/unit/models/UserTest.php. And then I have another one for feature tests as well. I'm then defining the inverse down here. So for any tests in our feature directory, I'm marking them as the type test, and their alternate file is in the app directory.

So for any tests in our feature directory, I'm marking them as the type test, and their alternate file is in the app directory. I've done the same thing for the unit directory here as well. I'm then also specifying some additional types here. So for any php files in the model directory, I'm calling them a model, and similar for controllers, routes, and migrations. And you'll see what this unlocks shortly. So let's go ahead and save both of these files using :w, and we'll run packasync to install Projectionist. Now let's jump over to our Laravel project, and we'll open up NeoVim.

install Projectionist. Now let's jump over to our Laravel project, and we'll open up NeoVim. Let's try browsing to our UserController. And inside here, if I type in :shift a, it'll ask to create an alternate file. And you'll see that the paths here mirror the application structure. So inside either the Unit or Feature directory, it'll create a HTTP\Controllers\UserControllerTest. You can get creative with the wildcards in the Projectionist configuration, but this is the way I like to set up my tests. So in this case, I want a feature test, so I'll press 2, and that will open up our UserController.

is the way I like to set up my tests. So in this case, I want a feature test, so I'll press 2, and that will open up our UserControllerTest. We can, of course, use our artisan mapping to open our Factory class new method and select a Laravel test. And then that will go ahead and fill that out for us. In this file, I can type :A, and it'll jump straight back to the UserController. Since I'm in the UserController, if I press :A, it'll just jump straight over to the test. It won't ask to create it again.

over to the test. It won't ask to create it again. Now we also define some files with different types, like model, controller, route, and so on. If I type a colon and then capital E, and then I said, say, migration, and I can tap complete this, I can then also tab complete the next parameter, which will select all of the migration files in the migration directory. So I could jump straight to the user migration. Similarly, I could say E controller, and then I've got options for all of the controllers here.

Similarly, I could say Eloquent controller, and then I've got options for all of the controllers here. I could also say Eloquent controller and say something controller, and it'll go ahead and create that file for me in the right place. But typically, I use artisan make commands instead. Now the other two commands we set up were the start and console commands. So if I type :start, then I configure this to start php artisan serve, and if I come back to vim and I type in :console, you'll see this opens up a php artisan tinker session straight away for me. If we jump back to our .files repository and come back to our projectionist file, one thing

away for me. If we jump back to our .files repository and come back to our projectionist file, one thing to note here is that these are all the defaults that I've set up. But in any project, I can create a .projections.json file in the root of the project and contain everything inside this object in here in a JSON format rather than Lua, and that will override anything I've set here. So if you want to use php artisan serve by default, but maybe in another project you're using SAIL, you could customize it just for that project. And if you don't want to commit that file to source control, then you can always add it to your global .gitignore.