There's no point. It's a waste of your time. All right, so let's say you want to, I don't know, interact with Amazon S3 storage. Well, again, you could interact with their API yourself, or it looks like we have an SDK that we could pull in. If we use a framework like Laravel, it looks like we have a service provider to assist with that. Great. Maybe you want to test your code. We haven't talked about that much, but we will get into it very soon.

Maybe you want to test your code. We haven't talked about that much, but we will get into it very soon. Yeah, it looks like there are some packages, one called mockery, one called phpunit, one called pestphp that I will introduce you to. Maybe you want to make some kind of application on the command line. So where the command line, as you see here, is your interface rather than a browser. Well, that's called the console. All right, well, it looks like symphony offers a console component that we can pull in.

Well, that's called the console. All right, well, it looks like Symfony offers a console component that we can pull in. And then even further, if we want to style it to make it look very pretty, we can pull in a tool called Termwind. All right, so you get the general idea. Whatever you need to do, there is probably a package that is available to you. Okay, rhyme intended. All right, so let's pull this in together. And yeah, work along with me. getcomposer.org, we will hit download.

yeah, if you want, you can quickly peruse this page here. And yeah, here, this is probably the most interesting part. Most likely, you will want to put composer.phar. And that is available here. All right, we will want to put that in a directory that is part of our path so that we can simply call composer from anywhere in our application. Okay, so you can see they are moving composer.phar into our /usr/local/bin directory. Okay, so let's just copy that and do the exact same thing. All right, so I will paste that in, move it into my path.

Okay, so let's just copy that and do the exact same thing. All right, so I will paste that in, move it into my path. And yeah, hopefully, we're all set to go. So we can test this by closing the tab, opening a new tab with Command-T, at least for me. And if I run composer, there we go. We're up and running. Okay, so now I want to, well, before we pull in a package, why don't we create a basic composer.json file? Because actually, as it turns out,

why don't we create a basic composer.json file? Because actually, as it turns out, before I introduce you to any of these packages, I first want to introduce you to Composer's built-in autoloading feature. So let's run composer init within our current project. composer init. Okay, this command will guide you through creating your composer.json configuration. Now, in our case, I'm not building any specific package. So very quickly, I can enter my way through most of these settings, as you see here. Next, do I want to define my dependencies interactively?

I just want to do it manually for you. All right, would you like the vendor directory added to your .gitignore? So this means, do we want this folder to be included, ultimately, when I push all of this code up to a production environment? And generally, no, you don't want to do that. So we can add the vendor folder to this .gitignore file. And that is a way to instruct Git to, well, ignore this directory. That's exactly what it does. All right, so now if I switch over to phpStorm, all right, and yeah, we can see two new files here.

All right, so now if I switch over to phpStorm, all right, and yeah, we can see two new files here. composer.json, that's our configuration file for Composer. And then also .gitignore, which is unrelated to Composer entirely. It's related to, well, Git. Any folder or file that we specify here will be ignored by Git. And yeah, you can see it added slash vendor. So that means ignore your vendor directory. But I don't see a vendor folder. All right, well, that's the next step.

But I don't see a vendor folder. All right, well, that's the next step. We need to run composer install. So install our Composer dependencies. But right now, if we have a look, well, I don't have any dependencies specified. But still, let's go ahead and run it. All right, so have a look. Where is it? Yeah, right here. Nothing to install, update, or remove.

Yeah, right here. Nothing to install, update, or remove. And yeah, it makes sense. We didn't ask Composer to install any package. So it didn't install any package. But then right down here at the bottom, generating autoload files. This is what I want to finish up with. So yeah, as it turns out, in addition to Composer being a great dependency manager, it also ships with a great autoloader. And as it turns out, that's what almost all of us use these days.

Well, if I got rid of our autoload registration, and I switch back to the browser. And no, it's not magic. It doesn't happen automatically. So we do get a fatal error. Class CoreContainer was not found. All right, so the next question. How do we make use of Composer's autoloader? Well, if I switch back, here's that new vendor directory. And again, that was created when we ran composer install. And if I open it up, this will contain all of the packages

And again, that was created when we ran composer install. And if I open it up, this will contain all of the packages that we ultimately pull in with composer. But right now, we just have one folder for composer itself. And if I open it, and by the way, you don't need to pay much attention to any of these files. I'm just showing you to give you a quick bird's eye view of what's happening here. And yeah, you'll see a bunch of autoload specific files, like individual classes I want to autoload, or namespaces, or PSR-4 based autoloading. So what is PSR-4?

or namespaces, or PSR-4 based autoloading. So what is PSR-4? It's just a specification for how we can go about autoloading files. That's it. It's just a spec. For now, that's all you need to know about it. All right, so we are going to make use of that. So if I come back to composer.json, here's what we do. Here, I will add a new property called autoload. And this is where I can define and configure

Here, I will add a new property called autoload. And this is where I can define and configure how I want autoloading for my application to behave. And yeah, I want to take advantage of PSR-4. Okay, so let's see what we have right now for our namespaces. We have this core folder and an HTTP folder. Now, ultimately, I think I'd like to graduate to a top level app folder. But for now, we can keep them separate. So if I open up any of these classes that we've created, it looks like my top level namespace is core.

So if I open up any of these classes that we've created, it looks like my top level namespace is Core. And that namespace corresponds to this directory name. All right, let's try it out. I'm going to say the namespace Core corresponds to the core directory name. Now, I will warn you, there's a small little mistake here that I introduced on purpose. And I did that because it's a near certainty that at least for one of your projects, you will make this mistake as well. And luckily, Composer can find this and notice it and then tell you how to fix it. All right, so we'll get to that in a minute.

And luckily, Composer can find this and notice it and then tell you how to fix it. All right, so we'll get to that in a minute. So whenever you update your autoloading configuration, you will want to switch back to the terminal and run composer dump-autoload. And that'll repopulate those autoload files. But now we can see, yeah, right here, a non-empty psr-4 prefix must end with a namespace separator. A namespace separator is, well, let's go to any of these. Well, do we have one? How about middleware?

Well, do we have one? How about middleware? That's a namespace separator, just a slash. All right, so it's telling us right here, a psr-4 prefix has to end with that backslash. All right, so we'll do it right here. But now phpStorm is squawking again. And that's because, well, as it turns out, a backslash can be used for escaping purposes. So now it thinks I'm trying to escape that quote, and I'm not.

a backslash can be used for escaping purposes. So now it thinks I'm trying to escape that quote, and I'm not. So I actually need to use two backslashes. I'm going to escape the backslash. Yeah, a little confusing. You'll get used to it. All right, so let's run it again. composer dump-autoload. All right, and I think we're all set. Let's go and check just for fun.

All right, and I think we're all set. Let's go and check just for fun. If I go back into that Composer folder and into autoload psr-4, it looks like the file was changed on disk. So let's reload it. And sure enough, we can see this mapping. And yeah, it's very simple. It's saying this namespace can be found at our base directory, which is just the root of the project, and then into the core folder.

which is just the root of the project, and then into the core folder. Okay, now we actually had two, as we talked about. And again, eventually, we will merge these. But for now, we'll double up. So let's add another top-level namespace for HTTP. All right, back to Composer. Let's duplicate this and then swap it out. And yeah, notice I don't have to do it for every nested directory. I only have to declare the top level, the root namespace.

Can I switch back to Firefox and cross my fingers and hit refresh? No, it still doesn't work. And that's because, well, yes, we have defined these mappings, but I still haven't required Composer's autoloader into my project. So that's the next step. Let's go into public/index.php. I can now delete our old autoloader function. And yeah, maybe right here, I can say require. And I want to pull in vendor and then this file right here, autoload.php. Okay, but I can't just do this.

And I want to pull in vendor and then this file right here, autoload.php. Okay, but I can't just do this. I can't say vendor/autoload.php, because remember, I'm currently in the public directory. So this would look for a vendor folder within public. And of course, I can't do that. So I need to go up a level to the root and then to vendor. And yeah, it looks like many episodes ago, we defined a constant for that. So why don't we do that now? base_path and then concatenate vendor/autoload.php.

So why don't we do that now? Base path and then concatenate vendor/autoload.php. And yeah, I would even move this as high up as we can go. So in fact, why don't we just do something like that? And yeah, this is very common, very typical for any modern php project or package. If you inspect their entry point at the very top, you will see a require statement that pulls in Composer's autoload file. If you're using a framework like Laravel, have a look. One of the first things it does is pull in Composer's autoload file. All right.