Creating packages

Prosper Otemuyiwa recently wrote an article on how to create Laravel 5 packages on his blog. Although his approach is entirely valid and may suit you well, I work a little differently when creating a new package.

First, I create a new GitHub repository where the package will live. In that repo I copy the contents of PHP League’s skeleton repo. That skeleton provides a great starting point. You get (amongst others):

  • a very nice readme template
  • a changelog
  • a license file
  • a composer.json file

After replacing all placeholder values with the correct values I go ahead and submit the repo to Packagist . Note that by this time the package has zero functionality. Normally you should refrain from adding non functional packages to packagist . But considering at this stage there’s only a master branch and no tagged versions, most developers will not use the package. “Requiring dev-master in your project is like having unprotected sex with the internet”, a wise man once said.

Now the package is available on packagist, it’s time to create a fresh Laravel installation. My preferred way of doing this is with the Laravel installer:

laravel new package-name

When the installation is complete I use Dimitrios Savvopoulos’ method of installing a package in development in a Laravel app. This consists of requiring the dev-master of your new package in the composer.json of the new newly created Laravel app. The package can be pulled in by running:

composer update --prefer-source

The new package will be installed as it’s own git repo in the vendor directory so changes can be committed and pushed to GitHub from right inside the vendor directory. Nice! Now everything is set up to start developing the new package.

When the package functionally works and is thoroughly tested I tag a version 1.0.0 on GitHub. When doing further development on the package I use semantic versioning to tag subsequent releases.

If you have another, possibly better, way to create new packages, please let me know.