 How's everybody doing this morning? And thanks for coming on the last day of the con here. I know everyone's probably had a little bit of information overload, maybe a few late nights mixed in there. So thanks for coming and listening to us today. Today, we're going to talk about Composer Workflows for Drupal 8. My name's Kevin Maul. I'm a senior developer at App Innovation Technologies. My Drupal.org name is K. Maul. And my Twitter account is at Kevin J. Maul. And speaking with me today, it's Pablo Fabregat. He's an automation engineer. You see his information here. And today, as I said, we're going to talk about Composer. Now, I'm not a Composer developer. I'm a Drupal developer. And when I started in with Drupal 8, I needed to figure out Composer. I had not really used Composer. I knew what it was, but haven't actively used it. So really what we're going to do today is talk about some of my experiences and how I figured out what it needed to do with Composer and how I figured out how to be using Composer with Drupal 8. So we're going to talk about what is Composer and give a little bit of introduction for people who aren't familiar with it yet. We're going to talk about a few Composer commands. We're going to talk about what are packages, where are packages. If we don't have our code up on a public place, how are we going to add our private code to our Drupal application? Some plugins and enhancements for Composer that are going to make it easier to work with Drupal 8. And then Pablo is going to talk about how he's building our new automated build process to use Composer and work with Drupal 8. Let's talk a little bit about dependency management in Drupal. Who here, the first time they used Drupal, went to Drupal.org, downloaded a zip file, copied it over to your web route, expanded it, and added your modules manually? Anybody here do that? Yeah, that's exactly how I started with Drupal 2. So you didn't quite know it, but you were your dependency management tool. You determine what you needed, what versions of things you needed, you downloaded it, you placed it where it needed to be, and you installed it. Good job. You can add that to your resume in your LinkedIn profile. Then you discovered Drush. All of a sudden, now with a simple command line tool, you can download a module, you can enable a module, you can update a module. Things are great. Drush is fantastic. Things just got so much better. From there, you discovered that you could use Drushmake files. Now, instead of running a command to download all your modules individually every time you need to do it, you could specify all your dependencies in a single file. And with one command, Drush will go out and grab everything you need, put it to where it needs to go. So I mean, from where you are to where you started to where you are now, it's just mind blowing. You did everything manually, and now with one command, everything happens for you. So now, instead of you being your dependency management tool, you're using Drush for dependency management. Well, now we're in Drupal 8, right? So we've gotten off the island. We have more than just Drupal modules in our website. We have libraries. We have PHP code that isn't in a Drupal module. So we need a new dependency management tool that is going to handle all of our Drupal dependencies plus all of our non-Drupal dependencies. So here we have Composer. So first thing you need to install Composer, we're not going to really run through that now, but here's a link to the documentation that will help you run through installation of Composer. So what is Composer? So Composer is a tool for dependency management in PHP. It allows you to declare your libraries, your project depends on, and will manage, which is install and update them for you. This is from the Composer documentation. So if it manages your packages, then what's a package? This is a package, but this is not necessarily what we're talking about. So a package within PHP in respects to Composer is really a bit of PHP code that lives under a namespace with a name, and it includes a Composer JSON file. So let's take a look at what a Composer JSON file looks like and see some of the things that are in here that we're going to need to define our package. So I've taken this Composer JSON file from the Symphony YAML library. As you can see, it specifies the name, and the name includes the namespace, which is Symphony. So you're going to use your vendor name or your company name as a unique namespace for your library. And the name of the library is YAML. It also defines which type it is. So this is a type library and describes some metadata about it. You could give it a description, wear a link to your home page so people can check out your documentation. It defines what you require, and we're going to talk about that a little bit more in detail a little bit later on. It's going to tell it where your code lives so it can create an autoload file so that everything's loaded for you automatically. And a few other things here is like minimum stability and an extra section where you can define certain things. So we're going to talk about these sections a little bit more in detail as we go on. So how do you define your dependencies? How do you get things in Composer JSON? You can edit the file manually, which you can do, but you need to make sure that you're writing JSON that's syntactically correct. If you don't, things are going to break and it's not going to work. So Composer has a command line that helps you easily do this and will update your Composer JSON file for you. So if you needed to require a library or a package that you wanted to include, you simply just use Composer Require and define the namespace, the package, and the version. Composer will go out. It will update your Composer JSON file and it will automatically go out and fetch the library and install it in your application. Fantastic, so it's going to install it, but where's it going to get it? We didn't define anything about where this library exists. That's where Packages comes into play. So Packages is a PHP package repository and this is actually the default package Composer repository. So you don't need to add any links or URLs to say, hey, when I ask for this library, go out to this place and get it. It's automatically going to look at Packages. So if you are going to write a piece of code and you want other people to use it, the best practice is to create your package and then submit it to Packages. That way anyone using Composer in any project now has access to the code that you wrote and can pull it into their application. So now who here has custom modules in their Drupal installation? I do. Who has custom modules that for some reason or another you don't really want to put on Drupal.org or in a public domain? All right, so what do you do? Well, Composer gives you the ability to add a repository and say, hey, if this is an in-packagist, then look at this repository. So with this command here, you can tell Composer that you want it to look at your repository here. So this is a config setting. So you write Composer config and specify the options. So let's say I created a module, right? Hello Universe. I took Hello World and I made it so much better that it's now proprietary information. This is the key to my business. And I don't want to put that on a public domain because you're going to steal it and compete with me. So I've got this in a private repo and I'm going to tell Composer about this repo with this command. So I'm going to specify Composer config, repository.name, so the name of your repository. VCS is a type. So you can specify which type Composer use. This essentially just says, this is a version control and then the URL of the repository. Great, so now we can pull in packages anywhere in PHP. We could pull in our custom packages. But what about Drupal modules? What about code that already exists? How do we find that? Well, thankfully, some smart people created Drupal packages. So this is a repository that was created to house all of your Drupal modules. So now, instead of having everything be on packages, you can specify in your Composer JSON file that you require Drupal slash module name and it will automatically go out. It'll pull that module down for you. And there's actually a new endpoint on Drupal.org where the packages are now going to be hosted. And in a Composer buff that we had yesterday, Webflow, who actually created Drupal packages, mentioned that it might be deprecated in favor of using this endpoint over the old packages URL. So going forward, this is the URL that you want to add to your Composer JSON file so that you can pull down your Drupal modules into your project. So who has lots of custom modules in your Drupal application? So great. So in order to add, let's say you have 10 or 15 custom modules in your Drupal application, you'd have to go and add each repository to it. To each website that you're gonna put these custom modules in. Now say you have a bunch of different sites that use these. Say you have 15, 20, 30 sites that all use these same modules. Do you really wanna go and add each repository to every Composer JSON file that you're gonna have? That gets a little bit tedious. Like we're all developers, we're all lazy, we wanna type as few characters as we possibly can. So how do we handle this? Well, there's a solution for that and that solution is Torrent Proxy. So Torrent, which is created by the creator of Composer, is a packages proxy. So not only will it act as a mirror for packages, but you can also add all of your custom repositories to this one Torrent Proxy and then just include the URL to your proxy in the Composer JSON file. So you can just specify one repository and all of the custom modules that you add to that will now be available to you into your application. So here's a little bit of a visualization about how this all works. So Composer is really gonna sit in front of your Drupal site and as you require things and as you install them, it's gonna look in these different places. It's gonna find the packages that you need, wherever they exist, it's gonna pull them down and it's gonna put them into your Drupal website. So fantastic, we've got a new dependency management tool that will handle not only our Drupal code, but also our non-Drupal PHP libraries that we're now much easier to use. So let's talk a little bit about semantic versioning. So semantic versioning is a way of tagging releases for your libraries and your PHP code and it gives developers a little bit more information about what is in your library or how they're able to work with certain versions of your library. So the convention for this is it's a three number release. So you would have a major release, minor release and patch release. So as I said, it gives you a little bit more information about it. So major versions, when you upgrade to a major version, so you say you have a library and you have a 1.0.0 version. You say you wanna completely restructure, re-architect it and you don't wanna support anything in the 1.0 library. So you change everything and you would update your major version. So that's gonna tell people, hey, if you're using 1.0, if you update to 2.0, it could possibly break your site. So you're gonna know that all I want is 1.0 versions of this library because that's all I've tested with. That's all the functionality that I need. So a minor version would be features that you add to your module or to your library that aren't necessarily gonna break your backwards compatibility. So say you wanna add a feature and everything else will still work with your library. Then you can update from 1.0.0 to 1.1.0 and people will know, all right, there's more features in this library now because he's updated the version. But I know I could pull that in, that's safe, shouldn't break my site, great. And then the patch version is, so you're all excited, you put a 1.0 version out there, great. It works fantastic, right? You wrote perfect code. Somebody finds a bug in it, right? How could they possibly be a bug in your code, right? But it happens. So somebody fixes it for you, submits a pull request and you pull it in. When you commit that to your library, then you can update the patch version. So now if you had 1.0.0, now you can have 1.0.1. So that way people will know, hey, this has the same features, but there's been a few bug fixes that have been out that we wanna pull into it. So it gives you a lot more information about as your versions change, it will give you information so developers can understand how they can utilize that within their application, in which versions they can and should be using. So how do we define this in Composer? How do we tell Composer, all right, use this version of my library or use any number of these versions? You can specify an exact version constraint and say, you know what, I want 1.0.2 version of this library. So when you run Composer install, you're always gonna get only this. If you get, say 1.1 comes out and you try to update this, if you specify this in your Composer JSON file, you're still only gonna get 1.0.2. So it's not very flexible, you're not really gonna be able to take advantage of bug fixes that come out in libraries or feature updates that you wanna add. So you can also specify ranges. You can say, give me anything greater than or equal to 1.0. So if there's a 1.1 up there, I can use that, you could pull that down. Not necessarily suggested, because technically if a 2.0 version came out and you went to install it, unless you've tested your code, it could possibly break. So you could say, well, give me anything 1.0, but less than 2.0. So give me any 1.x version of this library, because I know that it's not gonna break any of my code. There's also a dash, which is inclusive. So if you said 1.0-2.0, that's gonna give you any 1.x version, but also 2.0. So you gotta be careful about how you specify these constraints. There's also a wild card. So you could put the wild card on any section of the versioning. So you can write, all right, give me 1.2.x, point star. That's essentially saying, give me any 1.2-minor version of this library, but any patches that are up there will support that. So that's equivalent to saying, give me anything 1.2.0, but less than 1.3. You could put the star on the minor version, which will say, give me any minor version of this. So anything 1.0.0, but less than 2.0, because I know that that could possibly break my site. You could also just put star, and this essentially says, give me anything, and don't do this. Really, don't do this, don't do this, because you will eventually break your site. Somebody will come out with a new major version of this, and you'll update to that version of the library, and it could possibly break all your code. So not suggested. So then there's these next significant release operators. So the tilde is essentially gonna specify that the last number can change. So if I write tilde 1.2.3, then it's gonna give me a minimum of 1.2.3, but it's gonna give me anything up to 1.3.0. If I write tilde 1.3, it's gonna give me any version 1.3.0, but up to 2.0. So this is a much better way to specify it, because you can specify a minimum, and Composer doesn't have to kind of search all of the previous releases. It knows that I'm only gonna have a minimum of 1.3, but I can have up to 2.0. So there's also the carrot. This is similar to the tilde, but this is gonna allow for non-breaking versions. So even though I am specifying all three numbers in the version with a carrot 1.2.3, this is equivalent of saying, give me a minimum of 1.2.3, but give me anything less than 2.0. So it essentially says give me any minor version, because we know that this isn't gonna break our code. So saying carrot 1.2 is equivalent to saying 1.2.0, but less than 2.0. You can also specify stability in constraints. Composer is gonna default to depth, as it's minimum stability, but you can specify this in the versioning and in the command line when you're requiring a package. So you can specify that you'll accept the dev version or you can specify that you only want a stable version. So the minimum stability can be set in your composer JSON file, but each project can override that. So if you say my minimum stability is dev, but this particular package, I wanna make sure I only have a stable version. You can specify the stable on that particular library. So let's take a look at the composer JSON file that Core ships with. So in Drupal Core, it's gonna require multiple symphony libraries, doctrine, guzzle, things like that. So as you can see, Drupal Core uses the tilde 2.8 version of the symphony libraries. So that's gonna say give me anything 2.8, but less than 3.0. So now we know how to kinda define and list and specify which versions we want, but we still need to install and pull them down. So we're gonna talk a little bit about the install and the update command. So this was something that took me a little while to wrap my head around because you would think intuitively that the first time you run this, you're gonna run install. And every subsequent time that you need to do this, you're gonna run update, right? Isn't that how you do it? So you're gonna tag with Drupal, you install it, and then you update it. Well, that's not quite exactly how these commands can be used and what they mean. So let's talk about install. The way I like to think about this is, install is install and it's more like a sync. When you run composer install, composer's gonna go out, fetch all your libraries, gonna look at your composer JSON file, and when it finds a specific version of a library, it's gonna create a composer.lock file, and it's gonna specify exactly which version and which commit it checked out when pulling the library down. So you have an exact record of the exact commit for every library that you have. So install is always going to make sure that you have that version. So if you run install, there's no composer.lock file, it'll look at composer JSON file, look at your constraints for the library, and figure out which version will work best based upon what you stated there and create the composer.lock file. If for some reason a library got lost or removed or something manually, you can run composer.install again. It's gonna see that it has the lock file. It's gonna see which version of that it checked out before, and then it's gonna check what version you have. If it's not the exact same version, it's gonna remove that version and install the exact version that you specified in your lock file. So that's a way that you can kind of sync. So you can actually take a composer JSON file and a composer.lock file into an empty site and run composer.install, and you'll be assured that you get the exact version of every library that's listed in the composer.lock file. Update, on the other hand, is gonna look at the composer JSON file first, and it's going to look at what you have and it's gonna resolve what the best version is based upon your constraints. So if there's a newer version of the library available that matches the constraints that you specified, regardless of what you have, it's gonna pull it down and then update the lock file. So here's a little bit of a visualization about how that works. So composer.install is gonna first look at your composer.lock file. If it doesn't exist, it's gonna act as if it's composer.update. If it does exist, it's gonna just ensure that your library version is that exact version. If you run update, it's gonna look at composer.json first, and if there's a later version that matches your constraints, it'll then pull it down and update your composer.lock file. Another handy little command is create project. So this is the equivalent of doing a git clone and then a composer.install. So it's just a little bit of an easier way to take a project and pull the whole project down and create it. So with composer, it's not just Drupal-specific, so say if we wanna install Laravel. We can just write composer.create project Laravel, Laravel. You specify your project name and the version of Laravel we want. That's gonna check out the repository that contains Laravel's composer.json file, specifying its dependencies, and then run composer.install. So it's a handy little tool for quickly updating and creating projects. So let's recap a little bit here. We know how we wanna use composer to manage our dependencies. We know how to create and list these dependencies. We know how to install them. We know where they're located. We know how to add our custom code and we know how to define our versions and we know which commands to run them with. So great, let's get down to it. How are we gonna use composer with Drupal-8? We'll install Drupal. To make this a bit easier, there is a project out there called drupal-composer-drupal-project. This is essentially a starter kit for using Drupal. This is gonna provide a few things that is gonna help you construct your project root and your web root for Drupal. So it's going to use composer installers. And so essentially this is what's added to the composer.json file. You can specify what paths. So there is now a drupal core has kind of been split out and it's been made into its own project with a type of drupal-core. Module types are drupal-module. Drupal profile, drupal theme, drupal drush, so on. So we can specify where we want these things. So when composer goes out and you say, all right, give me this module, it's gonna see that it's a type of drupal module and say, okay, well rather than putting that in my vendor directory, I'm gonna put that in my web root under modules contrib module name. So you can specify where these things are gonna go. So as I said, there's a few different types of drupal packages that you can define. And you can also use custom installers. So say you work for a bigger organization, you have a lot of custom modules, you put them under your namespace, you may not want them in your contrib folder. So you can just specify that they can go in modules slash your company directory. And then now you have your contrib with all your contrib modules and then you have your vendor, or your company's directory with all your specific modules for that company. Just helps you organize it a little bit better. So if my namespace is KMAL, if I make a package and I could make it a type KMAL module and put it in modules slash KMAL. And all my code is there and organized a little bit better for me. So we could pull in Drupal core, we could pull in Drupal modules, but those aren't the only things that are in a Drupal installation, right? There's your index.php file, there's a few other directories that you need. So we need a way to kind of pull those down as well. So that's where the Drupal scaffold plugin comes in. So this is a plugin that it's going to build the rest of your Drupal web route structure. The plugin defines some scripts that you can define to run post install and post update. So these functions essentially gonna download these files, build these directories and put everything where they need to go for you. So now we've got all of our modules, we've got Drupal core, we've got all the rest of the things that we need and we can install our Drupal site. So for people who are new to this, this may seem really complicated. It used to be so easy, right? You download Drupal, you move it over, you install it, everything's great. Now Drupal is changed and I have to use all this stuff, like how is this easier? Well, it actually is a lot easier once you kind of understand how it works and you know how to use it. So I put a quick demo here to show you how quickly and easily you can use some composer commands to quickly build and install your Drupal site. All right, so this is a Drupal project website. It gives you a create project command, which you can run and I specify my directory. Does some composery things, checks it out, sees that it has a composer JSON file, downloads all your dependencies. So within that it specifies Drupal core and all of the dependencies for Drupal. Downloads all of them and creates your auto load file that is included in your index PHP. So all your classes are now auto loaded. So now I can come over and I see that my project route is created. My web route is actually in a slash web and that's where my Drupal installation is. I can do a just site install and install my site. So great, with a single create composer command and a just site install, I've got a working Drupal 8 site. I didn't have to worry about all that other stuff that starter kit did it all for me. So now I created an awesome Drupal module. I want to add that. It's not in Drupal packages. So I go through and I add my repository to it. And then all I need to do is require my Drupal dot hello universe module. I specify I want a 1.0 version. It's gonna go out, it's gonna find it in my repository, it found it and now it's gonna pull it in. All I need to do is drush enable hello universe. It enables it. I go to my site and bam, here's my hello universe module. So now with three quick simple commands, I'm able to install Drupal and my module. So now here I've just updated my module. I had to add a little bit of an extra feature to it. So I'm gonna commit that feature. I'm gonna push it up to my GitHub. I'm gonna cut a tag for it. This new feature is 1.0.1 or 1.1.0. And because I want this new feature, I'm gonna run composer update, not composer install. It's gonna go in, it's gonna say, all right, well there's a new version of this module that matches the constraint you put in. I'm gonna remove the old one and install the new one. So I go over, I clear my cache and bam, my feature is updated in the module. And so you can kind of see where it seems a little bit complicated at first, but with just a few commands, you can really quickly get up and running with Drupal 8 and any modules or any custom code that you need to pull into your site. So next Pablo's gonna come up and talk about how he's going, how we're kind of working that into our automated build process. Oh, everyone. So we're gonna see two examples about how we put together this, almost everything what Kevin was talking about, how we put together this in an automated process. So we're gonna use two examples. We're gonna create a project and then we are going to make some changes to that project. But before we go into that, let's talk a little bit about the big picture here, the structure that we come up in our teams. So on one side, we have the GitHub repository without with all our code. We want that GitHub repository to play nice with Travis because we want some tests and we have also our Torrent proxy. And we want to deploy all that to one or several Acquia environments. And in the middle we are being helped by this service called iron.io. We don't need to go into that but we're going to go a little bit in a couple of slides. We have a couple of Python scripts that are being helped by some Docker containers as well. And by the way about that Docker part, there's an excellent session that happened on Tuesday which is called ride the whale by socket wench. You should check it out if you're interested in Docker. So let's go there. Let's create a site from scratch. So this script will initialize everything in the first step. We create the placeholder repository with some hooks and a very, very basic composer Jason to say hello to Torrent. And then another hook that we'll integrate with Travis. Then we're gonna install Composer which is not ready yet in our container. We're gonna also install this amazing plugin, Composer plugin which is called Prestissimo which will download all your packages in a parallel way. So it will work super fast after that. We're gonna run the Composer create project command. We're gonna go into that Composer command in detail in a second. After that we're gonna do some cleanup and we're gonna push our changes to GitHub. Now about that Composer create project. We want our project. Let's create our project. We want to create a new project, no interaction at all. We don't want to be asked any questions because that will stop our automated process. Our minimum stability is dev and on our namespace we want any version below 2.0. Between 1.0 below 2.0. We have our path to our project and then the Torrent private repository URL also as well in that command. So let's create the project. Let's do it. We have our project created. Everything's there. Our files are nice and ready to go. So let's send that to Acquia. We're gonna clone, the script is gonna clone our Acquia repository. It will generate some extra files like the settings.php file, Git ignore, HD access rules, which by the way we generate with a Python library called Jinja 2. It's a template library so it makes everything easier to generate those extra files. So we have everything ready to go. Let's sync. We're gonna sync that GitHub repository with the Acquia repository. We're gonna push everything to Acquia so we have our files ready to go. So let's install Drupal. We have our site running. There's site install. Our credentials are ready to go to test the site as well. Beautiful. The site is running. It's in our Acquia environment but that's not all. I want my configuration as well. So all the YAML files, which are being generated by Drush config export are going to be stored in a config directory in our GitHub repository. And about that, there also was a very good session on Tuesday called configuration management theory and practice. You should check that out if you're interested in the whole config management stuff. So we have our configuration exported. It's already in GitHub so everything's ready to go. Our Acquia environment is done. But we want also other environments so let's propagate all that code. We're gonna propagate that code and the database generated through the Acquia environments via the Acquia some Acquia API calls. What we've seen so far, we created the repository, we initialize it, we run Composer create project, we send the changes to Acquia, we run our Drush site install command, we exported our configuration and we replicated the code. So our site is there, it's already running, it's beautiful, that the beautiful triple theme. But now we want to add some changes. So let's change some stuff. We're gonna change the site title. Oh, the video's not playing here, excellent. We can see the config files over in the same, in that config repository, config directory, sorry. So we're gonna change the title, we're gonna change the slogan of the site. We're also gonna change by hand, excuse me, Composer create some file, we're gonna add the Google Analytics module. By the way, you can do this by hand or you can use Composer require and then the module name. So everything is ready to go, we're gonna add the Composer JSON and the config base system site YAML file, we're gonna commit those changes and we're gonna push that. And now we're going to use that service that I mentioned earlier, which is called iron.io, which if you are familiarized with Jenkins, it's kind of similar, the kind of similar concept. It's just help us to execute those scripts with the Docker container. So we add some parameters to let the script know what's going on and we're gonna queue that task and in a couple of minutes the all the changes are going to be deployed and if you go to the site we refresh the site and we're gonna see our new title and new slogan and if you go to the extend section we're gonna see our module ready to go. Now what happened behind that? We clone both GitHub and Acrea repository, we installed that plugin Prestissimo, we run Composer install, we sync everything back to Acrea, we imported the DA configuration and we run thrush cache rebuild because you always clean cache. So the end, thank you. So we covered probably a very lot of information in just a short amount of time. There's obviously a lot more that you can find out about Composer and a lot more ways that you can use Composer to kind of do exactly what you needed to do with your Drupal 8. So if you're interested in learning more you can check out the Composer documentation, I provided some links there. I can provide some more resources and we'll post the slides on the session page for the session here. So now we'll open up for questions if anybody has a question if you could just come up to the microphone here so you'll be on the recording. Hey guys, so we're using Composer as well to manage dependencies in our project and we've had this like, let's say we have a very like big legacy project that has 120 patches and yeah, that happens with Drupal 7 and Drupal 8 even more I guess but no legacy projects yet. So we're kind of looking at how is the best way to combine the Composer update in Composer install and when to decide to do the Composer update and whether to do this on the full stack at some point in time, every, I don't know, release or something or like do minor updates just Composer update package name if you want to update something. So yeah, kind of we are specifying the strict versions right now because we have patches that only apply to that version probably. So I'm kind of interested how you guys handle like version names and what kind of version rules you use for your projects. So, well first of all, we didn't really go into it at all but there is a way which I'm assuming you know if you're doing it that you can add patches to Composer there's a plugin for that so it'll apply your patch. So I guess to me it matters whether does that patch get committed and how did you specify your conversion your version constraints from it. So if you specify that you want like say 1.0 of a module or a library and you need to patch that because you found a bug, you created a patch but it didn't get committed to the repo yet then you're gonna use that plugin and Composer will actually apply your patch over that library. But if they commit that patch or they fix the bug on their own and push it up to a version that's really how you know determines how you specify your constraints in the JSON file. If it's just a new patch version and you specify that you would take any patch version of that Composer update would then grab that new version and you wouldn't necessarily need to patch it because now your patch is already there. So you want to specify your versioning so that it's flexible enough to pull in bug fixes and things like that but not so strict that you'd have to update a lot of different files in order to pull that down. So I would say that if it's just a bug fix and they update a minor version if they completely re-architect the module or the library and they update a major version you would have to come in change your constraint to match that version and then pull that down. At the moment I think there's different opinions on what they're having your repository when you use Composer. On the one hand there's the traditional way of just installing your site and putting everything in for example you get a repository. On the other hand there's the people that say you don't want core and contrips and everything you install from Composer in your repository which actually means rebuilding your site on every deploy. What's your experience and opinion on that? So we were just talking about that the other day too and so as of right now it's best practice that you don't want to be committing your vendor file to your repository because now you're bugging down your Git repo with changes to things that you're not really handling or you're not changing yourself. So technically that applies to your contrib folder too. Right now we're still working out the process of exactly how we're gonna do it. Right now all of the modules are in our Git repo but going forward I think that we need to have the discussion about removing those things for that. We're gonna be running the Composer commands on our builds anyways so I think that we're probably gonna lean towards maybe removing those and having Composer manage those dependencies. That's my understanding of what the best practices are kind of going forward but we kind of haven't solidified our exact approach on that. So basically that would mean that you only put into your repository the things that you manage and change yourself. Yeah you need to put your custom code in there if you're not having Composer manage it. Anything Composer's not managing you would put in there. And right now you'd also want to put all the files that Drupal scaffold puts in there like your index.php and all of that you'd want to add. I'm sorry can you kind of like. We are using a similar workflow and we just get to ignore what you don't need. So we are getting to ignore everything apart from the modules and the profiles folder where you normally start your things. So would you get to know file you can do it? Yeah exactly and I mean I'd be interested to hear cause we're working through this process now too it's relatively new to us. So if there are people out there that have opinions or are doing it a certain way then I'd love to talk and hear how you're doing it. So I want to comment about the patches and if the bug was fixed on the dependency then when Composer update tries to apply the patch it will just fail. So you will know that this patch fail you will see that the bug was fixed and you will just remove the patch from the Composer JSON file and then you can move on. My question was about you showed how you can use that service for private repositories, private packages. But I was wondering if there's a service that I could tell it like here's my beatback at the team. Can you please create a packages from that team that all the team could share? Is there anything like that? I mean if I understand your question correctly I think what you would need is Torn Proxy. So if you have any number of 10 or 15 different repos that you're managing on Bitbucket rather than having to add those individually you can add those to your Torn Proxy and then you don't have to put it on Packagist and Torn Proxy is actually run on your server so it's not open to the public. But Torn Proxy is, I saw the site, it's per developer, it's priced per developer, right? So you have 10 people, it's like 70 bucks per month. Isn't there something like I could say here's my Bitbucket repository. The team, they all have credentials to the Bitbucket. Please create packages out of it, is there nothing like that? I mean not to my knowledge, I mean to me the only way that I would know how to do that right now is package using Torn. If anybody has run into that scenario and has any information on that but we haven't run into that. Thank you. I had a question kind of in line with one of the previous questions about having it not committing your contrip files, contrip modules to their main repository. It looked from the demo like on some of your custom modules you have individual repositories for each custom module and you're pulling the updates to those in through Composer. So in your main project repository for the website are you also committing the changes to the custom modules after Composer updates those? I mean anything that's managed by Composer you could technically exclude from that. So like I said as of right now like our modules are in there so we have to kind of work around that a little bit but if you're managing it through Composer technically you can exclude that from it and then when you run your Composer commands if you've set your version constraints correctly and really what you're doing is committing your JSON file and your lock file. So when you're pushing that up to an environment or another developer's pulling that down you're never really gonna run update, you're gonna run install. So if the Composer lock file has a certain commit in it and you pull down that and run Composer install even if you had a different version of that library it's gonna pull that down. Have you ever run into any issues on Acquia when you run Composer update on any of the Acquian environments where it like hoses the site and breaks everything? Well if you rank I mean it's possible if you run Composer update then you could possibly break it because it could go out and grab a version that you didn't develop on and even though technically if you set your version constraints to only update minor versions somebody could have put a bug or something in there that could possibly break your site that you didn't develop with. So it's never really best practice to run update on that if you have an updated lock file. And that's why the difference between running install and running update is kind of important to understand because when you're developing you can say all right I want this new version of library let me just update it and don't pull in and update it then you do all your testing you write all your code around that and then test it and if everything works for that you could commit your lock file then any other environment or any other developer that's using that can pull down that lock file and then run Composer install and know that they got exactly the same version that you used and that you developed with and that you insured didn't break your site. Gotcha, thanks. Do you know if there is any possibility to retrieve the modules directly from the file system instead of using a proxy or something like this? So you're gonna specify you want your module like you have it somewhere else on the file system? I have it at the same place where my Drupal checkout is my installation so I have the profiles and the custom modules on the same checkout, git checkout so I want to retrieve the dependencies directly from there without having to specify any proxy server or something like this. Well, I think each module have a Composer JSON file so I mean the repository has to be specified somewhere so if it's in there, if they specify and you have a comment. Yeah, you can in your Composer JSON you can specify a git repository which can be local, can be just the local path to whatever git repository can use it as a repository where it pulls the like a module or a library from but then you have to for it usually then after for each library that you have locally you have to specify a separate repository in your Composer JSON. Okay, so it's possible for each library? Yeah, I don't know if there's an easier way to just have one entry and that works for all of something and this is just how far I got so far. And then I wanted to ask if not all your stuff is in the repository the git repository and then your deployment you cannot use git as a deployment tool and maybe that's a bad idea anyway but I don't know, but then you have to copy it from somewhere instead when you deploy your stuff and you want to make sure that it's exactly the same version of everything and the constraints in your Composer JSON are not good enough. Well, I mean if you have a Composer lock file you know it's not going to look at Composer JSON file so you know if you run it and that's why you want to run install because it will look at your Composer lock file and say all right it's this version of this I'm going to pull exactly that so something happened where there was a different version in there and you run Composer update it's going to pull that down. But do you have the Composer lock in your repository? The Composer lock file is in the repository, yes. This is just an answer to the question before regarding an alternative to the proxy the torrent proxy. I was googling this and there's an option called stasis status. Thank you. Have you used it? No, the UI and it's free. It's, I'm just going to echo it to the mic it's basically the same there's no UI and it looks like you have to host it yourself but it's free for people that are looking into this. Very excited. Yeah, thank you for showing this. I usually just ask Chad everything I don't know anyways so I'll put his email on here for you. Great, so thanks. So obviously tomorrow we've, there's some sprints going on at triple con so there's a first time sprinter workshop so if you're interested in contributing and haven't had any experience doing so then we can help you out. There's the mentored cord sprint and the general sprints. And also if you could take a moment and then evaluate the session and let us know anything that maybe we can do better to improve talk for next time we do it. So thank you everybody for coming.