Now that we have our plugin set up, we can go about moving all of those custom components that we defined inside the app into the plugin instead. Now, currently, a lot of our files live in the app directory, and the equivalent for this in our plugin is the source directory. The source directory is the one that's auto-loaded by Composer into this namespace here. So one step we're going to need to do is update the namespace of all of our files. Let's copy the entire forms directory, which has this inner components directory and our two component classes, the entire thing into the source directory. Now the new namespace, instead of app, is going to be our DanHaronFilamentToolkit namespace.

Now the new namespace, instead of app, is going to be our DanHaronFilamentToolkit namespace. So let's copy that through to both classes. As you can see, this section class here is using app concerns canBeSection, so we should move that over too. I'm going to copy this namespace here to update the reference, and copy this entire concerns directory with the canBeSection in, into source, and we can update the namespace here as well. So DanHaronFilamentToolkit. To reference our new classes in the Livewire component, we need to update the imports.

So DanHaron FilamentToolkit. To reference our new classes in the Livewire component, we need to update the imports. So in the demo form Livewire component, we can instead reference the FilamentToolkit namespace. If we refresh the page, all of these form components are still working as they should. However, the color picker is referencing the view from the app. There are no views in the plugin at the moment, and it's the same for the section. Sections also reference in this section view. So let's move those over into our plugin. Resources views, and we have our forms directory with components and color picker, and we have

So let's move those over into our plugin. resources/views, and we have our forms directory with components and color picker, and we have our section view here. I'm going to drag those directly into the resources/views directory of our plugin. So they're moved, and this is going to fail. The reason why this fails is because views that are registered to a package in Laravel have a specific prefix, and this prefix is defined in the service provider. Now Sparty's package tools will use the name of the package as the prefix, so all we need to do is prefix the views that we're referencing with the package name, and then ::, and that tells Laravel that the views can be found in this package.

to do is prefix the views that we're referencing with the package name, and then two colons, and that tells Laravel that the views can be found in this package. Let's do the same for section. Now when I refresh, the views are working again, and they're registered automatically by the Sparty package tools. Let's do the same for our info list. Now our info list has a similar section component, and we have our color entry. Let's copy all those over. So we can actually safely delete this forms namespace now, and probably the concerns directory too.

So we can actually safely delete this forms namespace now, and probably the concerns directory too. And let's move this entire info lists and components directories into the src directory. Now phpstorm's managed to refactor the namespace for each of these files, but if you're using a different editor, make sure that that's actually been done. It can be section, it's still referencing app though, so let's copy that over, and also update the namespace of our views with that prefix. So info list section, copy that, and the color entry, also copy that, and of course we need to move the view. So this info lists directory in the app resources moves into the plugin resources.

to move the view. So this info lists directory in the app resources moves into the plugin resources. Now when we refresh, everything's also working correctly. Finally we have our table. So we have our custom color column, and we also have our filter. Let's do the filter first because that's the easiest one. The filter doesn't have a view because it's using the form builder, so we can copy the entire thing and move it into the source directory, and this date range filter has its updated namespace. We don't have a view, so we don't have to use any prefixes.

its updated namespace. We don't have a view, so we don't have to use any prefixes. That should work out of the box, and the color column is not referencing anything in the app namespace, so we're good there. We just have to update this view. So again, let's prefix it with this Filament toolkit, and move the view from our app tables directory into resources/views. When I refresh, it's all working still. Now behind the scenes, phpStorm has also refactored the Livewire components that are using our new classes, so they've updated the app namespace here automatically, but again, if you're not

Now behind the scenes, phpStorm has also refactored the Livewire components that are using our new classes, so they've updated the app namespace here automatically, but again, if you're not using phpStorm, then make sure that's done. Now that our package contains all of the files that control our custom components, those custom components can be used by anyone who installs it.