Introduction
This time I will write the procedure for publishing Laravel's Composr self-made package.
The basic steps are the same as in the previous article, so if you haven't read it yet, we recommend reading this article first.
Let's make a Composer packages - chapter.1
Preparation
Please refer to the previous article for the structure and preparation of directories and files.
When you create your own package with Laravel, implement the service provider
which is the core of FW called Laravel on the package side as well.
Since Laravel 5.5, a mechanism called Package Auto Discovery
has been introduced, and the service provider will be automatically loaded by adding the following to thecomposer.json
of the package to be created.
"extra": {
"laravel": {
"providers": [
"Vendor\\PackageName\\PackageServiceProvider"
]
}
}
It is also possible to create something like a debug tool by creating a route within the service provider
or by inserting middleware in the created route.
By the way, I have released the following packages.
temori/artisan-browser
It is a development tool for displaying a terminal-like screen on a browser, checking the route, and executing the artisan
command.
In this package as well, the root is created by the service provider, and the screen of the tool is displayed by adding it to the view displaying html elements, js, and css in the middleware.
The basic structure is the same as Previous article, but with a few additional directories for Laravel.
The following is the directory of the created package.
├── artisan-browser
│ ├── LICENSE
│ ├── README.md
│ ├── composer.json
│ ├── config
│ │ └── artisanbrowser.php
│ └── src
│ ├── ArtisanBrowser.php # Core class of this package
│ ├── ArtisanBrowserServiceProvider.php #Service Provider
│ ├── Controllers #Since the route was generated, the controller to call there
│ │ ├── AjaxController.php
│ │ └── AssetController.php
│ ├── Facades
│ │ └── ArtisanBrowser.php
│ ├── Logs
│ │ └── HistoryLogger.php
│ ├── Middleware # Middleware for rendering the html element of the package on all pages
│ │ └── Inject.php
│ ├── Renderer
│ │ ├── AssetRenderer.php
│ │ └── HtmlRenderer.php
│ ├── Resources
│ │ ├── artisanBrowser.css
│ │ ├── artisanBrowser.js
│ │ ├── image
│ │ │ └── logo.png
│ │ ├── vendor
│ │ │ ├── draggabilly.pkgd.min.js
│ │ │ ├── jquery-1.12.4.min.js
│ │ │ └── suggest.js
│ │ └── views
│ │ └── index.blade.php
│ └── helpers.php
Create a directory as appropriate depending on the package to be created.
Implement package processing
This is also the same as previous article, but if you want to control the behavior with a configuration file etc.
I think there will be occasions when you want the package user to edit the configuration file.
In such a case, Laravel has a mechanism to place an asset on the application side, so let's utilize it.
In the service provider's boot
method
$this->publishes ([
__DIR__.'/../config/artisanbrowser.php' => config_path('artisanbrowser.php','config'),
]);
If you write something like
# The force option places the file by overwriting even if the file already exists
php artisan vendor:publish --tag=config [--force]
The configuration file is placed on the application side with.
Alternatively, you can merge the configuration files of the application side and the package under vendor.
If you define the following in the register
method, you can use the settings on the package side as the default, and if you override only the value you want to change, the settings on the package side and the application side will be merged.
$this->mergeConfigFrom (
__DIR__.'/../config/artisanbrowser.php','artisanbrowser'
);
Details can be found in the official Package Development.
After the package implementation is completed, the procedure after that is the same as Previous article.
Finally
I wrote the flow of the Composer
self-made package in two parts. How was it?
I've only written a rough flow, but I hope you'll feel that it's not that high a hurdle: grinning:
You may want to start by creating a package for your own use.
Top comments (0)