Oh Dear is the all-in-one monitoring tool for your entire website. We monitor uptime, SSL certificates, broken links, scheduled tasks and more. You'll get a notifications for us when something's wrong. All that paired with a developer friendly API and kick-ass documentation. O, and you'll also be able to create a public status page under a minute. Start monitoring using our free trial now.

Creating packages

Original – by Freek Van der Herten – 2 minute read

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.

Stay up to date with all things Laravel, PHP, and JavaScript.

Follow me on Twitter. I regularly tweet out programming tips, and what I myself have learned in ongoing projects.

Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer.

Expect quick tips & tricks, interesting tutorials, opinions and packages. Because I work with Laravel every day there is an emphasis on that framework.

Rest assured that I will only use your email address to send you the newsletter and will not use it for any other purposes.