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.
