By Younes Rafie

Quick Tip: Composer & Github – Develop Packages Interactively

By Younes Rafie
Help us help you! You'll get a... FREE 6-Month Subscription to SitePoint Premium Plus you'll go in the draw to WIN a new Macbook SitePoint 2017 Survey Yes, let's Do this It only takes 5 min

In this quick tip I will show you how to use Composer in conjunction with Github to ease your package development process.

Using Composer Repositories

Say you have a package hosted on Github, and want to develop it while using it in your project. After having your Github repository set up, you can use Composer repositories configuration to tell Composer about your code repository.
Let’s say I have a package on Github with a URL, and my package composer.json file looks like the following.

// composer.json

  "name": "whyounes/laravel5-twig",
  "description": "Twig for Laravel 5"

Composer has a nice way of loading packages through Github or any VCS. You only specify your repo URL and it will automatically scan your composer.json for package info. Keep in mind that repositories have a higher priority over Packagist when installing or updating.

// composer.json

"require": {
	"laravel/framework": "5.0.*",
	"whyounes/laravel5-twig": "dev-master"
"repositories": [
        "type": "vcs",
    	"url": ""

Now you can keep working on your local package and push your changes to Github, If you made some changes to the local package and run composer update before pushing to Github you will lose them.
Branches are used for versioning your package. Version names can either be numbered like 1.0, 1.0.*, etc, or you’ll have to prefix your branch name with dev-*, in our example the dev-master version will look for the master branch. You can check the documentation for more info.


We've began using this approach on our internal packages. To make it even better, you can tag releases on Github and then specify that tag as the package version in place of dev-master, since being tied to master can be dangerous for production sites. Our basic workflow for this is:

git add -A
git commit -m 'add some cool new feature'
git tag 1.1.0 # Or whatever your new version is
git push origin master --tags

Now, you can require your package by that new version number.

Get the most important and interesting stories in tech. Straight to your inbox, daily.Is it good?