In the previous episode, we toyed around with this idea of creating widgets that we can then reference in our views, like this. Now I would consider this the spiking phase. In some respects, you're not even to step one. You're still in a phase of toying around, trying to figure out what it is you want. So now that I have a better idea, let's now extract a package that I can maintain and develop separately from my core Laracasts application. Okay, so to do that, I'm going to use a tool called Laravel Packager. I really like this. It gives us a quick CLI for scaffolding Laravel packages, so it'll speed you up immensely.

I really like this. It gives us a quick CLI for scaffolding Laravel packages, so it'll speed you up immensely. Okay, so we will start with a brand new project. So you can come along if you'd like. All right, and next, I will pull in that package through Composer. All right, great. So we've pulled in that package, and it's automatically been discovered, which means if I run php artisan, we should have a series of new commands that you can find right here. Okay, we're going to build up a new package. So let's take a look at it.

Okay, we're going to build up a new package. So let's take a look at it. Let's run the help for it. We need to give it the vendor namespace as well as the name of the package. Okay, the vendor will be, do we want Laracast or myself? Let's do Laracast. And if this was something a little more prominent, I might think of a fun name, but this is probably something only I would use, so we'll pull that in. So now, we should have a new package, and there it is. You'll see a packages directory, and notice the directory structure.

So now, we should have a new package, and there it is. You'll see a packages directory, and notice the directory structure and the boilerplate is exactly what you'd need for most new projects. So specifically, notice in your composer.json file a few things here. If I scroll down, notice in the autoload section, it's already registered PSR4 autoloading for Laracasts\Widgets, and that is pointing to our source directory. So again, these are the sorts of things you would normally have to do, manually, and it's the same workflow every time. So this saves you quite a bit of effort.

manually, and it's the same workflow every time. So this saves you quite a bit of effort. And next, while we're here, notice that it sets up automatic discovery. So what this means is, it's basically just a little hint to Laravel, that when you pull in this package, it should automatically register the service provider and this alias for the project. Okay, anything else to be aware of here? We're pulling in all the testing tools we need, which would be phpunit, mockery, and orchestra-testbench.

We're pulling in all the testing tools we need, which would be phpunit, mockery, and orchestra-testbench. This gives you an easy way to test a package as if it was part of a traditional Laravel project. And we'll talk about that more in a little bit. And next, this probably needs a PR to the main repo, because as of Laravel 6, this would cause an issue, of course. So let's just say, around 5 or Laravel 6. Okay, next, I'll update my name. And we'll just go directly to the homepage.

that would override our defaults. So that's very useful. Next, it creates a singleton with a key of widget and the service container. And again, if you need it, keep it. Or if that's not something you would use, that can be removed as well. Okay, and that's basically it. So now here's the cool thing, and I'll create a new method called test. We'll make it static, and we will return it works. So I just wanna show you how easy and seamless this can end up being. At the moment now, if we go outside of our package into a standard routes/web.php

So I just wanna show you how easy and seamless this can end up being. At the moment now, if we go outside of our package into a standard routes/web.php file, let's just return, and I'm gonna try to load that widget file like this. And if we did everything correctly, and it's not quite right yet. But once we're done, we should see it works in the browser. But yeah, if we run it, that class isn't yet visible to our main project. So have a look at this though, here's another thing. If I go into the composer.json file, as part of running that packager, where is it? Yeah, this command.

where is it? Yeah, this command. When we ran that, it also updated your application's composer.json file. And if we scroll down, it creates a new local repository. So if we wanna pull in this repository, it'll reference this path here, which is to our packages directory, and it'll set up the necessary symlink. All right, so let's give it a shot. So if I switch back to the command line, I'm now in the root of the application, not the package. And I will go ahead and pull this in.

I'm now in the root of the application, not the package. And I will go ahead and pull this in. Okay, so notice we did find it, and it does set up a symlink to where we are currently maintaining the package. So if we go into the vendor directory down to, there it is, lyricas. Yeah, again, notice the widget directory is a symlink back to this package. Which means if I come back to Firefox and I give this a refresh, there we go. Okay, so now we can get started. I'm gonna switch back to some of the code we wrote in the previous episode, specifically the abstract Widget class.

I'm gonna switch back to some of the code we wrote in the previous episode, specifically the abstract Widget class. I'll copy that, switch back, go to Widget here, and then I do need to update the namespace. All right, next, if we switch back, what else do we need? We should update the ServiceProvider, and here's where we create the Blade directive. Although, I happen to know we're gonna change that a little bit as well to simplify things. But nonetheless, in the boot method, we can paste it in here.

to simplify things. But nonetheless, in the boot method, we can paste it in here. And I'll pull that in. Okay, so now our package is going to create the widget directive. Okay, and why are we getting red here? Yeah, here, this no longer makes any sense because it's an abstract class. So I will get rid of that. There we go. Okay, so now next, whenever you're creating a package, remember things are a little bit different.

For now, though, let's just get things working. So let's give it a shot. I'm gonna go back to my app directory, and we'll create a new class here. We'll call it TrendingArticles. And that'll be within the, what would it be, HTTP widgets directory. There we go. And we'll start by giving it a title. Next, as we learned in the last episode, we decided the default views directory would be called widgets. And it'll look for a file that matches the class name.

we decided the default views directory would be called widgets. And it'll look for a file that matches the class name. Okay, so here we'll spit out the title. All right, does that make sense? We have now created a new TrendingArticlesWidget that will extend that MasterWidget class, or that abstract class. We've set one property that should be available to the corresponding view. And then we reference that variable here. So the only remaining step is to see this on the page. So let's just return that default view that ships with Laravel.

So the only remaining step is to see this on the page. So let's just return that default view that ships with Laravel. And then if I return there, let's get rid of all this. Okay, so we are going to reference a widget called trendingArticles. And hopefully that should do it. So if we come back, ooh, the class does not exist. All right, we must have set up the namespace incorrectly. Oh, and yes we did, app/Http/Widgets. Okay, one more time, and there we go, it works. So let's come back, add another method like we had the last time.

Okay, one more time, and there we go, it works. So let's come back, add another method like we had the last time. Article one, Article two, and then if we go to the widgets view, within a UL, let's say for each article as article, and then we'll spit that out. Okay, come back to Firefox, give it a refresh, and this is working. Now in the next episode, I do want to take it a step further and write some tests, and we'll talk about things a bit more. But until then, let's have a look at what we did. We started by pulling in this package.

But until then, let's have a look at what we did. We started by pulling in this package. This allowed us to run a single command to quickly scaffold the necessary package. Next, we updated the ServiceProvider to register the Blade directive. And then, in the composer.json file, it automatically made itself available to anyone who installs your package. So that means when they run composer require laracasts/widget, this WidgetServiceProvider will automatically be included as part of their application. Next, to start, we've created a single abstract Widget class that, again,

as part of their application. Next, to start, we've created a single abstract Widget class that, again, will be available to your User. So at that point, all they need to do is create their new Widget, then create the corresponding view, and they're all set to go.