One of the most important parts of Laravel Framework training is that you can write packages; in fact, packages are features that you can use to add new features to your site. Packages can anywhere from Using programs that improve the programming process and make it easier for programmers. There are different packages, such as standalone packages that can be used in all PHP language frameworks (Carbon and Behat packages), Laravel -specific packages, and other packages. In the continuation of this article, we will review the important points about packet writing in Laravel. After reading this article, you can start building packages in Laravel and design your desired packages for this popular and powerful framework so that Other people and programmers can also use your packages.

When writing a Laravel program, it does not matter if you use contracts or facades, because both have the same level of testability. However, when writing packages, your package does not have access to all of Laravel’s testing helpers. In this case, if you want to write your own package tests, you can use the Orchstral Testbench package.

Package Discovery

In the config / app.php file within a Laravel application, the list of service providers that the application should load is as follows in the provider’s section. When someone installs your Package, you want your Service Provider to be included in this list.
Instead of forcing users to add your Service Provider to the list, you can define a Provider in your Package’s extra section of the composer.json file. In addition to Service Providers, you can also specify the facades you want to register.

"extra" :  { 
    "laravel" :  { 
        "providers" :  [ 
            "Barryvdh \\ Debugbar \\ ServiceProvider" 
        ] , 
        "aliases" :  { 
            "Debugbar" :  "Barryvdh \\ Debugbar \\ Facade" 
        } 
    } 
} ,

Once your package is configured for Discovery, Laravel automatically registers its Service Providers and Facades during installation, providing an easy and quick installation for users who want to use your Package.

Avoid Package Discovery

If you are a consumer of a Package and you want to disable Package Discovery, you can put the package name in the extra section of the composer.json file of your application.

"extra" :  { 
    "laravel" :  { 
        "dont-discover" :  [ 
            "barryvdh / laravel-debugbar" 
        ] 
    } 
} ,

Also, if you want to disable Package Discovery for all Packages, you can use the * symbol as shown below.

"extra" :  { 
    "laravel" :  { 
        "dont-discover" :  [ 
            "*" 
        ] 
    } 
} ,

Service Providers

Service Providers are a bridge between your application and the Package you want. One of the most important functions of the Service Provider is that it loads the resources of packages, views, and configuration files for you to use easily.

And Service Providers inherit from the Illuminate \ Support \ ServiceProvider class and have two main boot and register methods that perform most operations. It should also be noted that the Basic Service Provider class is in illuminate/support, which we must add to our package dependencies.

Configuration

You should normally put your package configuration file in a directory called config in your program. This allows users who use your Package to easily change the default configuration settings of your Package to their liking.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 {
     $ this -> publishes ([
         __DIR__ . '/path/to/config/courier.php' => config_path ( 'courier.php' ),
    ]);
}

When your Package users run Laravel vendor or publish command, your file is quickly copied to the Publish location. Once your Configuration is released, you can access its values, just like any other configuration file.

$ value = config ( 'courier.option' );

Default Package Configurations

You can easily merge your package configuration file with a copy of the published program. Doing this allows users to define the settings they want in the Published copy of the config file. You can also use the mergeConfigFrom method to merge configurations within the register method of the Service Provider.

/ **
 * Register any application services.
 *
 * @return void
 * / 
public  function  register ()
 this $ this -> mergeConfigFrom (
         __DIR__
     . ' /path/to/config/courier.php' , 'courier'
    );
}

 

I����b�W

Routes

 

If your package contains one or more Routes, you can load them using the load routes from the method. If the Route‌s of the program are cached, and you can not load the Route‌s, this method will run automatically.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 {
     $ this -> loadRoutesFrom ( __DIR__ . '/routes.php' );
}

Migrations

If your package contains one or more migrations, you can submit them to Laravel using the load migrations from method so that you can load them. The load migrations from the method accept the path of package migrations as its only argument.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadMigrationsFrom ( __DIR__
     . ' / path / to / migrations' );
}

After registering your Package Migrations, all migrations will be executed automatically when the PHP artisan migrate command is executed.

Factories

If your package contains one or more Factors, you can introduce them to Laravel using the loadFactoriesFrom method so that you can load them. The loadFactoriesFrom method accepts the path of the package factories as its only argument.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadFactoriesFrom ( __DIR__
     . ' / path / to / factories' );
}

After registering your Package Factories, you can use them in your application.

factory (Package \ Namespace \ Model :: class) -> create ();

Translations

If your package contains one or more translation files, you can submit them to Laravel using the load translations from the method so that you can load them. For example, if your package name is a courier, you can do the following.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadTranslationsFrom ( __DIR__
     . ' / path / to / translations' , 'courier' );
}

You can load the courier package and its welcome command as follows.

echo trans ( 'courier :: messages.welcome' );

Publishing Translations 

If you want to publish your package translations in the directory or resources/lang/vendor section of your application, you can use the publishes method in the Service Provider. The published method accepts an array of package paths and their desired publish locations. For example, to publish Courier Package translation files, you can do the following:

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadTranslationsFrom ( __DIR__
     . ' / path / to / translations' , 'courier' );
    $ this -> publishes ([
         __DIR__ . '/ path / to / translations' => resource_path ( 'lang / vendor / courier' ),
    ]);
}

When your Package users execute Laravel vendor or publish an Artisan command, your Translation Package is published in a specific Publish location.

Views

To register your package views, you must tell Laravel where the views are located. You can do this using the load views from a method in the Service Provider. The load views from the method accept two arguments to the View path and the package name. For example, if your package name is courier, you can enter codes such as the following in the Service Provider’s boot method.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadViewsFrom ( __DIR__
     . ' / path / to / views' , 'courier' );
}

Once your View path is registered in the Service Provider, you can load your desired View, such as admin, from the courier.

Route :: get ( 'admin' , function () {
     return view ( 'courier :: admin' );
});

Rewrite the package views

When rewriting or overriding the views of a package, when you use the load views from a method, Laravel first registers two locations for your views, namely the resources/views/vendor folder of the program and the directory that we specified. So, suppose we want to use a courier in this example. First, Laravel checks to see if the developer provides a custom version of View in resources/views/vendor/courier.

Then, if there is no custom version of View, Laravel searches for the directory or View location that we loaded in the same method, load views from. This allows users who use your Package to customize your package views as they wish easily.

Publish Views

If you want the views to be published in the directory or resources/views/vendor section, you can use the publishes method in the Service Provider. This method accepts an array that includes the package view paths and custom Publish locations.

پ / **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadViewsFrom ( __DIR__
     . ' / path / to / views' , 'courier' );
    $ this -> publishes ([
         __DIR__ . '/ path / to / views' => resource_path ( 'views / vendor / courier' ),
    ]);
}

When your Package users run vendor: publish, your package views are quickly copied to the Publish location.

View Components

If your package contains one or more View Components, you can introduce them to Laravel using the loadViewComponentsAs method so that you can load them. The loadViewComponentsAs method accepts two tag prefix arguments for View Components and an array of View Component classes.

For example, if your package Prefix is ​​courier, and you have an Alert and a View Components button, you can enter codes such as the following in the Service Provider’s boot method.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> loadViewComponentsAs ( '
     courier' , [
        Alert :: class,
        Button :: class,
    ]);
}

Once the View Components are registered in your Service Providers, you can use them in the Views below.

< x-courier-alert /> 
< x-courier-button />

Commands

You can use the Commands function to register your package commands with Laravel. This function takes an array of command class names as input. When commands are registered for the first time, you can execute them using the CLI:

/ **
 * Bootstrap the application services.
 *
 * @return void
 * / 
public  function  boot ()
 {
     if ( $ this -> app-> runningInConsole ())
         this $ this -> commands ([
            FooCommand :: class,
            BarCommand :: class,
        ]);
    }
}

Public Assets

Your Package may contain assets such as JavaScript, CSS, and images. To publish these assets in the Public folder of the program. You can use the publishes method in the Service Provider. We add a so-called Public Asset Group Tag to the published method in the following example.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> publishes ([
         __DIR__
     . ' / path / to / assets' => public_path ( 'vendor / courier' ),
    ], 'public' );
}

When your Package users run vendor: publish, your package assets are quickly copied to the Publish location. Since you typically need to overwrite or rewrite Assets each time. You update a Package, you can use force – at the end of your command.

php artisan vendor: publish --tag = public --force

Publishing File Groups

Sometimes you may want to publish groups of Public Assets of a package and resources separately. For example, you might want to allow your users to publish your package configurations without having to publish their assets. You can do this by tagging them when calling the published method from the Service Provider package.

For example, suppose you want to use tags to define two Publish Groups in the boot method of the Service Provider package.

/ **
 * Bootstrap any application services.
 *
 * @return void
 * / 
public  function  boot ()
 this $ this -> publishes ([
         __DIR__
     . ' /../config/package.php' => config_path ( 'package.php' )
    ], 'config' );
    $ this -> publishes ([
         __DIR__ . '/../database/migrations/' => database_path ( 'migrations' )
    ], 'migrations' );
}

Users using your Package can now publish these groups individually using its tags when running vendor: publish.

php artisan vendor: publish --tag = config

Conclusion:

Learning to write a package at Laravel Professionally can be one of the biggest needs of any Laravel programmer. Many swing programmers today use ready-made packages to improve the quality of their programs. Instead of writing code themselves from scratch. Packages with different security bugs or any other bugs are less commonly used, and maybe in a few months, with the launch of another package with the same features. Still, with fewer bugs, your Package will generally be used by no other program. Do not write.

The packages you create are one of the biggest strengths of your resume, both for employment in Iran and for employment in any other country.