 That's great. All right, as long as you made it to the coffee break, that's awesome. One, I apologize for my voice. I'm just getting over a cold. So hopefully you can hear me okay and I don't go like this on the recording too much. I hope it's not the only time. Just to show you what it was. Great, thank you for coming to my session, Composer 101. You know, as you heard in Dries' keynote that composer is a part of Drupal and if you're just new to it, it's gonna be a great introduction to the basics you need to get going with composer. Not really focused on the Drupal side of it. That's a little more complex but I have some follow-ups for everybody here. So by the end of this, you should be able to use Composer though in your PHP projects and in your Drupal projects. Before I get going, raise the hands. How many people here like live demos? Okay, I too like to live dangerously. So we'll see how the internet does. If it craps out, I have a pre-recorded demos and I'll switch to that but if not, we're gonna do some live demoing to show you how simple composer can be. So before we get started, a little bit about myself. Hello, my name's Mike Miles. I'm from Boston, Massachusetts and I work as the Senior Technical Solutions Manager at a digital marketing agency called Genuine. Genuine, we help, we make agile brands. We help brands be fun and innovative across all the technologies that we in full service capabilities that we have. We're not a Drupal shop but we have digital strategists and video production designers and UX and development across a whole bunch of technologies, Drupal just being one of them. That's what I do during the day and night. I run a podcast called Developing Up which is focused on the non-technal side of being a developer. So anything that has to do with your development career but not anything to do with coding. So how to work on a team, how to negotiate, how to say no to your boss or your clients, stuff like that. A new episode's actually coming out in 15 minutes on leadership. So check that out after the session. I mean you can listen to it during the session but I prefer you don't. If you wanna know anymore about me, you can find me online at MikeMiles86. I've been working with Drupal for almost 10 years now doing everything you can think of with Drupal. I help lead the Boston Drupal Meetup and the New England Drupal camp. So if you're ever in New England you should come check out the Drupal scene there designed for Drupal which is in the summer. We have Drees Key Noting which is an exciting reason to come. So you should check that out. So you're a typical developer, happy person that we have, really cool people. In PHP projects it's easy for them to manage a piece of PHP code. A file that they control, that they own, that they write. Developers are happy to do that. Multiple files, no problem. But what happens is if you are writing PHP code or using, you wanna use other libraries you have to start pulling in people's code that you don't control. So this could be for logging. This could be for sending emails. You don't wanna reinvent the wheel. And developers, they can do this. They're not so happy about it because in the repositories they have to add code that they don't control, that they can't change. This is the case if you're using Drupal. Drupal core, you're never supposed to hack core. So they're not that thrilled about doing that. And especially if you have third-party dependencies that have third-party dependencies or you have two dependencies that share a dependency on another library. All of a sudden this starts to get complicated and developers really don't like that because now you're spending a lot more time managing the code than writing the code and differentiating your project to building cool things. And don't even get me started on if there's a security update, like there was two weeks ago for Drupal core, then Z, oh my God, developers hate that. Well, with developers, as a developer, I can say what we don't like is having to spend most of our time maintaining something we don't control and that we can't change. And it's a fundamental truth no matter what your role is, everyone here probably knows this, that every project has limited time and budget. So amount of time when it has to be delivered to the client, to your marketing department, whoever you're building a project for in Drupal, it has to be delivered at a certain time. That means you only have so much time to build it and focus on what you need to accomplish. You only have so much money to hire people to do that. What this means is if you are having your developers, if you're a developer and you have to maintain all this, you're spending much of that time, much of that budget, making sure everything is in sync, everything's working, that you're really trying to wrangle other people's code to build something amazing. When what you wanna spend most of your time on is building what differentiates your product, building what you control and focusing your time and energy on that to build as great of a product as you can. This is where Composer comes into place. Composer is a dependency manager for PHP. It's a per-project dependency manager. I hope I'm being recorded. Everything's good. Everything's good, great. Could you just announce if there are some Cs? There are some Cs available. Please move in, fill in. I'll make me feel good about myself. So Composer is a dependency manager for PHP. Like Dries mentioned is, Dries note, there are other technologies that have dependency managers like Node or JavaScript has NPM, Ruby has, I forget the name of it, but what they allow you to do is take that maintenance out of your developer's hands and give it to a computer that can do it reliably and can constantly do it and it handles all that things for you that you don't want your developers have to worry about. So what I wanna talk about today is basically three buckets of things. One, explain the benefits of using Composer and dependency manager on your projects. How it frees up your developers, how it frees up your project, how it allows you to build really amazing products without worrying about the tools you wanna use to do it. I'm gonna outline the basic Composer project structure and setup, how you get Composer going and started. So you can start using it on any project and the typical file structure that you may use and you may see in Composer projects. And then demonstrate the five basic Composer commands that you need to know to get up and running with Composer. So by the end of this conference, conference, well, yeah, by the end of the conference, by the end of this talk, you should be able to set up a Composer project, know the commands to get third party dependencies and know the commands to have Composer manage those dependencies for you so you don't have to worry about them. Sound like a good plan for everybody? I see some head nods, great. All right, so just to illustrate what Composer does, we again have our happy cool developer who is happy to maintain their code but they don't wanna maintain other people's code. So instead of worrying about all those dependencies, the developer just talks to Composer and says, hey Composer, these are the libraries my project requires. These are the versions, these are what I wanna use to make things work. Composer says, great, I'm gonna get those, I'm gonna organize them, I'm gonna see if they have dependencies, I'm gonna get those dependencies, I'm gonna see if those dependencies have dependencies and I'm gonna get those for you, I'm gonna handle it buddy, all good. The developer can also say, hey Composer, I wanna update these, there's been a security update, can you update these packages? And Composer will say, no problem, I got you, I will update them, I will update their updates, I will update their dependencies, it'll be all good. So Composer abstracts all this maintenance and frees up all this maintenance time from your development team so they just have to worry about the code they're gonna write. Now every Composer project has this basic structure. There's the project root and then there might be a Composer.far file which I'll explain in a moment. There's a Composer.json file which is basically the file your developers use to tell Composer what your project requires. There's the Composer.lock file is what Composer uses to keep track of all the projects or the packages it's maintaining for you. I like to think of it as like Composer's database even though it's just a file. And then there's the vendor directory where Composer stores all that third party code so you never have to touch it, you never have to see it. And then there's everything else that has to go into a project. So that could be your custom modules, your themes, whatever type of PHP project you're working on, if it's Drupal or not. Everything else goes in your project. We're not gonna worry about that stuff. Now for security purposes, when you are working on a Composer project, it's ideal that you keep everything related to Composer above your web root. So your JSON file, your Composer.lock file in your vendor directory. The reason for this is you don't want those web accessible since it's code you don't control. So if you have a third party library let's just say an example I know of PHPUnit. If you're writing PHPUnit tests and you're using Composer to manage the PHPUnit library, if that's in your web root, if someone's clever enough, they can find a path to execute PHPUnit tests which may not seem like a big deal but if someone's really smart they can use that to do some sort of injection to your database or really get some details they're not supposed to. So keeping all your Composer project files above your web root is a secure way to make sure that the only thing that's web accessible is the code you control. Now obviously to work with Composer, you need Composer installed on your machine. This is where the Composer.far file comes into place. Composer.far is a PHP archive file. It's like an executable. Composer itself is PHP based and you can install Composer one of two ways. Well, first you can install on Windows, they have a Composer setup file executable that'll help you set it up. Then you can install it on Linux, they have a download page that will explain the steps to download it. So I click there, is the internet working? We'll see. But like I said, there's two ways you can install Composer, globally on your machine or locally. If you're installing globally, the benefit of that you only have to install it once. You install Composer on your machine, you can use it across any projects you have locally, you're good to go. The caveat of that is that anyone on your team, you have to make sure they've installed Composer and because people are gonna install Composer at different times, they may have different versions of Composer. You're introducing that variable of, well, it works on my machine and you don't wanna do that. But you can do it globally if that works for you. You can install it per project and this is where with the project structure I showed, we have the Composer.far in your project route. If you do that, then you can run Composer kind of like Drush, where it's recommended you have Drush per project. You can have Composer per project, you can run Composer in that project and what you know there is that everyone who downloads the project from like Git or wherever, they have Composer already. You know everyone's using the same version of Composer and that alleviates that. The caveat is the way you have to run the command is you have to type PHP first in the command line and then Composer. So it's a little annoying. But let's see what it's like to install Composer on your machine. And this will be our test to see if the Wi-Fi is good enough. So this is the download page on Composer on getcomposer.org. It has three, four PHP lines to run in your command line. They recommend you come here every time you wanna install Composer because the version of Composer changes so does the hash check. So what I'm simply gonna do is I'm gonna copy this PHP line, go in my handy-dandy terminal which I have an empty project. And I'm gonna just paste it there. And so what the command line's gonna do, it's gonna go getcomposer.org.installer, download that code into composer-setup.php. And all right, I'm already bored of this. So we're gonna go to the prerecorded version. Skip, skip, skip, skip, skip, skip, skip. All right, so I put in the copy command, it downloads it on my machine. And then what I do is I copy the other PHP code which is gonna do a hash check on that file I downloaded, make sure it works, it's verified. Then you run PHP composer-setup.php. This is the file you just downloaded and this is gonna check on your machine if your PHP settings validate for what Composer needs. And then you can set a file name so you can just call Composer. If everything works, it's gonna say great, Composer is there. Then you can delete the file and you're good to go. So that was quick. So what just happened was I downloaded the PHP file from getcomposer.org. I did a hash check to make sure I got the file I was expecting and it's verified. Then I ran composer-setup.php so that it can check my system to make sure my system has the right requirements. And then it installs Composer which is the composer.far file. And then I removed the setup file from my project directory because I no longer need it because I have Composer set up. So that was locally. After doing that, I'm all set. I have Composer.far in my project. We can do the same thing for the global install. It's the same couple steps. The only difference is once composer.far is added to your project, you're gonna move it into a directory that is relative to your path variable for your machine. So here I'm moving it to user local bin composer. And I forgot to type where I wanna move it to. Great, I wanna move composer.far to a global path variable. In doing that, now I can just run composer from anywhere. So if I actually show this from my terminal because I don't need composer to do that, I already have composer installed. Surprise, surprise. If I type composer, I have composer on my machine. I can run it from anywhere. So globally I can type composer because it's in a variable. It's in a path that's in my path variable. Without it, I have to type, let me clear this for you. I would have to type php composer.far to run composer. So now that you have composer installed, really it's running these four commands and then moving it either into a global location or keeping it for your project. Then what I can do, this is the recorded one, is we wanna start using composer to tell composer what we need. So composer, like I said, it uses a .json file. This is how you interface with composer and say, composer, these are the dependencies my project has. Now, if you're good with JSON, you can write it yourself. It's just a JSON schema file. You give your project information, like your name, the description, the type, which for our case is project. You can provide license information if you want that for your project, like I'm using the MIT license, their GPL license, any author information, an array of authors. The stability of the packages you wanna use, if you leave that out, it's gonna assume you only wanna use stable code. So I recommend you leave that out, especially for production work. The require array, which is what we'll get into, which is where you list all the third-party packages you wanna use for your project. And the require dev, which is another array of packages, which you can tell composer, only install this in my dev environment. So you can do things such as the coder module or drush you can put in there or other tools. But you don't have to write this yourself. You can have composer do it. And I can actually show this live because I have composer installed. So you can run the composer init command. And what composer init does is it brings up an interactive guide to generate that composer.json file. So by default, it's gonna ask for your package name, which is your project name. It'll be your logged in name and the directory you're in. I recommend, like they say, vendor name, client name. So I'll do Drupalcon composer 101. It's gonna ask for a description. This is just metadata. That's good for you and your team. My demo composer project. It's gonna ask for any author information. This could be your team members. I'm gonna leave it default for now. Minimum stability. I'm gonna leave that default because I only want stable code. It's 11 o'clock. I want a type project is what I'm going to be doing. Don't care about licenses for now. Now to ask you for an interactive, would you like to declare any dependencies right now? Do you wanna search for any third-party code you wanna use in your project? So right now I'm gonna say no because we're gonna get into that in more depth. And then what it shows me is that JSON, it's going to generate so I can validate it. Yes, it has my project name, my project description, my author information, and I have empty requirements. So I'm gonna say yes, composer, generate that for me. So now in my project directory, I have composer.json. And if I open that, we're gonna see, that's really big. We're gonna see, it's the JSON file that it showed me it was going to generate. All the information it listed, now I have it available. So once you have composer.json, you can start searching for packages. But the question is, well, where do I find packages? Where do I find PHP code in third-party libraries? If you're using composer and you don't do anything extra, composer is going to look at packages.org. This is the official repository for PHP packages that are installable with composer. You can search for anything here. Search for packages, comes up a big list. You can find Drupal here, but you can't find Drupal modules. So if you want things for, say Drupal, they're Drupal specific, you can say in your composer.json file, where else to look for files? You can add a repositories array to your composer.json file. And there's two types of repositories you can add, one that is a composer one and one that is just for version control systems. For example, Drupal has its own composer packages library, which is available at packages.drupal.org slash eight or slash seven for Drupal seven. If you want to install Drupal themes, Drupal modules, you have to add this to your composer.json file. And this will tell composer when it starts looking for packages, look on packages, also look here to see if you can find any third-party code. You can also add any version control system like any GitHub repo, any Bitbucket repository. It doesn't even have to be a git. Any repository that has code that you want to use as a library, you can add it to your repositories array with type VCS for version control system. Doing this, if you have private packages, private repositories that you want to use for your projects, you can add it here. There's more advanced tips on getcomposer.org on how to do private repositories and add your hash key or your keys to access it and whatnot. But this way you can just link to any project and include it without having to download the code manually. Once you have packages that or repositories where you wanna look for packages, it's time to use composer require. This is the command that will tell composer my project requires this library. My project requires this third-party code for it to work. And when you run composer require, it's gonna touch three things, the composer.json file, the composer.lock file, and the vendor directory. Now, the require command can be run one of three ways. If you just run composer require, that's gonna bring up an interactive search in your terminal to help you find packages based on a keyword. If you run composer require with a vendor package name, it's gonna search all your repositories for something that matches that package name and then get the latest version. And if you run composer require with a package name and a version constraint, which I'll get into in a little bit, it's gonna get that explicit version of that package for your project. So let's try the live internet again. If I run composer require, it's gonna say, hey, search for a package. Tell me a package you wanna look for. Let's say log, right? Having logging on your packages or in your projects is a really good thing. It's gonna go, in this case, it's only gonna look at packages. It's gonna find any projects that have the keyword log in it. And then it's gonna return an array of those. All right, this is boring again. So it's gonna search, and then it's gonna pull up a list that it found, and then it's gonna give you a chance to say, which from this list do you wanna use? Give me the number. Did it show up yet? Man, that's really slow. All right. And once you select it, then it's gonna go back to packages or the repository found that package, get the additional information about that package, such as the versioning, find the latest version, download it and download any requirements that package has. So you see here in this recording that I select monologue, I skip the version constraints, it downloads version 1.23, and then it downloads monologue and a library requires PSR log. Now, one of the things you also notice here in the fourth bucket I have, composer.json has been updated. What composer does when it downloads a package, first it updates your composer.json file with that package information, which I'll show in a moment. Bump, bump. All right. And then it also at the bottom it says writing lock files. The lock file is the composer.lock. This is how composer keeps track of all your packages. It has a bunch of information about all the packages you've installed. For example, with the monologue package. It has this packages array, it says I've installed monologue, I've installed this exact version, 1.23.0. It has source information like the git repository, it pulled it from any requirements this package has. So this package requires PHP version 5.3.0 and it requires that PSR log package version 1.0 or higher. So when composer installs one, it's gonna check my system to make sure I have the right version of PHP and it's going to download this third-party library, PSR log, and add that to my vendor directory. Now know about the lock file as you do not edit it. Think of it as something you cannot touch. It's generated by composer for composer. It's not meant for human consumption. Look at it all you want. Peruse, window shop, but don't edit it. If you do, then you're gonna screw up composer and it's easy enough to start over with composer but you don't wanna do that. Now when composer downloads packages or package dependencies, third-party code, it puts it in the vendor directory and the way it organizes the vendor directory is based on vendor name and then package name. So for example, in the vendor directory, it would have a composer directory for itself. It has monologue because we downloaded monologue and in monologue vendor, it has the monologue package. Inside that directory, you would have all that PHP code that that package has. And you see it also has the PSR directory and inside that has the log directory. The more packages I download, when I look in vendor, the bigger vendor's gonna get. This is where all my third-party code goes so I don't have to worry about it. Which means you don't commit it to your repository. The reason why you don't commit vendor to your repository is because again, it's code you don't control, code you don't own. You don't wanna have it in your repo because then you're maintaining it. What you wanna do instead is in all your teams, environments, you have them run composer install, which we're gonna get to in the next section. And on your environments, like your dev or stage, you wanna try to generate what are known as build artifacts that will run composer install for you and download all that code. But keep it up, your repo, the only thing you want in your repo is the code you control. So now, we can run composer require with a package name. Let's say we wanna download PHP unit. I give it the vendor and the package name PHP unit. Composer finds the latest version of that on packages. Downloads it and you see it's downloaded a whole bunch of other packages that PHP unit requires. Let me get into what just happened here. So I ran composer require PHP unit. It went to packages, it found information about PHP unit and it got version 5.7, which is the latest version. It updated my composer.json file with PHP unit information in that version constraint. Then it downloaded a whole bunch of packages in my vendor directory. So it downloaded PHP unit, but it looked at PHP units, composer.json file, downloaded all the requirements it had, any requirements they have, downloads all those. Then there's actually this interesting thing where packages in composer can say, hey, you might wanna think about installing these other packages, they're not required, but they'll help you out. So it provides suggestions in command line to say install these other packages. And then finally, it writes the lock file. It updates the composer.lock with all the explicit versions of the packages that downloaded. The third way to run composer require is with the package name and a version constraint. Now, versions in composer are comparable to tags in Git. Actually, they're very one-to-one related. So if you say explicitly, I wanna download version 1.0.1 of this package, you're telling composer, look at the repository for this package, find me the Git branch that matches this number. You can have a V before composer will figure that out. And it gets that exact version. But version constraints can be arranges. So you can say, I want a version of this package that is at least version 1.0, but it's less than version 2.0. I don't wanna break any of my functionality with a major update. So this command here, greater than or equal to 1.0, the space is equal to an and statement. So greater than and equal to 1.0 and less than version 2.0. We'll tell composer for that package, find me the latest version that matches that constraint. We can use a star operator, it's a wild card. So I can say, I want a version of this package, the latest version that matches the constraint of version 1.0.1. So I only want patch updates. This follows semantic versioning, which is major, minor patch that Drupal follows as well. So this will give me anything that matches version 1.0, point whatever the highest number is. You can also use a tilde, which will signify to composer, give me the version that matches below the next major release. So this tilde is actually equal to that version constraint, the second one I listed, greater than or equal to 1.0, less than 2.0. So this is a shorthand way to write it. And you can use a stability flag if you want to get things that are not stable code. So if your composer.json file doesn't list a stability requirement, composer's gonna assume you only want stable working code. Sometimes that won't work for specific packages. In Drupal 8, this is true because a lot of modules are still in beta and alpha. So you may have to add a stability flag and say, look, I know I told you I only want stable code, but for this package, I want an exception. Give me the dev version for 2.0.dev for this package. So this may look like this in your command line. You write composer require, let's say we want B-hat because we like to do all our testing. And we want version 3.3.star. I'm gonna say no suggest here just to hide some output in the demo. So what this is gonna do is composer is going to look at packages, find me a version of B-hat that matches this constraint. So basically anything that's lower than 3.4. And then it's gonna download B-hat and all its dependencies as well. So what happened here is it didn't even tell me what version is gonna install because I told it the version. So the first line was I've updated your composer.json file with that package and that version constraint. We'll look at the composer.json in a moment. Installed all the libraries or all the third-party code that I need to run B-hat and then updated my lock and vendor directory. So now my composer.json looks like this. We have our monologue package which is specific version 1.20.0. PHP unit was 5.7. And then B-hat has that version constraint with a star 3.3.star. So this is great. I have my packages installed and downloaded. Composer is maintaining the versions for me, maintaining their dependencies. I don't have to worry about any of that. I can write my fun code. Now, if you're running the composer require command on your machine, that's all you need to do because it's gonna download the code locally. But again, you don't commit your vendor directory so how do your other team members get that third-party code to work with it? This is where the composer install command comes into play. So the composer install command works with your composer.lock file and your vendor directory. When you run composer install, it's going to go and download all that third-party code for you. So if you've set up the project and then you give it to your team member, they get your git repository, they just have to write composer install in their terminal and they get all their code downloaded. Now, your composer.lock file, you should commit it to your git repo but you don't have to. If you don't, what's gonna happen? When you run composer install, composer's gonna look at your composer.json file and use your version constraints to download the packages. What this can lead to is depending when people run that command, they can get different versions depending on your version constraints. If you have a .star, someone can have version 3.3.2 while you have 3.3.1. If you have your lock file, your lock file explicitly states what version to download. It's always major, minor, patched, 3.3.1. If you have your lock file, everyone who runs composer install is gonna get that version. So I recommend you add your composer.lock file to your repository so that you know everyone in your team, every environment you run your project on is gonna have the same exact versions of code you don't control. So when you run composer install, it's gonna look at your lock file and it's going to then download. It's gonna go to your repositories. It's gonna download all those packages and it's gonna install all of them and all their dependencies and you're good to go. You're ready to start running. So composer install looks at what repositories you're depending on. Downloads them all from the lock file, adds them all to your vendor directory, updates the lock file if it doesn't exist. So that's great. So composer init creates your composer.json file. Composer requires how you tell it what packages you want. Composer install is how you get everyone else on your team to have those packages. What happens when there's an update? Well, instead of having to manually have to update a third-party piece of code, even if it's a dependency of a dependency, you can have composer do it for you with your composer.update file, or command, sorry. So composer update will update your composer.json, your composer lock in your vendor directory. It can be run one of two ways. Composer update without any other parameters will look in your composer.json file for all your require and all your dev require packages. It's gonna use the version and trace to find the latest version of all those packages and then it's gonna go ahead and download them. It's gonna upgrade to the latest version if it doesn't have it. Remove the old code, replace with new code. If you run it with a vendor package name, it's only gonna update that specific package. For example, composer update Drupal core. Will only update Drupal core in its dependencies. It won't update any of your third-party modules. So for example, if we run composer update for our B-hat package, so we say B-hat, B-hat, it's gonna use our version constraints in our composer.json to find out if there's latest version from packages in this case. It's gonna update it to version 3.4, and then it's gonna update our lock file and it's gonna update our vendor directory with the latest version of that code and any dependencies it may have. So we see here, it updated from 3.1 to 4.3. But if you run composer, just update on its own with no other commands, it's going to find all your packages that need to be updated and update them all. In this case, monologue had to be updated from 1.20 to 1.23. So you can update your packages pretty simply by running composer update. Following your version constraints, composer's gonna update them. What happens if you wanna remove a package? I find this happens to me a lot when I am starting a new project, I'm building it and I'm testing modules, for example. I use composer in some of my modules, running composer install, Drupal slash path auto. And if it seems like actually I don't need that project, that module in my project anymore, you can use composer remove to get rid of it and get rid of any third party code that it required. So you don't have to manually do that. Composer remove command is gonna update your .json file, your .loc file in your vendor directory. So for example, suppose we wanna remove the PHP unit library from our project. You shouldn't do this, you should keep your unit tests. But it's gonna remove PHP unit, it's gonna look at all the dependencies that PHP unit has, cross check them against all my other third party code and get rid of any of the ones that aren't dependencies of another package. So it's gonna remove a whole bunch of things from my vendor directory for me so I don't have to worry about it. So when you type composer remove package and that's the only way to run composer remove is with a package name. It's gonna get information about that package, find its dependencies, check them in your vendor directory, get rid of them if they're not cross dependent for anything else, delete all that code from your repository, remove it from your .json file and remove it from the .loc file. So if you run composer install, downloads your vendor directories, composer update, update some, composer remove for packages you don't need, now what do you do? Now you do everything else. Everything that you need to do on your project and you don't wanna worry about third party code. But the question is, all right, I have all the third party code, I don't know much about, because composer is doing it for me, how do I use it? I'm not allowed to touch the vendor directory, I'm not allowed to touch the .loc file, how can I use PHP unit? How can I use the hat test? How can I use these modules? Well, composer, every time it downloads a package, it updates an autoload.php file, which uses PSR4 autoloading to help you load that class file in those objects without having to know exactly where they are. So all you have to do in your PHP code is you make a require statement to the composer autoload.php file. Now here, for example, this PHP file is in my project route or my web route. So I go a directory above that because everything composer is above my web route. I go to vendor and then autoload.php that composer generated for me. And from here, I can start just calling classes and instantiating objects in composer because the autoload file has handled where that's located, how to load those files. I don't have to know it. I don't have to put paths anywhere in my code. So I can do the autoloader, then I call monologue and create a logging tool. That's great for me. I don't have to know anything about this third-party code except that the autoloader is there and then I installed it with composer. So to recap, composer manages project dependencies for you. It saves you time, your developers' time, your project time so that you can focus on what's important and what differentiates your product is the code that you control, the code that you have to write and maintain. It takes out maintaining those third-party libraries that you have no control over and that you shouldn't add to your repository. You can install composer locally by keeping composer.far that you download running the composer setup in your project directory or globally by moving that to a directory that's accessible by your path. There's benefits and caveats to that. It's to your team's discretion what you wanna do. Composer is composed of three main parts. Composer.json, which has the project and dependency information for your project. Composer.loc, which has the specifics of all your dependencies that composer uses to maintain them. And your vendor directory, which holds all that third-party code, which you do not add to your Git repository. Then your basic commands, composer init, helps you generate that composer.json file. Require, helps you find packages and adds them to your project. Install, allows your team members to download that third-party code. Update, updates your packages to a version that matches your version constraints. And then remove, gets rid of any packages you no longer want and their dependencies. And then you use the autoload file created by composer to load those dependencies into your projects so that you can instantiate them. So I have a couple of resources for everybody here. The first link, bit.ly slash decon18 composer, this is an annotated version of this presentation since you can't hear my lovely raspy voice. You can watch it and peruse through it and read all the comments and see all the code I ran through. Getcomposer.org is the place for composer. They have tons of documentation to get you going further than these basics. I recommend reading their documentation, it's really helpful. Packages.org is a place to find composer packages, PHP packages. You can access it from the web and do a search there or you can use it from your command line. Now that everyone here knows the basics, you should be able to start going with composer on any PHP project, but I assume some of you want to know the more difficulties that have to do with composer and Drupal because it gets a little more complex. There's a great session tomorrow. It's two hours long. It's how to build a Drupal site with composer and keep all of your hair by Matthew Grasmick and Jeff Geerling. That's tomorrow at from 345 to 6pm in room 103B. Everyone here has the tools they need now to be prepared to go into that session and learn the more advanced topics of what you need to do to manage Drupal projects with composer. So I recommend you check it out. Both these people are really smart and I think you'll get a lot away from it. You can also start using your composer skills if you're here on Friday and join us for the sprints. We use composer in Drupal. You don't have to, but it's a great tool to speed up your development and you can help out with the sprints that way. If you have any questions or feedback for this presentation, for myself, I greatly appreciate it. I require it. If I was composer, I'd say I require feedback. So please, if you have any feedback, let me know. I'm here for the rest of the conference. Happy to chat. You can find me on Twitter at MikeMiles86. You can check out my podcast, which just released a new episode on leadership a half hour ago as I was magically here presenting to you all. Thank you, automation. With that, that's the end of the presentation. I have time for questions, so I'll put up the resources link and if you have a question, please raise your hand. After applause. I saw a question here. Yes. The question was, how do you update composer? Great question. Composer itself has an update command. Let me see if I can list it here. Oh, composer. You type composer, it will list all the commands you have available. And I believe there's a self update command. Do I scroll past it? Self update, up at the top here. So if you write composer self update, that'll update your composer.far file to the latest version of composer. Great question. I should have covered that, for sure. So yeah, self update. Composer self update would be the command. Yes. The question was, is there a tool that can generate your composer.json file from existing sites? I think there is. I know, especially in Drupal, there's a drush command that will help you do that. I don't know what the command is off top of my head, but I do know one exists. For other projects, I'm not sure if there is one. I know there is at least one GUI tool for composer. I also don't know the name of that on top of my head, fortunately, but there should be some. So at least drush has you covered. In the back there. Can you transfer the installer profile to other team members? Yes, you can. So the great thing with composer, what you want to add to your repository is your .json file and your .loc file. With that, anytime someone runs composer install, they're getting the install from the .loc file, but that means anyone in your team can run composer update. Anyone in your team can assume command because they have .json file, which is like how you interface with composer. So yeah, you don't have to transfer anything. Anybody can do it. Did I answer your question? Great, in the back there. My argument would be that the composer documentation says to follow their guide. Like I know you can install composer with like Homebrew on Mac or with Appget. I don't know if there's a benefit or not to doing it that way. I will say using the composer commands here, then you're checking the hash value to make sure that you're getting exactly what you want. So there's a little security there, but whatever works for you. I mean, you can also use like Wget to just get composer if you wanted to, but I'd recommend following their guides. Is it typical to check in composer.loc? Yes, it is, and the reason for that is because if you don't, then any time you run composer install is going to read from your composer.json file, and people are gonna end up having different versions based on your various constraints. So unless in composer.json, you say explicit package versions like x.x.x, 1.0.1, then people are gonna have different versions of packages, they're gonna have different dependencies, and that could you, again, it could be like, well, it works on my machine, I don't know why it doesn't work on the server when we installed it a year ago. So if you keep your lock file in there, the lock file has the specific versions. So I'd recommend it in the back. So the question was in terms of automation and running scripts to have it run install and update, should you do both? I would recommend just install and you have a human run update because you want, if you run update, again, your environments are gonna be updating packages to a different version that then your team members may not be using because it's gonna update the lock file and you only want your environments to be using what you tell it to use. So only run update locally, ideally have one person do that. Like I like to do it either right before release or right after release to update and then only have your environments run the install. Yes. Yeah, so the question was in terms of when do you turn it on and off again with Composer by deleting your vendor directory and your lock file? I would say at any time you can delete your vendor directory, it doesn't matter because then as soon as you run Composer install, it's gonna recreate it. For the lock file, that's a tricky question. I would say if I delete it when I know I wanna like update or change the version constraint, I tend to just delete it if I wanna update everything. Cause the problem is once you delete it, again, when you run Composer install, people are gonna have different versions or you're gonna have a different version than everyone. Unless you tell everyone, delete your lock file. So I would only delete my lock file if someone accidentally edited it and you're like, well Composer's not working at all, I'm not getting in the code. Then you're like, all right, let's see what happens when we get rid of it because your .json file does have all the information you need to recreate the project. Had the internet been good enough, you would have seen me delete the lock file and the vendor directory like four times during this talk. But everyone here was using their computers during my presentation. So, no, everyone here is great. Any other questions? No, oh yes, in the back. If you, the question was, if you run Composer update on a specific package, can you tell it a version to update to? I don't think so, I think what it will do is follow your version constraints. So if you're careful with how you limit, how you list out your constraints, then you should be okay when you run Composer update. So example, if your constraint is a specific version, 1.0.1, and you run Composer update on a package, it's not gonna do anything. Because it'd be like, well, it's 1.1. But if you say 1.0.star, you run Composer update, it's gonna do 1.0.4.5, whatever the latest version is. So instead you'd wanna do Composer remove and close or require if you wanna give it a specific different version constraint. Correct, if you run Composer update and it does update packages, it's gonna update your lock file because it's getting a different version of those packages, which it keeps listed in that lock file. So if you're doing that in your Git repository, if you run Composer update, it does update packages, and you go to make a commit, you're gonna see that your .lock file has changed, and you're gonna commit those changes and everyone in your team's gonna pull them in and then they run Composer install and it's gonna see, oh, we have to update. Good question, yes. So the question was, Composer works great for Drupal 8? How do you integrate it to an existing Drupal 7 project? I can hand you off and say, go to this education tomorrow. Based on my knowledge, there's a bunch of setup you have to do. Even though Composer works great with Drupal 8, there's a lot of subtleties that you have to get in place. One of the advanced things you can do in that you'll learn tomorrow, I'm sure, is you can tell Composer, when you install a package of this type, install it in a certain directory instead of vendor. This is a great way to handle modules. You can say, install your modules and decor, contrib. So for Drupal 7, I assume you'd have to set up something similar and then you can still pull your modules in and just make sure the path directories is correct where they're going, where your themes are going. Beyond that, I think it should work pretty well, but I haven't tried it. Yes, ooh, is there any way to tell if there's any packages you have that are no longer being used? I think there is a command that, I'm reading live here, I should have done it. Outdated will show you the version to see if your package is outdated. I know if you do Composer show, it'll show information about that package or info. I don't know if there's one that will say, oh, thank you, Timer. I don't know if there's one that will explicitly say, hey, these packages aren't being used anymore, you should get rid of them. But if you're using Composer to manage all your dependencies, you shouldn't have any abandoned ones left. So if you use Composer to remove, it's gonna get rid of any dependencies that aren't cross dependent. So I don't know how you would end up with, what would abandon dependencies? Good question though, that'd be helpful. Any more questions or another round of applause? Either way works for me. Oh, and I have stickers too, if anyone wants stickers. Always forget to mention that. Yes, I thought for recorded demos, you have to have that. So those are in the annotated versions, you'll find those are there. Hi, I love the way you said what happened. Thank you. Great. Yes, yes, no problem, happy. Thank you, yeah. For the latest updated? Yeah. Thank you. Oh, how to revert. You would have to, if you want to revert, you would have to do like a Composer to remove. Yeah, a Composer to remove, you would have to revert that package, and then require it with a version of strength that matches the previous version. So if you wanted, say you had updated the version 3.4, but you're like, I want to go back to 3.3. You'd have to say Composer to remove package, then Composer require package 3.3.star, and that'll get that version of it. So you can't say like revert, but you can say, you can tell what version you want. So that would be the way to do it, yeah. That's a good question. Thank you. So if you do Composer to remove, would it know that it responds all the way to it? No, like in Drupal, if you had like a module enabled, you could still run Composer to remove, because it's just gonna delete the code. And I know nothing about Drupal. But then you can speed up the database and it will come to that. Yeah, yeah, so then if you go to your Drupal site, Drupal's gonna be like, oh, there is something wrong here. But yeah, so Composer won't uninstall it for you. It won't know that's uninstalled, it just knows you want to get rid of that third party code. It relines more people. Yes, yes. Just make sure you have rules in place like how to remove packages or modules, like uninstall, then delete the code. So if your web host doesn't allow you to install Composer, for example, on Acquia, say, right? You have to have the vendor directory there. What you can do is in an intermediary step, like you can either use, we use like internally, we use Jenkins, or you can use like CircleCI, like a CI tool that will build that. And you build in your build script to run Composer install, and then you have that reading to check in to your Acquia repository. So like you have like say like a Bitbucket or GitHub repository, it's an intermediary tool, and then your Acquia repository. Once it gets a little complicated, but really you just have to make a commit, you tell the tool that, hey, I made a commit, it runs install, adds that code, and then pushes it up. Once you have it set up, it works awesome. But getting that set up, yeah, it's a little confusing. Or you have a separate repo on your machine that you then add it to, or a separate branch. Yeah. Well, what you can do in Acquia, that's cool. What you can do is they have Acquia Pipelines, which is an automation script that you can say, all right, Pipelines, I push code up, run Composer install, install the vendor directory. Pipelines are an additional kind. And depending on like your cloud subscription it is, it's totally worth it. It's probably over $20,000. I think for some it could be like, between like five to nine grand depending on it, but. Some of them, like if you're like enterprise level, you have it included, you need to like turn it on. It's a simple YAML file where you list here the commands to run when I push code to my repository. Check it out. But like, if you use Bitbucket, Bitbucket has pipelines that you can turn on, GitHub obviously has like Travis or Circle that you can use to handle that for you. Yes. So, one to be honest, I haven't used Windows in years, but I would recommend the EXE. They handle a lot of things for you. The only thing with the EXE is it installs it globally. So if you wanted to pair projects, you can still follow the like the PHP commands to download it. They list all this information on their website. But I think, you know, Windows can be a little trickier, right? So it has to be a little bit easier. So they recommend the .exe. We're moving a lot of stuff in Windows. Okay. I mean, all Composer needs to run is PHP. So like those commands are just PHP commands. So if you can run PHP from terminal command line, then you can follow those. Which had that point, as we've been evolving, so that's all good work. So you have like Bitbucket, which might not have an version of .exe, and WSO. We could, we could use it. Yeah. Yeah. If that's, if that's a composer. Yeah, well, I ended up doing it. Yeah, what it'll do, so when you, when you download, when you get the composer set up and you run that, what it does, it checks PHP settings, checks your PHP version, checks some I and I settings. If they don't, if you don't have what you need to run Composer, it's going to tell you, hey, these things are broken. Fix these. If they work, they'll say, great, I'm going to get the hard file and it works. But it'll tell you, if you're trying to install it, I think five, six, yeah. They listen on the website. It'll tell you, it's homework. It's good to know. Thank you for coming. Appreciate it. Thank you very much. Thank you, thank you for coming, I appreciate it. Sure. We have only two developers. Okay. And when we started with Drupal 8 and Composer, it wasn't even when I pushed up to the gig. The second developer gets a pool and it's all like eating down the file owner's and some conflicts and we were really happy to use it. This for Composer files or for Drupal files? For vendors, right? For vendor, right. So that's where I recommend you don't have your vendor directory in your repo. Yeah, that's the game. Yeah, for Aqua, you can do it. Yeah. Yeah, they're recommended to commit. You're right. And that's causing a lot of problems. Yeah, because that'll cause problems. So that's where. Yeah, I meant to share. Yeah, you can do pipelines or some, even your intermediary build system, then you can let that handle it for you and you don't have to worry about it. It's a little more. You should go to the session tomorrow and show them how to come to that stuff, yeah. Yeah. Thank you so much. Yep.