 Greetings, hello everyone. I'm here for the composer in Drupal, the past, the present, and the future. I'm Brian Aslet, Mixologic on Drupal.org. I work for the Drupal Association on the engineering team. My breadth of responsibilities include things like packages.drupal.org that composer relies on and some of the build tooling and the Drupal CI system for testing and many other things behind the scenes. I'm here with... I'm Greg Anderson. I'm a Pantheon engineer and I'm involved with projects such as Drush and the composer and core initiative. All right, so what are we covering today? We're going to talk about what the initiative, what we set out to do, and what we are. Cover why we're using composer. What is the, you know, why is Drupal find value in using composer and why are we switching off of what we were doing? What's the composer merge plugin and why it was problematic? Well, I feel like I'm reading some of these slides here. So I'm going to cover like how you should manage a composer managed site in the future now that we've got this all moved into core. And then what the path forward is for sites if you already have a site that is composer managed or a site that is managed using tar balls. And then what's it going to look like in Drupal 9? This is kind of a short list of people that have been involved in the initiative. Myself, Greg, mile 23 has been pretty instrumental in reviewing a lot of patches and providing a lot of patches. Theo Proxima's given us a lot of great reviews and Grasmash, he is the co-maintainer of the composer documentation on Drupal at Org. So he's got a real focus on making sure that what we build people are able to read about it and understand. And then we wouldn't be able to do most of any of this without Webflow, because most of the things that we have taken were proven proof of concepts in the community that we rolled into core. So he built most of those and has kind of paved the way all along the way. So big shout out to him. So the composer in core initiative, who are we, what are we doing? What is this specific initiative about? What's the scope? What were we trying to do? One of the main things was to make Drupal tar balls composer ready. That isn't the sole main thing. Oh, sorry, I'm getting ahead of myself. So our project page for the initiative is, you can find a set, this URL, or the short link up in the upper right hand corner will bring you to direct it to the initiative page, which is a good way to get to what we're working on. There's also a tag in the issue queue just composer initiative, but like two words. So if you find that tag, you'll be able to find all the issues that we're working on, all the things we're trying to do to move forward. So the goals of the composer initiative, we have always had composer as part of Drupal, but we've never had an official document and this is the way you need to do stuff. This is how to build a site using composer. This is the proper way. It's always been, well, you shouldn't be using composer because you're going to need to, however, there's no official way to do it. So it's always been in this weird nebulous space and we're like, we need to fix that. We need to make it so that this is the recommended way since it's the official way. Along the way, we realized that core development has often conflicted with the product itself because the Git repository was always a, like almost like an API, like where the files lived in the Git repository or where the files live on your web server. And those two things don't necessarily need to be tightly coupled like that. This allows us to be able to separate those two things and make core development not so dependent upon, breaking backwards compatibility by moving a file. And the tar balls, we wanted to make those composer ready because right now they're generated out of Git clone. And if we're changing the Git repo to not be the product, we can't use a Git clone anymore. So we wanted to make the tar ball itself composer ready so you can just download a tar ball and start from there. Still would probably prefer that you start with composer create project, but that's a part of that. So in order to do that, we had to stop using the Wikimedia merge plugin. We wanted to add the scaffolding plugin into core and add more composer built support to core, which is including building meta packages that provide safety mechanisms and allow people to have the same versions that core uses for development and things like that. I can interject here. Making Drupal tar balls download, tar balls composer ready has an important side effect and that is that all of the Drush PM code uses the tar balls. So if you do a PM update of your site to 880, then you're gonna be composer ready. All right, and of course, anywhere that we can improve upon the existing stuff that's in contrib or in the community space that as we move it into core we can make it even better than that was part of the goals. So why do we use composer? How many people are like very familiar with composer here? How many people are like, I hate composer. How many of you are the same people? Anyways, oh, sorry. So there's a lot of really good reasons why core is adopted composer. I think the primary one is the fact that we can rely on third party modules or third party code that exists throughout the entire PHP ecosystem and didn't have to be contained with just what Drupal developers have built. And so that allowed core to adopt things like sympathy framework and use that to underpin a lot of what core was doing. And so as we moved along, we realized that this would be good for module maintainers as well. And this would be a great way for module developers to use composer to manage their site. And so we ended up with people who are contrib maintainers saying, oh, we also want to use composer. And then we had site builders that say, and we also want to use composer because a contrib module maintainer wants to be able to have the third party library access as well so they can say, I'm gonna make a contrib module but all it really is is a wrapper for this cool library that stashes things on S3 that somebody else has already built for. So that was the maintainer side of things. And then the site builder side of things is like, well, I wanna use composer to download that module and also get all of its dependencies and also get other Drupal module dependencies. So as you can see here, the old method of installing using tar ball and getting all its libraries, several steps. You have to use Drush to download it, use tar ball to get everything into place and interacting with the file system and hopefully your SSH and things back and forth that the permissions are right. But composer way is just composer require the module. And so that solves a lot of things there. The upgrade is also simplified. You know, we don't have to do any library manipulations just composer update. So symphony, I don't know why this is here. You actually already covered this. So the whole point is that Drupal 8800 wanted to adopt symphonies, symphonies already using composer. There's a whole pile of things with just one step. Drupal could bring all of that in and say, hey, we're gonna do everything for you. And it's gonna be all the same as it was with Drupal 7. But then we had the complication that contrib module said, well, wait, I wanna use this too. So that's where we started to get into this. Right, I'm giving the presentation but I'm moving the slides forward. That's the, so there's also a little bit of history. Like when 8800 came out, there was no packages.drupal.org. People were using composer manager to try and make that happen. Or then Webflow had built a community version of the packages for Drupal modules. And then we decided, well, we wanna be able to make semantic version happen on Drupal.org. So let's figure out a way to make those two things work. And so we built packages.drupal.org around the 8.3 cycle. And the people have been using that and ironing out kinks and that. And then now that we're at the 8.8 cycle, we're like, okay, we really need to fix how composers use for everybody because it's evident that it's growing. Everybody's using it and that's the kind of direction. All right, I'm gonna talk a little bit about the composer merge plugin and the upgrade process as it existed before. We still have the Wikimedia composer merge plugin as part of Drupal 880. And what the Wikimedia merge plugin did in the past is it replaced Drupal Core with the source code was actually inside of the Git repository. So composer merge says, take the contents of this composer JSON file at this path and include it in the root level composer JSON. So the result of this is that you've got your core directory and the things inside of the composer JSON in the core directory are included as part of your project but Drupal Core is not a real composer project. The composer APIs can't find it. It's an illusion maintained by the Wikimedia merge plugin. If you use composer require with the merge plugin it's gonna sort of work. Composer's gonna go ahead and put that module in the right place because we have the composer installers project which will relocate it. But there's still no relationship between the core folder and the rest of the project. If you run composer update when you're using the merge plugin and you're only updating a contrib module this is also going to work. Composer will find the address module, give you the new one, update any of the dependencies in the vendor directory. But if you run Drush PM update when you're using the merge plugin this has a problem because PM update is gonna mass replace your site including the vendor directory. So any of the dependencies that you pulled in from the address module will get overwritten by Drush. So this is historically why composer and Drupal didn't work well together. So in 8.7 you don't have a good way to upgrade by a composer and you didn't have a good way to upgrade by a Drush once you started trying to use composer dependencies. So we just sort of stuck and this is our motivation for revamping things for 8.8.0. So let's talk about what we've changed and what we're doing here. So the idea is that there is a composer template that all projects get started from. We've made a couple of them but we start with two, the legacy and the recommended template. And those templates are your starting point and you'll never need to upgrade those again. They're basically just a here I'm starting my project and it's the starting blocks and then from there you manage your site. And so we put everything, they'll have updates or anything will be changed in the core directory and we use the composer installers plugin alongside the new scaffold plugin to manage the file system layout. And then to build the new tar balls which are not quite working yet because I found that the Drupal org infrastructure has a lot of potential race conditions with different things acting at different times and we didn't want to package something that wasn't some tree split yet. But when it is all being built then it will be built using composer and we'll end up with tar balls that look exactly like they do now except they were built using composer instead of built using a good clone. So the template that I was talking about, the Drupal recommended project, it's going to give you a relocated dog root, right? So we want to have our web assets under our web folder and our vendor folder outside of that so that it's not accessible via the web server so that all of your code was in vendor. And this allows us to, well it's sort of a standard best practice that people have followed and that's what the Drupal composer, Drupal project layout would give you and most people have started from that standpoint or that starting point and move forward. So Drupal recommended project is really the non-opinionated replacement for Drupal composer, Drupal project. And what I mean by opinionated is it comes with things that you're obviously going to want but it's hard for us to roll them into core and say yes, you're just going to get Drosh, you're going to get console, you're going to get these other plugins. So those things are potentially going to be added to this suggests section so that people can see like, oh, I'm starting a Drupal site. These are all things I definitely need for when I'm starting. The legacy project on the other hand is people are still using little tar balls and people have built their sites with everything underneath one folder and we didn't want to force everyone to do a strange upgrade or be in a situation where they couldn't move forward because they didn't have a way to separate their web inventor. So that's what the legacy project template is for. Basically it's for building older tar balls so that we can make sure that people have parity between what they have now and what they'll have in the future. All right, so also in Drupal 8.8.0 we have improved the scaffold process. Now the Drupal scaffold composer plugin was introduced in the third party components and it's something that Drupal Composer Drupal project uses heavily in order to put things into the right place. The old way would cause a download to happen from Drupal.org for every single file on the system and this was really a heavy load for Drupal.org. So the new way to scaffold takes a different tact entirely. We now declare all of our scaffold files inside of Drupal Core in the composer JSON file. There's a little metadata section inside of the extras directory that I'll show you later. And profiles can add or override scaffolding files as can a hosting provider or the Drupal site itself. And the files are copied into place rather than having to download them every time which is going to make the load on Drupal.org a lot better when of course security cache comes out. So in order to enable scaffolding for a profile or some other module, you have to declare it inside of the root level composer JSON file inside of the allowed packages section. Now the reason we do this is it's a little bit surprising in terms of the standard composer module model to have a file copied from one location into your project route. You have to be expecting the project to do this in order for it to actually happen. You wouldn't want to just download some random module and have it change your project route. So by default, Drupal Core is allowed to do this but if you add a profile, you have to specifically whitelist it if you wanted to let it add additional files to your project route. Once a project is enabled, you can declare your scaffold files with a simple mapping. The key is the target location, where the file is going to be placed and the value is the path where it happens to be stored relative to the project that's declaring the scaffold files. So you can see also that we have template substitutions for the project route and the web route because you don't necessarily know at the time you're setting up your project whether the site that is going to be using your project it has a relocated document route or not. So those template substitutions will be replaced with the actual path to the target and everything will get dropped into the right location. Now the fact that we're doing it this way and recopying the scaffold files every time we touch them gives us some additional capabilities. We now have the ability to append to the end of a scaffold file. So if you have a Drupal site and you have custom robot.txt contents that you would like added to your robots text, this has been a problem for Drupal since, well before Drupal 8, it's like, how do you manage your customizations to robot text without having it be overwritten every time you do an upgrade? And now we have a way to do that because the scaffold file has an append operation and you can say that for my robot.txt file I want to append from the contents of this other file that I provide and every single time Drupal is updated this append operation will happen again. So you cleanly get your additions added without having to hack core. You can also remove scaffold files. In this example, some people feel like you have the read me and the change log in your project route and people might find out what version of Drupal you're running which is a concern for people who don't update their sites very often. That's security theater because you can tell from a fingerprint what version you're running pretty easily. But there are other reasons you might want to get rid of these files if there's something you don't want. You can just override it, set it to false and the scaffold plugin will stop managing the file. So the meta packages we touched on this briefly earlier, core itself has a set of dependencies and when we are running core patches all the time we have a specific set of things that composer resolves to that we're testing against but what is the meta package? Okay, so those versions then we are extracting those into a composer meta package is really just a manifest of other packages you want downloaded and installed. And so rather than using a composer lock file which usually is something for a project but it's hard to ship cores lock file and have people rely on it we've actually created a meta package that says here's the exact versions of cores symphony dependencies that you should use if you want to have a tested set of dependencies. And so that's what those meta packages are. And so there's three of them. There's one that is the core basic dependencies there's the core dev dependencies and then there's the core ping dev dependencies and the difference between the two dev ones is one is exact versions and the other one is the actual version ranges but with the core recommended meta package one other advantage you get is that it locks all the dependencies at a specific point in time and so if say upstream twig pushes something out that is not API compatible that suddenly breaks Drupal you're shielded from that update you can keep updating and you're still stuck on that pinned to that one version of twig so that's one of the advantages of the meta packages and so but we have to generate these and make sure that they stay in sync with core and traditionally this has been again webflow building his own Drupal core strict package and Drupal dev dependencies packages and he had a Travis build that would kind of keep up you give or take an hour but sometimes we have a security release and we need that stuff right now and so we wanted to make sure that these meta packages were always up to date so they're actually in core and they're being generated by anytime someone is that the next slide? Yeah, so anytime someone modifies core's dependency tree like if they touch composer JSON or composer lock it's going to regenerate the meta packages and make changes to the core file system in core development so there's a post update hook that does that composer and so these are the three meta packages core recommended core dash dev and core dash dev pinned the latter two are in the process of being renamed to this that issue is almost RTVC not quite but yeah so this and this was all built out of another tool that webflow built called the Drupal package generator so yet another piece of the puzzle that we have pulled in from the community to make this possible. The upshot of this is that when you change composer JSON in a way that modifies the composer lock you'll find the meta package generator will run automatically and you'll have three well one to three extra files that are now modified in your source tree and you just include those in your patch and that way the meta packages are always completely up to date every SHA commit in the Drupal Drupal project is going to have the right meta package. So I'm going to back up real quick because after that gets committed then we have on Drupal.org our packaging systems watching the repo with Jenkins and then running a subtree split that takes every single thing that has a composer JSON in the core repository and creates components and creates the meta packages and also the template files all get subtree split out and so those all exist on packages and on GitHub. Anything with the composer JSON file in the Drupal Drupal repository is going to get sub-split out and it's going to appear on GitHub and in packages. Right, actually that's what the slide's about. Oh yeah, there you go. Yeah, so yeah it's really useful because ideally everything would be split up into just individual packages but Drupal traditionally has had things with projects that contain a bunch of modules and core which can take a whole bunch of functionality but this allows us to have a whole bunch of things in core using the model repo method so that we can change everything all at once but then they're managed as individual little things so end users only need bits and pieces of it. So, and then on the Drupal outer work side of things we are going to be changing our tarball generation script to use composer create project instead of get clone so that these will all be built the same way and using composer. All right, so the slide shows the general layout of the Drupal recommended project. In the traditional third party maintained components we had the aforementioned Drupal core strict and Drupal core dev dependencies and both of these projects in parallel had dependencies that were overlapping and it made it really difficult to run composer update. If you didn't do things exactly right at lockstep then composer would say I can't update this one because this one's in the way and I can't update this one because this one's in the way and you get this multi-page set of messages about dependency conflicts that's really hard to parse. So what we did instead in Drupal 8.8 is we made our meta package Drupal core recommended chain through to Drupal core. So if you use composer to update Drupal core recommended then you're going to get an update of Drupal core at the same time which makes it a lot easier on composer and easier on the user to figure out what's going on. The other change we did is Drupal core dev by default now does not pin to a specific version but instead has the same version constraint range as Drupal Drupal because we figured that this was more useful in terms of having the things you need in order to do your debugging without being hard pinned and it makes the upgrade easier. And this shows how Drupal core is recommended currently a self.version. So Drupal core recommended is going to have tags that parallel all of the Drupal versions and Drupal core is the same way. So self.version lines up but since we're generating this file we have the plan to just actually write the version of Drupal directly into the core recommended meta package. Work the same way though. And here's Drupal core dev. This shows you that it has not specific versions but version ranges and the behatminc and behatminc Selenium two drivers look complicated. These are workarounds for projects that have not have a stable release in three and a half years which causes us some problems but we're doing the best we can so that it doesn't cause problems for you. That's my fault. It's not your fault. One of them is. Wouldn't be anyone's fault if they actually had package stable releases every two years or something. But they don't. The other really neat thing is that we built this cool set of functions but it's gonna make it easier to manage your site but some people actually do get left behind. We're trying to do the Dries train tracks where your train just keeps going down the tracks and you don't have any difficulty in upgrading from one version to another but in practice sometimes even minor releases cause problems for specific sites that are pinned to specific modules that have problems upgrading due to API changes. So if you get stuck on Drupal 8.7 or even 8.6 we've got an out for you. You can still use the new stuff. You just use the same version of the scaffold tool from Drupal 8.8 but our core recommended and our core dev we have back produced those for all of the old versions of Drupal. So you can just include a version of Drupal core recommended for 8.7 or 8.6 and these older versions are kind of magic because instead of chaining directly to Drupal core there's another meta package called scaffold assets and this has all of the scaffold files that appear in Drupal core in version 8.8 but the old versions of Drupal didn't have the asset files so we've made an adapter package that's just silently behind the scenes inserted into your flow so that you can use the new stuff with the old versions of Drupal and this is just what it looks like. It looks exactly the same as Drupal core. It has a composer Jason and it has the file mappings that declare the normal Drupal scaffold files and says where they go in alignment with what Drupal 8.8 is doing. We also have Drupal core dev pin and this is similar to Drupal core strict in that it pins to very exact versions of each dev dependency and we really don't think that any site is going to need this so we're discouraging people from using it. It's there if you somehow discover that you have a need to pin to an exact version of the dependencies that Drupal is using but really we're only intending to use this for the download archived tar generation because we want to have a very high fidelity process to create a tar ball that's exactly the same as what you get from the Drupal Drupal repository. The only tar balls that use this now are current tar balls that you download from Drupal or do not contain the dev dependencies unless it's an actual development version of core than the development things are there so that's basically what this is for. But if you do run Composer install and pull the development dependencies in then you'll get them in the exact same version as you would if you had the Git core. Oh, I am doing this part too. Back forward for existing sites, how do you upgrade? So as I mentioned before, if you run Drift PM update and your site goes to 880 then Drupal core is automatically Composer ready. You can start Composer requiring if you've never used any Contrib modules before then you're already good to go. But if you are using Contrib modules you somehow have to get that list of modules you're using into your Composer JSON file. It is on our roadmap to provide an official Drupal org provided tool for doing this conversion. It's not ready yet but there is a community project Grasmash Composerized Drupal and that will take an existing tar ball based Drupal site and it will convert it to the community Drupal Composer Drupal project with the relocated document route and all of the Composer things involved. So our recommendation for today if you want to get onto a Drupal 880 site managed by Composer and you have a site that's not managed by Composer then you should run this tool and go to the community based version and then you should convert from the Drupal Composer Drupal project layout into the Drupal core. And so how you do that is pretty easy. There are a number of files or projects that the community provides and uses and all you need to do is map those to the new names that we're using in Drupal core. So we're going to change from Drupal Composer Drupal Scapple into Drupal core Composer Scapple and similarly Drupal core becomes Drupal core recommended and you can just remove the Drupal core strict and flip over from using Drupal core Required Dev to Drupal core dev and that's most of it. Then also later on in your Composer JSON file in the Drupal Scapple section, the old version of Drupal Scapple has an initial configuration tag that you don't need anymore so you can optionally just remove it and then the other thing you need to do is set up a locations element that declares where your web route goes and if you want your web route to go somewhere else like if you need doc route for some specific hosting provider then you can change that in your Composer JSON and you don't have to make send links to do any other funny fanciness. So do you have to commit to upgrading or if you're already running Drupal Composer Drupal project you can keep doing that until Drupal 9 and Webflow has already declared that he's not interested in making Drupal 9 versions of these packages so you're going to be obligated to switch at Drupal 9 time. We hope that people will switch before Drupal 9 because as I mentioned, it's a big load on Drupal Org whenever a core release comes out and all of these Drupal Scappals start downloading these files all individually and it's pretty easy to upgrade so hopefully this will happen. This is your section, right? Sure. Yeah, so in Drupal 9, kind of a question of what's the goal, what do we help them do? First of all, right now we've kept all of the kept all the scaffold files, starting with the bottom bullet here, the scaffold files exist in both places because we weren't sure if that was going to break any backwards compatibility if people were expecting file to be there in the tarball in the Git repo. They're there, but they also are duplicated in a scaffold files directory and core. So we have a test to make sure that people don't modify one and not the other. So basically we've literally got copies of stuff in core that are duplicated, so they need to be duplicated. In nine, we've got to remove the original one so that all that is left when you clone a Git repo from core they'll be just a core directory and there won't be anything else or well a composer directory too. Now, the root cusp, not sure if this one is actually the first one. Oh, okay, sorry. So when you clone Drupal core, you're getting a development version of core. You're getting the version that you should be using for writing patches to core, working on contrib modules, doing actual development, but you should not be using that for a site. And so there's stuff in the root composer JSON that's customized for core development and the expectation is that you're not gonna be operating that in place. You're not going to be doing normal site management stuff with a Git clone. You should always be using a composer project to be doing that or a tarball. The reason we do this is like imagine at some point someone wants to change the way scaffolding works and they have to change the way scaffolding works. At the same time, they're changing the files that are being scaffolded. And this allows you to do one patch that modifies the scaffold tool and also modifies Drupal and then they'll be tested by the test bot together. The core composer scaffold plugin is included as a path repository so that when you do start with your Git clone and there's only a core directory and then you do a composer install, it'll find that plugin and then run it because it sees it in that path repo. So it acts as if it were a package that we're already downloading for you. So that's what causes it to kind of unfold all the files into place. Then yeah, there's no vendor directory and Git of course, like so when the composer installed that continues to work. And then like I mentioned before we're gonna be removing all of those scaffold files. Now, there's sort of a future that we talked about for Drupal 9 into Drupal 10 that we were like, well how far down the composer rabbit hole can we go? And a lot of that depends upon how much better we can make it perform. And so we've got like several ideas about I'm sure a lot of you that have been using Composer have spent a lot of time waiting on Composer and there's a lot of reasons for that and I've seen the reasons and I think we don't need any of them. So I think we've got a lot of paths forward to making Composer run not in minutes and not use a gigabyte and a half of memory but to be able to reduce it down to where it's a very quick, very useful thing but we still have some experimentation to do. But once it's there, then we can do stuff like use Composer to power automatic updates and use Composer to manage extensions in general. So like the update manager that's the GUI built into core that would be nice for people to someday be able to install modules that have Composer requirements via that interface. And so eventually it could be where Drupal's entire dependency management layer is replaced with Composer and we don't have to maintain that code anymore. We're completely off the island for things we're doing there. So if you're interested in this come and find us in the spring room we don't have a large enough margin to talk about Composer optimizations here but we've really got some good ideas and I think it's gonna work out. So like in 9.x, the Composer Wikimedia Merge plugin is still sitting there. So there's some people may have maybe are relying on that to do custom modules to have it included in their route. You'll probably need to add that back in. We just want to make sure that it wasn't definitely part of core. So if you need it, the Drupal core is no longer in there because it's a path repository, right? Yeah, so whenever you check out core it's using the version that you've checked out looking at the path repository to figure out which version of core you have. So it's this kind of circular thing with the path repos. And of course there's the scaffold plugin and currently there's another path repo for vendor hardening that makes sure that the vendor directory doesn't have any test files or other things that we don't want in there. So that's sort of a throwback to everything goes under one doc route which you know, if we can get rid of that idea if we can get everybody on board with using a web route and a vendor directory separate from each other then we may be able to get rid of that security issue because. Yeah, so it's vendor hardening only exists if you're using the legacy project. If you use the recommended project with the recommended doc route it's not even in there. And we can go on to questions but first we'll say that there are going to be contribution opportunities. The metric contribution is going to be at 9 a.m. in foyer two. It's going to be a first time contributors workshop at nine o'clock in the Diamond Lounge and general contribution is going to be in foyer two. Hashtag Drupal Contributions and also please provide feedback for the server, the session. Also in the upper right hand corner again we have the short URL to the project page for the composer initiative. If you want to get more involved with what we are doing. Now you can open for questions. Yeah, I have a question there. And move the site support. How have you had that in thought? Kind of how to handle that when you have different several sites using the same code base but they might want to have different version of modules on the sites folders. Like composer optimizations I think that our margin is too small to talk about multi-site with composer. Composer itself does not support the concept of multi-site very well at all. It would be possible to shoehorn the concept of multi-site into composer and there's a big issue in core that I commented on and like if I were to write it this is how I would write it but I have no interest in writing this because it's alien to composer. But if you're interested in that you can come down to the square room area so we can talk about it. Is there any reason composer patches wouldn't work with this? Composer patches does work with this and it's going to be one of our sections we suggested it, it's not included right it's just suggested. Suggested? Yeah. And it's not something we're pulling into core because the community project works exactly the same way that we would make it work so we don't see any motivation for changing it at all right now. You mentioned the part about going from the Drupal Composer project to the new way and it's by replacing some of the packages. How do you do it? Do you do composer remove any composer goodbye or you change the composer JSON and then update and just log? Yeah my suggestion on that slide was to just change your composer JSON and then run update but if you remember the Dries note from yesterday we got together a list of composer commands that you can run three in a row and Ryan mentioned earlier that we're renaming the dev dependencies to core dev instead and so that will allow us to use a wild card and then we should be able to get an upgrade from Drupal 8 to Drupal 9 in a single composer line. But for now just change the composer JSON. Yeah. Well I think we're in our time box with questions and everything about that. Cool. Well hey. Trim if you want to play the composer. Yeah.