All right, for this first video, we're going to get your app up and running from scratch in your local development environment. And while there is Laravel's Horizon to provide a lot of these dependencies for you, we're also going to make sure that you've got a free version of every single dependency you need to get started. So let's get going. All right, to get started, we want to make sure that we have either Valet or Horizon pointing to our site's directory for me, but some primary directory. We're going to use the Laravel installer, which you'll get for free if you have Horizon running, but if not, you can use the Laravel documentation, which will show you what it looks like to get the Laravel install working. We're going to run laravel new symposium to create our new project, and we're going to see this beautiful new interface provided by Laravel's prompts.

We're going to run laravel new symposium to create our new project, and we're going to see this beautiful new interface provided by Laravel's prompts. We get to choose first which starter kit we're going to use, and this new prompt-based system means we don't have to install Laravel and then install a whole bunch of dependencies afterwards. We actually get to choose which independencies we're going to install as we go. Jetstream is a lot more complicated than what we're going to need in this particular project, so I'm going to choose working with Breeze. There's all sorts of options for Breeze here. We can do Blade with Alpine.

There's all sorts of options for Breeze here. We can do Blade with Alpine. If you're a React review developer, you can get Inertia. There's also an API-only version, and of course, there's all the Livewire options. But because we're keeping it simple on this one, I'm going to stick with Blade and Alpine. I choose generally to stick with Blade with Alpine unless I really know I'm going to need Livewire, and I'm personally not a big single-page application guy, even though if I were, Inertia would be the way I would do it for sure. We're going to skip dark mode support in this particular one. If you're not familiar, PEST is the default testing framework that all Laravel apps use going forward.

We're going to skip dark mode support in this particular one. If you're not familiar, PEST is the default testing framework that all Laravel apps use going forward. If you want to use php in it, that's fine, but we're going to stick with PEST with this one because why not? So it's going to install our basic dependencies, and at some point here it's going to ask us about the database. And here we go. So SQLite is the new default database for Laravel apps, and once again, it's not MySQL, which we're always familiar with, but I would say it's the default. It doesn't require any dependencies. Let's get started with it and see how far it takes us. So we can watch it install. And there we go. We can cd into our new app, Symposium.

So we can watch it install. And there we go. We can cd into our new app, Symposium. And as you can see, it says cd Symposium php artisan serve, which is the fastest and easiest way to get up and running with Serving. But because we have either Valet or Horizon running, we can assume we're going to be able to visit Symposium.test in our browser. So before we do anything else, let's actually go to our browser and type that in to make sure it actually works. All right, you can see what a default Laravel app looks like in Laravel 11. Got to zoom out a little bit here. So this is what every stock Laravel app is going to look like in Laravel 11.

Got to zoom out a little bit here. So this is what every stock Laravel app is going to look like in Laravel 11. It's working. The first thing we're going to pull in is some dependencies that make sure that all of your code is consistent across all of your contributors and all different environments. And it's something I've started pulling in on all of my projects going forward right at the very beginning. So the first thing we're going to pull in is a project called Duster by Tighten. And what Duster is, is it brings a whole bunch of different linters and fixers together in one place. You've got Laravel's Pint, but you've also got TLint, PHP Code Sniffer, and PHP CS Fixer, which each add some things to our linting and fixing situation that Pint can't do.

You've got Laravel's Pint, but you've also got TLint, PHP Code Sniffer, and PHP CS Fixer, which each add some things to our linting and fixing situation that Pint can't do. For example, TLint can handle Laravel's Blade. So basically what we want to do is have all of them together in one kind of organized thing where they're all working together in unison, and that's what Duster provides for us. So we're going to want to click on this, which will copy the install, and then we can paste it in here, and this will require Duster in our project. Now one of the cool things you can do with Duster is you can come over here and you can grab this GitHub Actions publish and these Husky hooks. So with GitHub Actions, what happens is every single time somebody takes a certain action,

and you can grab this GitHub Actions publish and these Husky hooks. So with GitHub Actions, what happens is every single time somebody takes a certain action, for example, push a commit, it will run your linters or your fixers or whatever else you want on your project. And so we can use this to publish some GitHub Actions for Duster. We also have the same option for Husky hooks, which basically does the same thing, but instead of in CI, it's on your local machine. So we're going to install both for our projects. Let's start with GitHub Actions. So when we run this command, it's going to allow us to choose three different options. We can lint only, which means it just is going to error out if there is a problem.

So when we run this command, it's going to allow us to choose three different options. We can lint only, which means it just is going to error out if there is a problem. If it doesn't pass our code quality, you can fix and commit, which actually makes a new commit to fix it for you and then actually commits that to your git history. There's also a third option. The third option is a little bit more complicated. What it does is recognize that you often, if you're going to do git blame, which shows you what particular git commits contributed towards this line of code looking this way,

which shows you what particular git commits contributed towards this line of code looking this way, you don't often want to see the formatting commits. And so what this does is it fixes it, makes a new commit, but then it also adds that commit to a file that says, ignore these when we're running git blame. It's the most complex, but it's really the best. So we're actually going to use that one for this project. It says resulting commit will stop any current run. Yep, that's fine. This is what we expect it to do. It's nothing that stresses out.

It says resulting commit will stop any current run. Yep, that's fine. This is what we expect it to do. It's nothing that stresses out. So we say, yes, we want to continue and that's it. And now we're going to do the same thing for husky hooks, which again, remember with husky hooks, what happens is every single time we run git commit, that's the way we're going to set it up. It's before you actually run git commit, it's going to run duster for you. So you don't even get the whole way up to continuous integration before it runs. We also get an option here.

So you don't even get the whole way up to continuous integration before it runs. We also get an option here. We can either have it lint so it'll error out the commit, or we can have it fix and commit, which means it'll actually make a fix and then commit the fix for us. You may have noticed that when I was running that, we saw this little error here that says xcrun: error: invalid active developer path. Sometimes when you update Mac OS, it loses its reference to where the Command Line Developer Tools live. And you need to basically run a command that says, hey, here's where it is.

it loses its reference to where the command nine tools live. And you need to basically run a command that says, hey, here's where it is. And this is the command xcode-select -s. And then you just pass it the information of where Xcode is. So I went to, I turned off recording. I went to another tab. I ran this, is everything good? And now we've got husky hooks enabled. So to dive a little bit further into what husky does, it allows you to set a configuration of what to do at certain moments in the git workflow. And in your .husky directory, you can add a new file for every single moment. We've got one here for the pre-commit moment, which is right before git runs commit.

And in your .husky directory, you can add a new file for every single moment. We've got one here for the pre-commit moment, which is right before git runs commit. And basically you're defining what happens in that moment. And we're saying is run the NPM package lint-staged. What lint-staged lets you do, as you can see in our config file here, is define that at that particular moment, it's going to run lint-staged, which is going to say only for files that are staged in git. So that are like added into our current working git stuff that match this particular glob, then take this action. So we say for all the .php files, we are going to run vendor/bin/php-cs-fixer fix on them, but only the PHP files and only the staged ones.

then take this action. So we say for all the .php files, we are going to run duster fix on them, but only the .php files and only the staged ones. So that's it for duster. And now it's time to take a look at our next project that we're going to pull in, which is called prettier. So prettier is a little bit more complicated to install in a Laravel app than duster is. So I wrote up a blog post in my personal blog, walking you through all the steps and all the dependencies you need. So you go over to mattstafford.com, check out the articles and find this article, how to set up prettier on a Laravel app, linting tailwind class order and more.

So you go over to mattstafford.com, check out the articles and find this article, how to set up prettier on a Laravel app, linting tailwind class order and more. And you can see that that's what I'm really using it for more than anything else, is for linting my tailwind class order. And I wanted to find a setup where I could get the official tailwind. So this is how to order them. I wanted it in IDEs. I wanted it in the command line. I wanted it in CICD. I wanted it everywhere. And I found that this is the ideal setup for it. So just we're going to walk through the steps here,

And I found that this is the ideal setup for it. So just we're going to walk through the steps here, and it's going to talk through exactly how to get that done. So as we read through, it's going to show us the dependencies we need to install with NPM. There's a file called prettier.rc that we need to install. That is basically a configuration file. So as soon as we run that, I've got my options here or my examples here, and here's the main example I'd recommend that you use. But of course, you can configure it however you want. And then there's a prettierignore file that's a little bit like .gitignore.

But of course, you can configure it however you want. And then there's a .prettierignore file that's a little bit like .gitignore. It's instructions about how to use the package. And unsurprisingly, there's also some information here about what it looks like for you to run it automatically with Husky as one option, hooks into VS Code as another option, and in GitHub Actions, just like we used for the other project. So for the project that we're working on right now, we did the installation, and now we need to set up our .prettierrc file. So let's get started there.

and now we need to set up our prettier .rc file. So let's get started there. All right, so we're going to paste in the sample prettier .rc configuration file, and you can learn more about it in my article or their docs, but you can see we're preferring around 120-character-wide column, and we're setting some specifications of how we want to handle quotes and tabs and commas and all that kind of stuff. So we also need to add a .prettierignore file. You can grab this and use it. It's the best one I put together, but I'm not an expert.

You can grab this and use it. It's the best one I put together, but I'm not an expert. So if you are a prettier expert, use your own and ignore mine. Ba-dum-ching. So now we're going to set it up with Husky locally. As you can see, we're using lint-staged just like we did for Duster, and there's an example here that looks exactly, you know, not exactly, but very similar to the one did for Duster. I did mention I should probably tweak this to only run on files in the resources directory, so if you are a, you know,

I did mention I should probably tweak this to only run on files in the resources directory, so if you are a, you know, lint staged guru, feel free to tweak this for your own, but for now we're just going to copy this, edit our lint-staged config file, and we're just going to paste it in directly below. As you can see, this one's shaped like an array, but the new one is just a direct string, so I've got to put them next to each other with a little bit different syntax. So now we're going to go and we're also going to set it up in GitHub Actions, and as you can see, there's two options.

So now we're going to go and we're also going to set it up in GitHub Actions, and as you can see, there's two options. It's the format your code option, or it is the lint your code and fail if it fails option, just like we had with Duster. For this project, once again, we're going to choose the one that says format your code, and so let's check out that tutorial. So let's look through. They've got some sample code here that we can use, and we're just going to find the ultimate sample GitHub Action and copy it. Now, if you're not familiar, GitHub Actions live in the .github / workflows directory,

and we're just going to find the ultimate sample GitHub Action and copy it. Now, if you're not familiar, GitHub Actions live in the .github slash workflows directory, and every file in there is a specific workflow, so we already have the Duster one here. As you can see, it's defining basically when certain behaviors happen, take certain steps, and this is all for Duster. So what we need to do is make one now for prettier as well, and we will name that one prettier, right, and we'll paste in what we copied. As you can see, it just says check out the code,

and we'll paste in what we copied. As you can see, it just says check out the code, and then it's going to run this npm run format, and I actually showed in my blog post how to do this npm run format. It's something you add to the script section of your package.json file, and it's a shortcut basically to run all of this code here. If you're a Laravel developer, you're familiar with, you know, the dev npm run dev or npm run build, so we're just going to add a new shortcut of our own here. So let's grab it from there and paste it in.

so we're just going to add a new shortcut of our own here. So let's grab it from there and paste it in. So the one thing that you might notice here is that this is going to end up with this format command running, and when it runs in continuous integration, we're going to end up with a lot of extra commits, and that's one of the reasons why we use continuous integration as a fallback, not as the primary place this is happening, because remember, we've got Husky on our local machine actually running it long before it actually hits this continuous integration

because remember, we've got Husky on our local machine actually running it long before it actually hits this continuous integration and handling those things, we have less commits. And then you can also install it in your IDE if you want, and having it in your IDE means less commits. And so this is just one piece of a larger puzzle, and you don't have to do any of the pieces. I would recommend you at bare minimum choose a code style and apply it across your code base in whatever way makes you comfortable. You don't have to use these particular tools

and apply it across your code base in whatever way makes you comfortable. You don't have to use these particular tools or these particular moments of integration. I just wanted to show you that these are the ones that I really like right now. All right, let's take a breath. We're done with all the code styling and formatting things. We have a few more steps to take to get our local development environment up and running so that we have all the dependencies we need, and we are going to be ready to build this app.

so that we have all the dependencies we need, and we are going to be ready to build this app for the rest of this video series. So there are a few other dependencies we want to take a look at, making sure we have an order, and the first one would be a database. But because we chose to use SQLite for this particular project, we're good. We don't need any dependencies there. If we did, I would highly recommend dbEngine, which is a free tool for setting up MySQL and other things like that on your Mac.

which is a free tool for setting up MySQL and other things like that on your Mac. So let's talk now about mail. I use a tool called MailPit, which allows you to basically send mail to a local server, and it gives you a mock email inbox that you can use to click around things. There's a couple different ways to install it. I used Homebrew, but you can also use Tighten's Takeout, which is a Docker-based tool.

I used Homebrew, but you can also use Tighten's Takeout, which is a Docker-based tool. If you don't have Homebrew or you don't want to use Homebrew. Either way, I recommend setting up some way for you to be able to click through an email inbox. You could just use Laravel's log feature for your mail, but I highly recommend something that lets you view and click on your actual emails, and MailPit's a really great way to set that up. That's it for mail, and for any other dependencies.

and MailPit's a really great way to set that up. That's it for mail, and for any other dependencies that we're going to need to deal with, they're either going to work by default because Laravel has reasonable local drivers, or we're going to set them up in a particular video. So let's take a look and make sure our database is actually working. We're going to hit php artisan migrate, and it says nothing to migrate, which means we've got a database up and running,

and it says nothing to migrate, which means we've got a database up and running, and it's actually migrated. Because we're using SQLite, it's going to be in the database/database.sqlite file. We can actually open up that file and see that it's a file that just has content there, but it's not content we can actually understand or see. Here's what's interesting, though, is the full data of the application is just in that file.

Here's what's interesting, though, is the full data of the application is just in that file. So if we delete that file and we create a new one, we now have what's effectively an empty, un-migrated database. So we can run php artisan migrate, and now the database migrations will run just fine. So let's take a look at our tests now, make sure they all pass, and they all pass, and yeah, at this point, we've got a functioning database, we've got functioning tests, we've got our mail working,

and yeah, at this point, we've got a functioning database, we've got functioning tests, we've got our mail working, and all the other dependencies we need to think about, again, we're going to deal with in future videos. All right, so you've done it. You now have a local, functioning Laravel app up in the browser, linting, mail dependency, database dependency. It's everything you need to basically get started working. So that's what we're going to do next time, asterisk.

It's everything you need to basically get started working. So that's what we're going to do next time, asterisk. We also want to make sure we've got it up and running in a staging environment, so the next time is actually going to be that, and then we'll be ready to work. So for now, git add, git commit, push it up to GitHub if you want, and I'll see you again next time.