Composer is great because you can easily add libraries to your projects and have it automatically pull down the same versions for every deploy of your site. The downside to composer libraries (and open source in general), is that sometimes it's hard to get your pull requests for bug fixes merged into the master so you can use it on your project or add your own customizations. You can fork the repository in order to gain more control over the source.

Fork

The first step is that you need to fork the library you need to make changes to.

On the project's GitHub repo there's a fork button in the upper right hand corner of the screen. Screen Shot 2015-04-24 at 11.16.22 AM

If you press this button GitHub will ask you where you want to fork the repo. We're going to use the TPT organization but you can fork it to your personal repo if you're the only one using it.

Screen Shot 2015-04-24 at 11.16.34 AM

Wait for GitHub to do it's magic.

Screen Shot 2015-04-24 at 11.16.39 AM

After this process has completed, you'll be brought to the homepage of your new repo. The thing I really like about Forks on GitHub is that it lists the original repo it was forked from.

Screen Shot 2015-04-24 at 11.16.47 AM

Edit the libraries composer.json

The first step to getting this library ready to be used is we need to change the name of the project in the composer.json for the repo we just cloned.

The first line will look similar to this:

"name": "squizlabs/php_codesniffer"

We need to change it to our new repo location (see this commit):

"name": "thisprogrammingthing/php_codesniffer"

If you don't make this change, composer won't see this as a valid package because the names won't match.

At this point you can make any other changes that you need to this library.

Loading your fork using composer

Now that we have a custom version of the library we can load it into our project. The first step is to make some changes to the composer.json file for the project it's going to be used in:

Before

{
    "require": {
        "squizlabs/php_codesniffer": "*"
    }
}

After

{
    "repositories": [
        {
            "type": "git",
            "url":  "https://github.com/thisprogrammingthing/PHP_CodeSniffer.git"
        }
    ],
    "require": {
        "thisprogrammingthing/php_codesniffer": "dev-master"
    }
}

This is an SUPER simple composer.json but the important points are:

  1. We added a repositories key to our JSON file that includes where to find our custom library.
  2. We changed the organization field to our custom libraries path.
  3. We switch to using dev-master. This is so we don't have to tag "releases" (I've found this to be overkill in most cases).

Now we just need to update our project so it uses our version of the library

$ composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)                           
  - Removing squizlabs/php_codesniffer (2.3.0)
  - Installing thisprogrammingthing/php_codesniffer (2.3.1)
    Cloning 8104697c26152935642da5413e970ffa1725e2ee

Writing lock file
Generating autoload files

The downsides

This process isn't without it's downsides. Yes, it's cool to have a copy of a library but now you have a version of a library that you have to patch every so often. I recommend doing this ONLY if you can't find another way around having a fork or if you don't care about not having the latest security and bug fixes (which you should).