Asked  7 Months ago    Answers:  3   Viewed   31 times

I am having trouble to create package in Laravel 5 as workbench has been removed.

As in this thread (How create package in Laravel 5?), Goldorak suggest that we have to create our own package structure ourselves.

So, how can I create the workbench manually and get everything ready for package development?



Using the laravel Workbench package:

You can add the illuminate/workbench package in a Laravel 5 by adding to your composer.json:

"illuminate/workbench": "dev-master"

then add the WorkbenchServiceProvider into your config/app.php file:


Now you need to create the config/workbench.php file since it has been removed from Laravel 5:


return [
    | Workbench Author Name
    | When you create new packages via the Artisan "workbench" command your
    | name is needed to generate the composer.json file for your package.
    | You may specify it now so it is used for all of your workbenches.
    'name' => '',
    | Workbench Author E-Mail Address
    | Like the option above, your e-mail address is used when generating new
    | workbench packages. The e-mail is placed in your composer.json file
    | automatically after the package is created by the workbench tool.
    'email' => '',

Fill your information in this config file then you will be able to use the workbench command:

php artisan workbench vendor/name

Creating your own package structure

In this exemple we will create our package called awesome in a packages directory.

Here is the package structure:

  • Vendor: your vendor name, typically this is your github username.
  • Awesome: the name of your package
  • src: Where you put the business logic

To generate a composer.json file you can use this command in the packages/vendor/awesome directory:

composer init

Now we create a Awesome.php class in the src directory with a simple method:

<?php namespace Vendor/Awesome;

class Awesome
    public static function printAwesomeness()
        echo 'Awesome';

After that we add the package to the laravel composer.json psr-4 autoloader:

"autoload": {
    "psr-4": {
        "App\": "app/",
        "Vendor\Awesome\": "packages/vendor/awesome/src"

and we dump the composer autoloader

composer dump-autoload

Now you can use your package everywhere in your laravel 5 project. If you need some laravel specific feature like service provider or view publishing, use them as described in the Laravel 5.0 documentation.

Wednesday, March 31, 2021
answered 7 Months ago

You don't need to use laravel/laravel package in order to reuse Laravel's authentication.

It's enough to just import illuminate/auth package. This will give you 2 out of 3 things that you need to authenticate users:

  • Guard class (usually accessed via Auth facade) that provides authentication method (attempt, check, etc.)
  • User provider that fetches users based on their credentials - this package provides both Eloquent and Database user provider

The last thing you need is a User class, or any Model that implements AuthenticatableContract.

Guard takes user provider as one of its constructor's arguments, and user provider takes the class of a model to use as one of its constructor's arguments.

Those 3 elements are enough to use Laravel's authentication.

Friday, May 28, 2021
answered 5 Months ago

Everything you need to know is in the docs, as it should be.

Apart from that: Think of a package to be primarily being a Composer package. You are not only on/limited to the development path of Laravel packages but actually Composer's since it's the one that is in control of autoloading those. If the package happens to include Service Providers, Facades, Blade views etc. then it has become a package with Laravel integration. This is in line with the reason the workbench was removed: to have a PHP wide solution.

A good starting point would be an existing project, ideally with a good set of use cases for the package. At least during development of an application it gets clear what could or even should be separated into packages/libraries. As an alternative create a new laravel project and build well defined use cases around the package.

The following is one possible way to develop packages (as SO mentioned, it's a subjective matter) that allows both "in-project" development and composer installs later on.

Disclaimer: I did not follow any tutorials nor did I specifically search for them since Composer and Laravel's docs provide everything needed. I just had a look at other Composer packages in the vendor folder which leads me to believe it's a valid way. The following solution isn't even bound to Laravel - I use the same approach when developing Zend Framework moduls.

Note: Check that the package's namespace is not taken on packagist if you want to publish it there.

Set up a folder structure as may be found in other composer packages in a lib or packages folder in the project root.


Add the package's src folder (and additional files to be autoloaded) to the composer.json's autoload configuration of the laravel project. (See Composer's docs for available options)

"autoload": {
    "files": [
    "psr-4": {
        "MyNamespace\": "lib/my-namespace/my-package/src/"

Note: The my-namespace folder is version controlled in its own repository. Therefor, the lib folder could be git-ignored on the project level.

Add Service Providers and Facades to Laravel's app configuration as mentioned in the docs.

Develop and use the package as described in the docs and seen in other Laravel packages.

Run composer dumpautoload every time the application ignores recently made changes in your package/library.

If a package is meant to be made availabe publicly (e.g. github/packagist) it should include a minimum of the commonly expected software artefacts and ideally follow semantic versioning. Roughly described in folder contents:


Note: I tend to add a composer.json file in the package/library's root right at the beginning. It forces me to keep a clear idea of what this package provides and does not provide.

To publish the package/separate it from the project move related autoload parts from the project's to the library's composer.json and adapt the paths. Then publish the project to packagist/own Toran proxy. Require the package with --prefer-source - this way it is possible to develop the package while in use, even in multiple different projects.

Thursday, August 19, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :