In this chapter, we're going to take a pause from Laravel to examine another tool in the PHP world. Don't worry. Laravel does make use of this tool, so if you stick it out, it will make you a better Laravel developer.
Composer is something special in the world of PHP. It has changed the way we handle application dependencies and quelled the tears of many PHP developers.
You see, in the olden days, when you wanted to build an application that relied on third party dependencies you would have to install them with PEAR or PECL. These two dependency managers both have a very limited set of outdated dependencies and have been a thorn in the side of PHP developers for a long time.
When a package is finally available, you could download a particular version, and it would be installed on your system. However, the dependency is linked to PHP rather than your application itself. What this means is that if you had two applications that required different versions of the same dependencies... well, you’re gonna have a bad time.
Enter Composer, king of the package managers. First, let’s think about packages. What are they?
Let’s forget about the concept of ‘applications’ and ‘projects’ for now. The tool that you are building is called a package. Imagine a little box containing everything needed to run your application.
This box requires only one piece of paper (file) inside for it to be registered as a package.
Configuration
You have learned about JSON in the last chapter, right? You are ready for this now! Remember that I told you JSON was used for data transfer between web applications? Well, I lied. It’s not that I’m nasty. It just made it easier to teach the topic with a smaller scope of its ability. I do this a lot. Expect many lies!
Do you remember how JSON represents a complex piece of data? Why can’t we use it within flat files to provide configuration? That’s precisely what the Composer guys thought. Who are we to argue with them?
JSON files use the .json extension. Composer expects its configuration to live at the root of your package using the filename composer.json. Remember this! Laravel will use this file often.
Let’s open it up and start entering some information about our package.
{
"name": "marvel/xmen",
"description": "Mutants saving the world for people who hate them.",
"keywords": ["mutant", "superhero", "bald", "guy"],
"homepage": "http://marvel.com/xmen",
"time": "1963-09-01",
"license": "MIT",
"authors": [
{
"name": "Stan Lee",
"email": "stan@marvel.com",
"homepage": "http://marvel.com",
"role": "Genius"
}
]
}
Right. Here we have a composer.json file at the root of a package for the X-Men. Why the X-Men? They are awesome. That’s why.
Truth be told, all of the options (keys) in this file are optional. You would usually provide the above information if you intended to redistribute the package or release it into the wild.
To be quite honest with you, I normally go ahead and fill in this information. It doesn’t do any harm. The configuration above is used to identify the package. I have omitted a few keys that I felt were reserved for special circumstances. If you are curious about any additional config, then I would recommend checking out the Composer website which contains a wealth of information and documentation.
I also found this handy cheat sheet online, which may be useful for newcomers to Composer when creating new packages. Mouse over each line to discover more about the configuration items.
Let’s have a closer look at the configuration we have created for the X-Men package.
{"name": "marvel/xmen"}
This is the package name. If you have used Github then the name format will be familiar to you, but I’m going to explain it anyway.
The package name consists of two words separated by a forward slash (/). The part before the forward slash represents the owner of the package. In most circumstances, developers will use their Github username as the owner, and I fully agree with this notion. You can, however, use any name you like. Be sure to keep it consistent across all packages that belong to you.
The second part of the name string is the package name. Keep it straightforward and descriptive. Many developers choose to use the repository name for the package when hosted on Github, and once again I fully agree with this system.
{"description": "Mutants saving the world for people who hate them."}
Provide a brief description of the functionality of the package. Remember to keep it simple. If the package is intended for open source, then you can go into detail within the README file for your repository. If you want to keep some personal documentation, then this isn’t the place for it. Maybe get it tattooed on your back and keep a mirror handy? That makes the most sense to me. Sticky notes will also work well, though.
{"keywords": ["mutant", "superhero", "bald", "guy"]}
These keywords are an array of strings used to represent your package. They are similar to tags within a blogging platform and essentially serve the same purpose. The tags will provide useful search metadata for when your package is listed within a repository.
{"homepage": "http://marvel.com/xmen"}
The homepage configuration is useful for packages due to be open-sourced. You could use the homepage for the project, or maybe the Github repository URL? Whichever you feel is more informative.
Once again, I must remind you that all of these configuration options are optional. Feel free to omit them if they don’t make sense for your package.
{"time": "1963-09-01"}
This is one of those options that I don’t see very often. According to the cheat sheet, it represents the release date of your application or library. I’d imagine that it’s not required in most circumstances because most packages are hosted on Github or some other version control site. These sites normally date each commit, each tag, and other useful events.
Formats accepted for the time configuration are YYYY-MM-DD and YYYY-MM-DD HH:MM:SS. Go ahead and provide these values if you feel like it!
{"license": "MIT"}
If your package is due to be redistributed, then you will want to provide a license with it. Without a license, many developers will not be able to use the package at all due to legal restrictions. Choose a license that suits your requirements, but isn’t too restrictive to those hoping to use your code. The Laravel project uses the MIT license which offers lots of freedom.
Most licenses require you to keep a copy of the license within the source repository, but if you also provide this configuration entry within the composer.json file then the package repository will be able to list the package by its license.
The authors section of the configuration provides information about the package authors and can be useful for package users wishing to make contact.
Note that the authors section will allow an array of authors for collaborative packages. Let’s have a look at the options given.
{
"authors": [
{
"name": "Stan Lee",
"email": "stan@marvel.com",
"homepage": "http://marvel.com",
"role": "Genius"
}
]
}
Use an object to represent each author. Our example only has one author. Let’s take a look at Stan Lee. Not only does he have a cameo in every Marvel movie, but he’s also managed to make it into my book. What a cheeky old sausage!
{"name": "Stan Lee"}
I don’t know how to simplify this line. If you are having trouble understanding it, then you might want to consider closing this book, and instead pursue a career in sock puppetry.
{"email": "stan@marvel.com"}
Be sure to provide a valid email address so that you can be contacted if the package is broken.
{"homepage": "http://marvel.com"}
This time, a personal homepage can be provided, go ahead and leech some hits!
{"role": "Genius"}
The role option defines the author’s role within the project. For example, developer, designer, or even sock puppetry artist. If you can’t think of something accurate, then put something funny.
That’s all you need to describe your package. Let’s look at something more interesting. Dependency management!
Dependency Management
You have a box that will contain the X-Men. There aren’t a lot of mutants in that box yet, are there? To build a great superhero team (application) you will need to enlist the support of other mutants (3rd party dependencies). Let’s take a look at how Composer will help us accomplish this.
{
"name": "marvel/xmen",
"description": "Mutants saving the world for people who hate them.",
"keywords": ["mutant", "superhero", "bald", "guy"],
"homepage": "http://marvel.com/xmen",
"time": "1963-09-01",
"license": "MIT",
"authors": [
{
"name": "Stan Lee",
"email": "stan@marvel.com",
"homepage": "http://marvel.com",
"role": "Genius"
}
],
"require": {
}
}
We now have a new section within our composer.json called 'require'. This will be used to list our dependenc... mutants. From now on I’ll be omitting the rest of the configuration, and just showing the require block to shorten the examples. Make sure you know where it lives!
We know that the X-Men will depend on:
- Wolverine
- Cyclops
- Storm
- Gambit
There are loads of others, but these guys are 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 upstream changes. That could get boring. Let’s add them to the require section so that Composer will manage them for us.
{
"require": {
"xmen/wolverine": "1.0.0",
"xmen/cyclops": "1.0.1",
"xmen/storm": "1.2.0",
"xmen/gambit": "1.0.0"
}
}
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 following command.
git tag -a 1.0.0 -m 'First version.'
We have created version 1.0.0 of our application. This is a stable release that people can depend on.
Let’s have a closer look at the Gambit dependency.
{"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 owner.
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?
You can add as many dependencies as you like to your project. Go ahead, add a billion! Prove me wrong.
Listen, do you want to know a secret? Do you promise not to tell? Woah, oh-oh. Closer, let me whisper in your ear. Say the words you long to hear...
Your dependencies can have their own dependencies.
That’s right! Your dependencies are also Composer packages. They have their own composer.json files. This means that they have their own require section with a list of dependencies, and those dependencies might even have more dependencies. And that dep... well. You get the idea!
Composer will manage and install these nested dependencies for you. How fantastic is that? Wolverine might need tools/claws, tools/yellow-mask, and power/regeneration but you don’t have to worry about that. As long as you require the xmen/wolverine package, then Composer will take care of the rest.
As for dependency versions, they can assume some different forms. For example, you might not care about minor updates to a component. In which case, you could use a wildcard within the version, like this:
{"xmen/gambit": "1.0.*"}
Now Composer will install the latest version that starts with 1.0. For example, if Gambit had versions 1.0.0 and 1.0.1, then 1.0.1 would be installed.
Your package might also have a minimum or maximum boundary for package versions. This can be defined using the greater-than and less-than operators.
{"xmen/gambit": ">1.0.0"}
The above example would be satisfied by any versions of the xmen/gambit package that have a greater version number than 1.0.0.
{"xmen/gambit": "<1.0.0"}
Similarly, the less-than operator is satisfiable by packages less than the version 1.0.0. This will allow your package to specify a maximum version dependency.
{
"xmen/gambit": "=>1.0.0",
"xmen/gambit": "=<1.0.0"
}
Including an equals sign = along with a comparison operator will result in the comparative version being added to the list of versions which satisfy the version constraint.
Occasionally, you may wish to enter more than one version, or provide a range value for a package version. More than one version constraint can be added by separating each constraint with a comma (,). For example:
{"xmen/gambit": ">1.0.0,<1.0.2"}
The above example would be satisfied by the 1.0.1 version.
If you don’t want to install stable dependencies, for example, you might be the type that enjoys bungee jumping or skydiving; then you might want to use bleeding edge versions. Composer can target branches of a repository using the following syntax.
{"xmen/gambit": "dev-branchname"}
For example, if you wanted to use the current codebase from the develop branch of the Gambit project on Github, then you would use the dev-develop version constraint.
{"xmen/gambit": "dev-develop"}
These development version constraints will not work unless you have a correct minimum stability setting for your package. By default, Composer uses the stable minimum compatibility flag, which will restrict its dependency versions to stable, tagged releases.
If you would like to override this option, simply change the minumum-stability configuration option within your composer.json file.
{
"require": {
"xmen/gambit": "dev-master"
},
"minimum-stability": "dev"
}
There are other values available for the minimum stability setting, but explaining those would involve delving into the depths of version stability tags. I don’t want to overcomplicate this chapter by looking at those. Instead, I’d suggest looking at the Composer documentation for package versions to find additional information on the topic.
Sometimes, you may find yourself needing to use dependencies that only relate to the development of your application. These dependencies might not be required for the day-to-day use of your application in a production environment.
Composer has got you covered in this sithation thanks to its require-dev section. Let’s imagine for a moment that our application will require the Codeception testing framework to provide acceptance tests. These tests won’t be any use in our production environment, so let’s add them to the require-dev section of our composer.json.
{
"require": {
"xmen/gambit": "dev-master"
},
"require-dev": {
"codeception/codeception": "1.6.0.3"
}
}
The codeception/codeception package will now only be installed if we use the --dev switch with Composer. There will be more on this topic in the installation and usage section.
As you can see, the require-dev section uses the same format as the require section. In fact, there are other sections which use the same format. Let’s have a quick look at what’s available.
{
"conflict": {
"marvel/spiderman": "1.0.0"
}
}
The conflict section contains a list of packages that would not work happily alongside our package. Composer will not let you install these packages side by side.
{
"replace": {
"xmen/gambit": "1.0.0"
}
}
The replace section informs you that this package can be used as a replacement for another package. This is useful for packages that have been forked from another but provide the same functionality.
{
"provide": {
"xmen/gambit": "1.0.0"
}
}
This section indicates packages that have been provided alongside your package. If the Gambit packages source were included within our main package, then it would be of little use to install it again. Use this section to let Composer know which packages have been embedded within your primary package. Remember, you need not list your package dependencies here. Anything found in require doesn’t count.
{
"suggest": {
"xmen/gambit": "1.0.0"
}
}
Your package might have some extra packages that enhance its functionality but aren’t strictly required. Why not add them to the suggest section? Composer will mention any packages in this section as suggestions to install when running the Composer install command.
That’s all I have on dependencies. Let’s take a look at the next piece of Composer magic. Autoloading!
Auto Loading
By now we have the knowledge to enable Composer to retrieve our package dependencies for us, but how do we go about using them? We could require() the source files ourselves within PHP, but that requires knowing exactly where they live.
Ain’t nobody got time fo' dat. Composer will handle this for us. If we tell Composer where our classes are located, and what method can be used to load them, then it will generate its autoloader. This can be used by our application to load class definitions.
Actions speak louder than words, so let’s dive right in with an example.
{
"autoload": {
}
}
This is the section in which all of our autoloading configurations will be contained. Simple, right? Great! No sock puppetry for you.
Let’s have a look at the most simple of loading mechanisms, the files method.
{
"autoload": {
"files": [
"path/to/my/firstfile.php",
"path/to/my/secondfile.php"
]
}
}
The files loading mechanism provides an array of files which will be loaded when the Composer autoloader component is loaded within your application. The file paths are considered relative to your project’s root folder. This loading method is effective, but not very convenient. You won’t want to add every single file manually for a large project. Let’s take a look at some better methods of loading more significant amounts of files.
{
"autoload": {
"classmap": [
"src/Models",
"src/Controllers"
]
}
}
The classmap is another loading mechanism which accepts an array. This time, the array consists of a number of directories which are relative to the root of the project.
When generating its autoloader code, Composer will iterate through the directories looking for files which contain PHP classes. These files will be added to a collection which maps a file path to a class name. When an application is using the Composer autoloader and attempts to instantiate a class that doesn’t exist, Composer will step in and load the required class definition using the information stored in its map.
There is, however, a downside to using this loading mechanism. You will need to use the composer dump-autoload command to rebuild the class map every time you add a new file. Fortunately, there is another loading mechanism which is intelligent enough not to require a map. Let’s learn about PSR-0 class loading.
PSR-0 class loading was first described in the PSR-0 PHP standard and provides an easy way of mapping PHP namespaced classes to the files that they are contained in.
Know that if you add a namespace declaration to a file containing your class, like this:
<?php
namespace Xmen;
class Wolverine
{
// ...
}
Then the class becomes Xmen\Wolverine, and as far as PHP is concerned, it is an entirely different animal to the Wolverine class.
Using PSR-0 autoloading, the Xmen\Wolverine class would be located in the file Xmen/Wolverine.php.
See how the namespace matches up with the directory that the class is contained within? The Xmen name-spaced Wolverine class is located within the Xmen directory.
You should also note that the filename matches the class name, including the uppercase character. Having the filename match the class name is essential for PSR-0 autoloading to function correctly.
Namespaces may have several levels. For example, consider the following class.
<?php
namespace Super\Happy\Fun;
class Time
{
// ...
}
The Time class is located within the Super\Happy\Fun namespace. PHP will recognize it as Super\Happy\Fun\Time and not Time.
This class would be located at the following file path.
Super/Happy/Fun/Time.php
Once again, see how the directory structure matches the namespace? Also, you will notice that the file is named the same as the class.
That’s all there is to PSR-0 autoloading. It’s quite simple really! Let’s have a look at how it can be used with Composer to simplify our class loading.
{
"autoload": {
"psr-0": {
"Super\\Happy\\Fun\\Time": "src/"
}
}
}
This time, our psr-0 autoloading block is an object rather than an array. This is because it requires both a key and value.
The key for each value in the object represents a namespace. Don’t worry about the double backward slashes. They are used because a single slash would represent an escape character within JSON. Remember this when mapping namespaces in JSON files!
The second value is the directory in which the namespace is mapped. I have found that you don’t need the trailing slash, but many examples like to use it to denote a directory.
This next bit is crucial and is a serious ‘gotcha’ for a lot of people. Please read it carefully.
The second parameter is not the directory in which classes for that namespace are located. Instead, it is the directory which begins the namespace to directory mapping. Let’s take a look at the previous example to illustrate this.
Remember the super happy fun time class? Let’s have another look at it.
<?php
namespace Super\Happy\Fun;
class Time
{
// ...
}
We now know that this class would be located in the Super/Happy/Fun/Time.php file. With that in mind, consider the following autoload snippet.
{
"autoload": {
"psr-0": {
"Super\\Happy\\Fun\\Time": "src/"
}
}
}
You might expect Composer to look in src/Time.php for the class. This would be incorrect, and the class would not be found.
Instead, the directory structure should exist in the following format.
src/Super/Happy/Fun/Time.php
This is something that catches so many people out when first using Composer. I can’t stress enough how important this fact is to remember.
If we were to run an installation of Composer now, and later add a new class Life.php to the same namespace, then we would not have to regenerate the autoloader. Composer knows exactly where classes with that namespace exist, and how to load them. Great!
There's one other useful loading mechanism that was added much later into Composer's lifecycle. It's called PSR-4 namespacing and is a little more convenient than PSR-0 loading.
Here's an example require block for PSR-4 name-spacing.
{
"autoload": {
"psr-4": {
"Dayle\\Blog\\": "src"
}
}
}
Here, we've mapped the Dayle\Blog namespace to the src directory. Don't forget to suffix the namespace with two slashes! This means that we don't have to create the Dayle/Blog directory structure, as all classes will be relative to the src directory. For example, consider the following class.
Dayle\Blog\Content\Post
It would be located at the following location on disk.
src/Content/Post
We've specified the namespace prefix in our autoloader, so we don't need to create the Dayle and Blog subfolders. This makes it much easier to see our project in the tree view of our text editor.
You might wonder why I put my namespaced files in an src folder? This is a common convention when writing Composer based libraries. In fact, here is a common directory/file structure for a Composer package.
src/ (Classes.)
tests/ (Unit/Acceptance tests.)
docs/ (Documentation.)
composer.json
Feel free to keep to this standard, or do whatever makes you happy. Laravel provides locations for its classes which we will examine in a later chapter.
Now that you have learned how to define your autoload mechanisms, it’s time that we looked at how to install and use Composer so that you can start taking advantage of its autoloader.
Installation
The Homestead machine that we configured in the installation chapter will have composer pre-installed. You'll need to SSH into the machine to use it.
First, make, sure that the machine is running by using vagrant up. Next, you'll use vagrant ssh to create an SSH connection to the machine. You're now ready to begin using Composer.
That was easy, wasn't it?
Usage
Let’s assume that we have created the following composer.json file in our package directory.
{
"name": "marvel/xmen",
"description": "Mutants saving the world for people who hate them.",
"keywords": ["mutant", "superhero", "bald", "guy"],
"homepage": "http://marvel.com/xmen",
"time": "1963-09-01",
"license": "MIT",
"authors": [
{
"name": "Stan Lee",
"email": "stan@marvel.com",
"homepage": "http://marvel.com",
"role": "Genius"
}
],
"require": {
"xmen/wolverine": "1.0.0",
"xmen/cyclops": "1.0.1",
"xmen/storm": "1.2.0",
"xmen/gambit": "1.0.0"
},
"autoload": {
"classmap": [
"src/Xmen"
]
}
}
Let’s go ahead and use the install command to install all of our package dependencies and generate our autoloader.
composer install
The output we get from Composer will be similar to:
Loading composer repositories with package information
Installing dependencies
- Installing tools/claws (1.1.0)
Cloning bc0e1f0cc285127a38c232132132121a2fd53e94
- Installing tools/yellow-mask (1.1.0)
Cloning bc0e1f0cc285127a38c6c12312325dba2fd53e95
- Installing power/regeneration (1.0.0)
Cloning bc0e1f0cc2851213313128ea88bc5dba2fd53e94
- Installing xmen/wolverine (1.0.0)
Cloning bc0e1f0cc285127a38c6c8ea88bc523523523535
- Installing xmen/cyclops (1.0.1)
Cloning bc0e1f0cc2851272343248ea88bc5dba2fd54353
- Installing xmen/storm (1.2.0)
Cloning bc0e1f0cc285127a38c6c8ea88bc5dba2fd53343
- Installing xmen/gambit (1.0.0)
Cloning bc0e1f0cc285127a38c6c8ea88bc5dba2fd56642
Writing lock file
Generating autoload files
Remember that these are fake packages used as an example. Downloading them won’t work! They are however more fun since they are X-men! Yay!
Why are there seven packages installed when I only listed four? Well, you forget that Composer automatically manages the dependencies of dependencies. The three extra packages are dependencies of the xmen/wolverine package.
I’d imagine you are probably wondering where these packages have been installed? Composer creates a vendor directory in the root of your project to contain your package’s source files.
The package xmen/wolverine can be found at vendor/xmen/wolverine, where you will find its source files along with its own composer.json.
Composer also stores some of its files relating to the autoload system in the vendor/composer directory. Don’t worry about it. You will never have to edit it directly.
So how do we take advantage of the awesome autoloading abilities? Well, the answer to that is even simpler than setting up the autoloading itself. Simply require() or include() the vendor/autoload.php file within your application. For example:
<?php
require 'vendor/autoload.php';
// Your awesome application bootstrap here!
Great! Now you can instantiate a class belonging to one of your dependencies. For example:
<?php
$gambit = new \Xmen\Gambit;
Composer will do all the magic and autoload the class definition for you. How fantastic is that? No more littering your source files with thousands of include() statements.
If you have added a file in a class mapped directory, you will need to run a command before Composer can load it.
{title="Example 49: Rebuild class map.", lang=text} composer dump-autoload
The above command will rebuild all mappings and create a new autoload.php for you.
What if we want to add another dependency to our project? Let’s add xmen/beast to our composer.json file.
{
"name": "marvel/xmen",
"description": "Mutants saving the world for people who hate them.",
"keywords": ["mutant", "superhero", "bald", "guy"],
"homepage": "http://marvel.com/xmen",
"time": "1963-09-01",
"license": "MIT",
"authors": [
{
"name": "Stan Lee",
"email": "stan@marvel.com",
"homepage": "http://marvel.com",
"role": "Genius"
}
],
"require": {
"xmen/wolverine": "1.0.0",
"xmen/cyclops": "1.0.1",
"xmen/storm": "1.2.0",
"xmen/gambit": "1.0.0",
"xmen/beast": "1.0.0"
},
"autoload": {
"classmap": [
"src/Xmen"
]
}
}
Now we need to run composer install again so that Composer can install our newly added package.
Loading composer repositories with package information
Installing dependencies
- Installing xmen/beast (1.1.0)
Cloning bc0e1f0c34343347a38c232132132121a2fd53e94
Writing lock file
Generating autoload files
Now xmen/beast has been installed and we can use it right away. Smashing!
You may have noticed the following line in the output from the composer install command.
Writing lock file
You might also have noticed that Composer has created a file called composer.lock at the root of your application. What’s that for I hear you cry?
The composer.lock file contains the information about your package at the time that the last composer install or composer update was performed. It also contains a list of the exact version of each dependency that has been installed.
Why is that? It’s simple. Whenever you use composer install when a composer.lock file is present in the directory; it will use the version numbers contained within the file instead of pulling down fresh versions of each dependency.
This means that if you version your composer.lock file along with your application source (and I highly recommend this) when you deploy to your production environment, it will be using the exact same versions of dependencies that have been tried and tested in your local development environment. This means you can be sure that Composer won’t install any dependency versions that might break your application.
Note that you should never edit the composer.lock file manually.
While we are on the topic of dependency versions, let's learn how to update them. For example, if we had the following requirement in our composer.json file.
{"xmen/gambit": "1.0.*"}
Composer might install version 1.0.0 for us. However, what if the package was updated to 1.0.1 a few days later?
We can use the composer update command to update all of our dependencies to their latest versions. Let’s have a look at the output.
$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing xmen/gambit (1.0.1)
Cloning bc0e1f0cc285127a38c6c8ea88bc5dba2fd56642
Generating autoload files
Great! The xmen/gambit package has been updated to its latest version, and our composer.lock file has been updated.
If we wanted to update only that one dependency rather than all of them, we could specify the package name when using the update command. For example:
composer update xmen/gambit
Wait, what’s that (including require-dev) bit mean? Remember the require-dev section in the composer.json file where we list our development only dependencies? Composer expects the update command to be only executed within a secure development or testing environment. For this reason, it assumes that you will want your development dependencies, and downloads them for you.
If you don’t want it to install development dependencies, then you can use the following switch.
composer update --no-dev
Also, if you would like to install developer dependencies when using the install command, simply use the following switch.
composer install --dev
The last thing you should know is that you can use the composer self-update command to update the Composer binary itself. Be sure to use sudo if you have installed it globally.
sudo composer self-update
That just about covers all the Composer knowledge we will need when working with Laravel. It has been a lot of information to take in, and a long chapter for these weary fingers, but I hope you have gained something from it.
If you feel that a particular topic needs expanding, then please be sure to let me know! In the next chapter, we're going to learn how to configure our Laravel application. Get your configuration gloves on!
My books are available online for free to encourage learning. However, if you'd like for me to keep writing, then please consider buying a digital copy over at Leanpub.com.
It's available in PDF, ePub, and Kindle format, and contains a bunch of extras that you won't find on the site. I have a full-time job, and I write my books in my spare time. Please consider buying a copy so that I can continue to write new and exciting books!