codebright

The Primers 18
• Storm
• Gambit
There are loads of others, but these guys are pretty cool. We will stick with them for now. You see,
we could copy the source files for these guys into our application directly, but then we would have to
update them ourselves with any changes. That could get really boring. Let’s add them to the require
section so that Composer will manage them for us.
1 "require": {
2 "xmen/wolverine": "1.0.0",
3 "xmen/cyclops": "1.0.1",
4 "xmen/storm": "1.2.0",
5 "xmen/gambit": "1.0.0"
6 }
Here we are listing the packages for our mutant dependencies, and the versions that we would like
to use. In this example, they all belong to the same owner as the X-Men package, but they could just
as easily belong to another person.
Most redistributable packages are hosted on a version control website such as Github⁷ or Bitbucket⁸.
Version control repositories often have a tagging system where we can define stable versions of our
application. For example with git we can use the command:
1 git tag -a 1.0.0 -m 'First version.'
With this we have created version 1.0.0 of our application. This is a stable release which people
can depend on.
Let’s have a closer look at the Gambit dependency.
1 "xmen/gambit": "1.0.0"
You should know by now that Composer package names consist of an owner and a package nickname
separated by a forward slash (/) character. With this information we know that this is the gambit
package written by the xmen user.
Within the require section, the key for each item is the package name, and the value represents the
required version.
In the case of Gambit, the version number matches up to the tag available on Github where the code
is versioned. Do you see how the versions of dependencies are now specific to our application, and
not the whole system?
⁷http://github.com
⁸http://bitbucket.org