Laravel 5 package development: where to start? [cl

Whilst creating this question, Stackoverflow already said this is a subjective question I'm asking. However, I think this is a question many starting (package) developers asked themselves at some point.

I have a couple of years of experience with Laravel now. And I've come to a point where I want to create a Laravel based package. I've done some research and a ton of information you find out there is already old and so outdated.

I have not one but several questions on this subject:

Where is a good starting point? I can't seem to find where I should start. I've read the docs and honestly I'm still in the dark here.
Is it recommended to first create your package as a normal project before creating a package out of it?
Where should the package be developed in? What's your workspace? A regular Laravel project? I've read workbenchis no more?
Are there some recommened tutorials you've followed and found helpful?

I sincerly hope this question gets some good answers, because current search results are not what they should be. Certainly not for a beautiful framework like Laravel.

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.

lib/
    my-namespace/
        my-package/
            config/
            src/
                Facades/
                    MyPackage.php
                Support/
                    helpers.php
                MyPackageServiceProvider.php
            ...

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": [
        "lib/my-namespace/my-package/src/Support/helpers.php"
    ],
    "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:

docs/
tests/
composer.json
LICENSE
readme.md

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.