Taking Maximum Advantage of Drupal Core's Composer Template

>> SPEAKER:  All right, hey, everybody.  So, um, my name is Mike Anello, and I'm going to be talking about the Drupal, the new Drupal Core, um, recommended project.  So, before we begin, my first few slides are basically, you know, a justification of why we need composer, why composer is so important.  I could go through those slides either light speed, or I can go through them a little bit slower.  So, since we are using Zoom and Zoom does have polling capabilities, if you go to your participants list in Zoom, um, underneath all the names, you'll see a yes/no, a green checkmark and a red X for now, so give me a yes, if you are comfortable with the basics of composer, you understand what a dependency manager is, you know, why it's so important.  You know, I don't need you to have super in‑depth knowledge, I certainly don't, um, but if you understand the basics, give me a yes.  If you don't, then give me a no.  And there's no judgment.  No judgment.  I think we're overwhelming yes.  I see some people putting it in the chat, that's fine as well.  I think I have my answer, you know, because we are, on the poll, we're at 25 to 1 in favor of yes, and in the chat, we are, like, six to one in favor of yes.  So, I'm still going to go through the slides, I'm just not going to go through them as in‑depth as I normally would.  It'll allow us to have more time for some of the demos and the hands‑on stuff that I want to do.  So, I'm going to go ahead and clear out the poll.  

All right, first of all, this is me.  I've been in Drupal community, um, for 14 years, 13 years, I just had my Drupal anniversary, I figured it was 13 or 14 years.  Been doing web development since the late 90s, like when mosaic was coming out, um, pretty much everywhere.  My company, Drupal Easy, I just touched my face once, I should get, like, a zap every time I touch my face, we do training and consulting.  The thing we're perhaps best known for is our long‑form Drupal training program.  It's online, so we got that going for us.  It's a 12‑week program, three half days a week.  We also do, um, client work and contracting work, and you can find out more about all of that at DrupalEasy.com.  The training program I just mentioned is called Drupal Career Online, and I believe we have some alumni in the room.  But yeah, so that's me.  I'm also pretty active in the Drupal community.  I tend to go to a lot of events.  I was going to teach a full day composer basics class at MidCamp, I think that was going to be yesterday, um, and I'm also pretty involved in, um, just, um, some community contribution stuff, both event organizing, community working group, community cultivation grant and stuff like that.  If you want a copy of the slides, they are right here.  I will put this link into the Zoom chat right now.  I have also uploaded them to the MidCamp site, although I will admit I made one small change to the slides today that I haven't re‑uploaded to the MidCamp site, so this will be the absolute latest version of the slides.  

So, let's kind of breeze through what a dependency manager is and why this is so important.  So, for dealing with open source, you know, we want to reuse as much code as possible, and we don't always just want to reuse our own code, but we want to reuse other people's code.  The way the PHP community handles that, for the most part, is they share libraries or classes or packages or dependencies.  For the sake of this discussion, those four nouns are synonyms.  You know, a dependency, a package, a library, a PHP class.  So, the idea is that if we're building a project, my project, some custom PHP project, and it needs to send an e‑mail, or, maybe, it needs to send a fancy e‑mail with attachments and HTML, we could write that all by hand using PHP, or we could go to GitHub or Packagist and say, hmm, I wonder if there's any code already out there that will help me to send fancy e‑mails easier, and you will definitely find packages that do this.  One such package is Swift Mailer.  Well, the authors of Swift Mailer, when they wrote it, you know, they had, you know, one of the things that Swift Mailer does is it validates that, an address is actually an e‑mail address and not malformed.  Well, the Swift Mailer maintainers could have, if they wanted to, written their own e‑mail validator, but they probably went to Packagist and found that there is a PHP class, a very well‑used and well‑maintained and well‑supported class called e‑mail validator.  

Um, so, rather than the Swift Mailer maintainers, um, writing their own, they basically use e‑mail validator, and then, maybe, the e‑mail validator maintainers, you know, use someone else's.  So, this tree of dependencies can get pretty deep, and that's just one component.  You know, if our project needs to read and write YAML, there's a YAML component out there, and it might have dependencies as well.  So, we end up with this fairly complex dependency tree, and one of the things that makes it really complex is the maintainers of all of these other open source projects don't care about your schedule, they don't care about each other's schedule.  Whatever your release schedule is, it's completely independent from Swift Mailer which is completely independent from another.  So, when you're writing your project, in the old days, before composer, you would go to source forge, perhaps, and look and write your code to that API, and if a month from now, if they came out with a new version, maybe, you were paying attention, maybe, you weren't, but the fact is your code works with a particular version of, um, of each dependency that you choose.  

So, when you build a project, it works with particular versions of its dependencies, there's no guarantees that the next version of a dependency, of the YAML component, for example, will still work.  Maybe, the API changes.  So, ideally, there should be a way to lock a particular version of our project with a particular version of each of our dependencies.  So, that's something that composer brings to the table, this idea of locking versions, so that, you know, we don't, we aren't writing to obsolete APIs.  Another potential issue is it's, you know, it can be quite common for multiple dependencies of your project to have the same sub‑dependencies, and one of those two sub‑dependencies require different versions.  Well, if you've got a lot of dependencies and one of these sub‑dependencies is very deep down the tree, that's going to be really difficult for you to spot and diagnose, you just might get some weird PHP that takes you a day and a half to figure out what the heck is going on.  It would be nice if we had a tool to give us a heads‑up that something like that might happen.  So, not only do we want to keep dependency versions locked, but we also want to make sure that as we add additional dependencies, we're not creating version conflicts.  That's challenging.  So, assembling a code base, that includes dependencies and dependencies of dependencies and so on, so forth, down the rabbit hole, making sure that the version numbers, um, are good and they don't conflict, that can be extremely tedious.  

So, those that use Drupal Commerce, I just touched my face again, by the way, so that's two demerits for me, you know, one of the maintainers of Drupal Commerce has this, you know, great line, I saw him talk about composer once, and he basically said we're not dependent, we are not to be trusted to do this job, to keep track of all these dependencies, that's why we have to use composer, right?  We tell composer we need a particular version, you know, the latest version, or, maybe, it's a range of versions, and it takes care of everything else for us.  It goes out, it gets it, it makes sure that it or any of its dependencies are not going to conflict with something we already have, that puts it in the right place, and it makes a record in our project of exactly which version we're using, so that, in the future, if I share the project with someone and they need to get all the dependencies, they will get the exact same versions.  

So, that's why we need composer, because it would be a pain otherwise, and if you've ever looked into Drupal Core's vendor directory, you can see all of the direct dependencies of Drupal Core.  There's, like, three dozen, somewhere around there, and then each of those have dependencies and dependencies and dependencies.  Dare I say, that would almost be an impossible task, for someone to, um, do that manually.  So, the vast majority of you indicated you're already comfortable with composer, so let's just talk about a few commands.  Composer.list, it's something I don't see folks use often, but I always like to look at a list command.  Whenever I install a new command line tool, there's usually a command list that just shows you all of the potential composer commands in this case.  It allows me to kind of wrap my arms around what we're looking at.  So, composer list is a good one.  Obviously, composer help.  Most of us, if you use composer regularly, you know what the require does.  That basically gets a new dependency and does all that version checking and putting stuff in the right place, updating the auto‑load and all that good stuff, and composer update, you know, when, um, a dependency, whether it's a Drupal module or something else, um, when there's a new version, we can update that, and update and require kind of work the same way, they go out, they look for the right version, they make sure dependencies don't conflict, it downloads it, puts it in a predictable place, updates your auto‑loader, it does all that good stuff for us, and if we decide we don't need a dependency anymore, there's always the good ole composer remove.  

Um, composer install is something, um, depending on your developer work flow, maybe you use this a lot, maybe you don't use it a lot, um, composer install basically takes your recipe or your manifest, which is a combination of your composer.JSON file and your composer.lock file, it basically re‑creates all of your dependencies with this one command.  All right, so, I tend to get all kinds of ‑‑ reading question in chat ‑‑ so, that is a loaded question.  I will tell you, I tend to not remove the composer.lock file.  When you remove the composer.lock file, what you're basically doing is doing a composer update on everything, which can be a little bit scary, especially for Drupal sites with lots of modules.  Um, is there a better way?  Probably, but without going in, you know, into the details of exactly what you're seeing, what incompatibility and conflicts you're seeing, it's hard for me to tell you what that better way is.  I can tell you we will talk about some tools, some composer commands that, um, you can use to help get yourself out of sticky situations in a couple minutes.  All right, so let's do a little demo here.  We're going to create a new project here in a second, um, with this new Drupal recommended project template.  

So this replaces, um, the old, well, I guess I'll bring it up the Drupal composer Drupal project template, and this was pretty much the de facto standard for building Drupal 8 sites prior to Drupal 8.8.  It still works, if you built a site, if you started a new site before Drupal 8.8 and you're using composer‑based work flow, you're probably using this, but starting with Drupal 8.8, we got a new template and a template that is actually part of Drupal Core.  This was never an official community project, it was, granted, a project that was managed by community members, but it was never part of Drupal Core.  So, this Drupal recommended project is basically a refactoring and somewhat of a simplification of the Drupal composer Drupal project.  It actually, um, it's a bit more robust, it has a lot better automated tests, and it's a lot, um, better suited for, um, Drupal's future as well.  So, I think I probably already talked about this, but let's, um, yeah.  

So, since November 2015, which when I looked up that date, you know, it's been over four years since Drupal 8 was released, for some reason, I can't believe that in my head, but, um, since about that time, the Drupal composer Drupal project template has been the, quote unquote, best practice.  Last December, Drupal 8.8 was released, and we got the Drupal recommended project template.  That actually exists on GitHub as well, but it's actually part of Drupal Core.  So, what's the differences between the two um, the Drupal, um, recommended project template is a bit simpler, it doesn't include things like Drupal Console and Drush, um, it's a little bit more paired down, it really is just focused on Drupal Core.  They both provide, um, one of the big differences, when it was initially released, I think this may have changed, but the Drupal recommended project has always had what we call pinned dependencies, meaning when you install Drupal 8.8.4, which I think is the version that came out yesterday, um, you're getting the versions of 8.8.4's dependencies that were tested with 8.8.4.  If you go and download 8.8.0, if you install 8.8.0 with the recommended project template, you will actually, you will not get current versions of the dependencies, you will get versions of the dependencies that shift with 8.8.0, and the reason for this is because those are the ones that passed the Drupal test.  

I believe there was two occurrences in the past where, um, dependencies were not pinned, so in, I can't, sorry, when the Drupal composer Drupal project template, um, for a long time, dependencies were not pinned, so they can kind of float ahead before Drupal Core was, and there were at least two occurrences that I can think of where, um, dependencies, um, that were floating ahead actually broke Drupal Core, and that was a bit of a problem.  Okay, so Eric, he's throwing my own words in my face, this is great.  Let's see what I can say to this ‑‑ reading question in chat ‑‑ I don't think, was that me?  Did I say that?  Yes.  Okay.  No, that's right.  Yeah, yeah, because that was, um, yes, so, I can't, I don't want to, it would take me a couple minutes to parse the entire question, um, because the answer depends on exactly how your composer.JSON is setup.  Is it still true, with the exception of swapping in Drupal Core recommended, so ‑‑ reading question in chat ‑‑ yeah, so, I can't answer that without actually seeing your composer, and please don't paste your entire composer.JSON into the chat.  I don't think anybody would like that.  Um, so, if general composer.JSON, I don't know what that means.  Are you talking the GitHub one, the Drupal composer Drupal project, or the recommended project template?  Which template is your site based on?  The recommended project?  I think that all you really need to do to update that is, um, I don't think you need web flow Drupal Core strict, I don't think you, I think your old command is still valid.  I think Tyler's agreeing with me there, so that makes me feel better.  

I think your first command, the composer update Drupal Core recommended Drupal/Core dev with dependencies is correct.  I have two people agreeing with me, so that seems like a good opportunity for me to, um, get out of the conversation.  Leave when I'm right, right?  All right, so, um, quick overview of this new template.  Considered best practice for managing, if you're starting a project today, 8.8 or better, use this one.  Don't use the old Drupal composer Drupal project.  Very robust starting point.  It's guaranteed to be sorted by the community, because it's part of Drupal Core.  It has to pass all of the same gates that the rest of Drupal Core has to pass.  Probably, most important, um, automated tests.  So, actually, while we are going through these slides, I'm going to start the, um, I'm going to start a new install of this, so I'm going to do a composer, create project, Drupal recommended project, and I'm going to put it into a 2020 directory.  All right, so it's composer create project command, this is the template we want to use, Drupal recommended project, and I'm going to put it in a directory called 2020, and this will take a couple minutes, so that's why I wanted to start this while we were talking about something else.  Okay, so, when you use this template, it makes Drupal Core a dependency of our project, which is kind of the way of thinking that the rest of the PHP community works, is, um, all of your code are various dependencies of your project, your project is the top level.  

Nested document by default, it includes an incredibly robust scaffolding tool, much more robust than, um, the one in the Drupal composer Drupal project.  We're actually going to do a demo of how we can tweak that scaffolding tool in a few minutes.  It installs Drupal‑specific project dependencies into the proper directories, and that's all configurable, but by default, it will put contributed modules in the module/contrib directory, and you can tweak all that, if you want.  It automatically, obviously, includes Drupal's public Packagist, so that modules and themes, um, on Drupal.org.  So, live demo, we've already started it, but composer create project, let's see how that one's coming along.  That one's done.  So, I did it earlier, so I had everything loading from cash, so that's all good.  We can see we did get Drupal 8.8.4.  Um, composer dependencies can suggest additional dependencies, so that's what all of these, all of these suggests are just, you know, the author of the validator dependency can put in their composer.JSON suggestions for additional dependencies.  There's some abandoned ones.  Not really sure what to say about that right now.  Auto‑load files, not going to get into that, because we can spend the next 45 minutes talking about that, and then we got the scaffolding plug‑in working here.  

So, what's really nice about this scaffolding program compared to the old scaffolding plug‑in, so, um, the scaffolding files are basically things like our index.PHP, our update.PHP, all of the files outside of the Drupal Core directory, literally the Core directory.  With the old scaffolding tool, with the old project template, all those scaffold files were automatically, were downloaded, so anytime somebody did a composer install or create project, like we're doing, this would be a network operation, and it would basically hit Drupal.org and download each of these files individually, which you can imagine, the more people that use composer, that starts to become drain on Drupal.org servers.  That's a lot of people hitting it.  So, this new scaffolding plug‑in, basically, all the scaffolding files are part of Drupal Core now, they're just hidden away in this directory over here, so all the scaffolding plug‑in is doing is copying those files, so it's getting the index.PHP file from this location and copying it to the web root, so that's one really nice advantage of the new scaffolding plug‑in.  Another new part of this recommended project template is a new dependency that allows, um, you or anybody, basically, to output helpful texts at the end of create a project or install.  So, since we're using the recommended project template, the recommended project template automatically outputs all of this information, you know, just helpful information about Drupal and, um, what some of the next steps are.  If we take a look at the, we'll look at real quick the composer.JSON file.  It's actually not that long.  Yes, Andy, I'm going to show you that in a second.  Well, maybe not a second, a few minutes.  

We have our normal kind of meta data stuff up here.  You know, once you start this project, like I have, my next step would be to come in here and update the name and description.  Um, here is the repository, this basically tells Drupal, or tells composer that in addition to looking at Packagist, also look at the Drupal Packagist for dependencies.  This is how composer knows where all the Drupal modules live.  You know, this is much smaller than the old template, only three dependencies by default, so we have Drupal Core and Core recommended, which gets us our pinned dependencies, the project message stuff, which gets us all of this text, the scaffolding plug‑in, which we're going to dive into in a minute, and then composer installers, which is a handy little tool which basically allows composer to put things that are Drupal modules into a directory other than vendor.  So, not a whole lot going on, um, not a whole lot more going on, and then down here, we see all the texts that the core, that the project message plug‑in output.  So, a little bit more lean.  You know, if you want Drush, then you're going to have to basically do a composer required Drush, and you can get it that way as part of your code base.  A couple extra steps, um, I don't think that's asking a whole lot, I like the fact that the recommended, this new template is, um, a bit more lean and focused.  All right, um, how are we on time?  David, do I have, is it 45 or an hour?

>> SPEAKER:  Well, so, technically, there's nothing after this, so you could just go on for hours, if you wanted.

>> SPEAKER:  All right, we'll go three hours.  Fantastic.  All right, so, I'm going to aim for, like, well, we might go till a quarter of.

>> SPEAKER:  Officially, you have an hour.

>> SPEAKER:  Okay.  Good.  Oh, that's perfect.  All right, so, I don't think I'm going to demo these three, you know, just from the fact that the vast majority of you said you were comfortable with composer.  I just did a require, right, I just added a new dependency, so I told composer, you know, I'm inside the current project, and I told composer I need to require this dependency, and then it did all of the things it does, it goes out, it looks for that dependency, it makes sure that none of its dependencies have conflicts, and it will download it and put it in the right place, and then when that's done, um, well, here it is, getting all of Drush's dependencies, and then it gets the version of Drush, here's all of our suggestions, and then it actually will redo all of our scaffolding files for us.  Let's keep going, and we're going to do some more of this stuff anyway in a moment.

>> SPEAKER:  Excuse me, Michael?

>> SPEAKER:  Yeah?

>> SPEAKER:  There's a question in chat, is there a way to disable specific scaffolding files?

>> SPEAKER:  Yes.  I'm actually going to do a demo of that in a couple minutes.  I actually have a slide about that, and we're going to do it as well.  It's actually pretty easy to do.  I want to talk about this though, because this is something I see trip people up all the time.  So, pay attention to this.  I use, for my local development environment, I generally use D dev, which is a docker‑based tool.  I'm not using D dev yet.  I have composer installed in Mac OS, um, you know, so I'm not planning on using D dev today, I'm just using, um, composer, but what you have to be aware of is that composer's a PHP application, so you need to be aware of what version of PHP you're actually running in.  So, currently, I'm on my Mac, I'm running version 7.1 of PHP.  Now, this is interesting, because, um, the PHP version can act as a version constraint or can act as a constraint for your dependencies.  You know, an example I can show you, um, I believe it's the YAML one.  Yeah, so, the latest version of the symphony YAML dependency requires 7.2.5.  So, if I tried to composer require symphony/YAML, which I'm pretty sure I already have as part of Drupal Core, so I'm not going to do it, but if I tried to do this like that, I would not get the latest version of symphony YAML, because I'm running PHP 7.1.  So, I believe, I've done this before, I would end up with version 4.4.5, which supports 7.1.  Now, that may or may not be a problem for you.  Where it's a problem is if your deployment environment, if your remote environments are all running PHP 7.2, you actually want the later version, right?  You want this version, but your local version of PHP is going to not allow you to install the latest version because you're running PH P 7.1.  

So, what's the solution to that?  Number one, just be aware.  Be aware that wherever you run composer, you want to make sure that at least the minor version of PHP matches everybody else in your remote environments.  That's very important.  Just be aware that this is an issue.  I get around it, because I, you know, I rarely use this composer, I rarely use a composer that's installed on Mac OS.  Um, you know, if you use D dev or you use lambdo or doxal, you probably have a version of composer inside of your container, and so that tends to be what I do.  I will use the version of D dev that's inside of, I'm sorry, the version of composer that's inside of my container, where I have complete control over the version of PHP.  So, just be aware that's an issue.  There is actually, um, a, um, you can add something to your composer.JSON that tells composer, um, ignore the version of PHP in my command line, but assume that this version that I'm specifying in my composer.JSON is the version of PHP that you should be using for assessing, um, dependency versions.  So, if you go to getcomposer.com, I don't know if I have that, yeah, it looks like, um, I'll put it in the chat, it looks like this, but, definitely, look that up in, um, on getcomposer.org.  So, be aware, that's one potential big gotcha.  So, I could do a demo, but I think I'm going to skip that one in lieu of some other ones I think are more interesting, but, basically, what I was going to show you is you can actually add a dependency, I'll show you part of it.  If we look at my composer.JSON again, I can add a requirement here that I'm requiring a specific version of PHP, which basically means that, you know, the project requires PHP 7.2 or better, which would pretty much stop my local composer dead in its tracks from doing anything.  So, that's not a bad thing to do, if you know that your remote environments have to be, you know, 7.2 or better or 7.3 or better, but just be careful.  

All right, here's a demo that, um, you know, I love to do this one, because it's so easy, and I don't think people realize how easy this is.  So, I'm going to demo this, it's not going to take that long, but I have a private repo on GitHub, and what I'm about to show you is good for Git Lab and Bit Bucket and maybe a few others, but I know the process I'm about to show you works for those three services.  So, I've got a bona fide private repo, it's basically got nothing in here, you can't access it, only I can, but I want to add this as a dependency of my project.  So, you know, if I came over here and I just did a composer require ultimike/privaterepo, composer's going to be, I don't know what you're talking about, right?  It's not on Packagist, it's not going to be found, right?  It doesn't know.  So, what you can do in order to, um, utilize a private repo is if you edit your composer.JSON file, you can add it as a new repository in this repository section.  So, we can come here, and the type is going to be VCS for version control system, and the URL, I think I have it in my slide here, do I even need to do this?  There we go, I got it all right here.  Oh, boy, I jumped ahead.  So, you basically add the URL to your private re po as a new repository to your composer.JSON.  I always like to run the composer validate command, because it will tell me if I missed a comma, which I often do.  This is good.  So, my composer.JSON is valid, and, yes, the locked file is not up‑to‑date, because I added something to the JSON that I haven't added up to the lock, but that's going to rectify itself in a second.  

Um, so now, we can do a, the exact same command, and composer's smart enough to say, hey, GitHub credentials are required, and it even gives you the URL that basically says you need a token, and when you give me the token, it's going to be stored here.  So, if we grab this URL, copy, um, brings me right to the right page, select the scopes.  Don't you need a log‑in?  Yes, I do, but you can just use a token, so that's the same idea.  Um, if you need to use a project, the default permissions are fine.  So, I'm going to copy that, and don't worry, I'm going to delete this as soon as this class is over, and now I'm going to paste and hit enter, tokens scored, and, boom, I've got the dependency.  So, it's one of those, like, little things that, um, if you don't know about it, it can kind of be, you know, it's a mystery, oh, I wonder if composer does that, but once you see it work, it's fantastic, because now, think about it, you can start thinking about building, you know, managing code bases in a completely different way.  You can build out modules, you know, one at a time and have private repos for each of your modules in GitHub and then just add them to projects as you need them rather than, you know, committing the actual code for your module to your project.  When I went through this and saw this, this is one of those, like, oh, this is a lightbulb moment for me.  

So, there's that here, if we do an ls‑alvendor/ultimike/privaterepo, you can see it's right there.  Okay, let's keep going.  All right, so this goes, I don't know, I don't want to scroll back in the chat, but someone was asking me about, um, I'm getting conflicts, I'm going to blow in my composer.lock, blow in my vendor, and, hopefully, that'll fix everything.  So, I think the next couple slides are what I normally use, you know, 95 percent of the time to figure out, you know, composer conflict or stuff like that.  The first thing I do is I'm starting to use this a lot more than going to the Drupal update status page.  Well, actually, better yet, I use this, and this basically, you're asking composer, hey, composer, which of my dependencies are outdated?  And the direct one, you know, by passing the direct flag, you're basically asking for dependencies that are in your manifest, so we're not looking for dependencies of dependencies.  So, what I can do here is I'm going to go to, so this is Drupaleasy.com, I just updated it this morning to 8.8.4, so there's no security updates here, but if I do composer outdated dash dash direct on Drupaleasy.com, the code base, it'll take a minute, but you've see that I've got, I'm a little bit behind on Google Analytics, but the nice thing is not only does it tell me the Drupal modules, but it also tells me, you know, the non‑Drupal modules, the other, you know, other dependencies.  

This symphony finder, this is actually a remnant of, um, I used to be using the older template, I've since switched to the newer template, but I forgot to remove this, I actually don't think I even need this anymore, but I tend to use composer outdated direct, and it gives me some good information there.  There's some easy wins I can get with those three, huh?  Look at that, and that one too.  Some easy, easy wins I can get.  So, composer outdated direct, that's a good one.  Ann's asking what causes composer to create the manifest file.  We're working a lot of D8 sites, and some have one, while some don't.  What do you mean about the manifest file?  Are you talking about the composer.lock file or the composer.JSON file?  I am not familiar with composer.manifest.YAML file.  This might be the first time I'm ever seeing that, so I don't know if that exposes a clear blind spot in my knowledge or if that's just something else.  I'd love, if someone else can answer that, you know, I will probably learn something.  Oh, so that's a dependency, so that seems like that file comes from a dependency.  Little bit of cold sweat there for me for a second.  Okay, thank you, Andy, for answering that question.  

All right, so, when you get into trouble, what do you do?  When you are trying to update something and composer is saying no, I'm not going to update that, because there's conflicts, um, I said that this is, you know, until you really start getting comfortable with composer, the knee‑jerk reaction might be what the person earlier said, um, you know, does that mean I should kill my composer.lock file, delete my vendor directory and, you know, just re‑install everything.  I've been doing that less and less.  This calendar year, I can't think of a time that I've done it.  I tend to use the first two commands we see here.  Well, actually, I'm sorry, the second command I see here, and I'll actually add another one here, and that is the composer depends Drupal slash cck, for example, but composer depends, we can do composer depends Drupal slash, I guess I can do core recommended without trimming anything.  Yeah, okay, so this shows me things that depend on this dependency.  So, this tells me Drupal requires Drupal recommended.  Let's try something a little bit deeper.  So, what requires twig?  You know, so, this thing requires this version of twig, Drupal Core requires, you know, better than this, Drupal Core recommended, so this is basically the data that composer uses to figure out which version of twig to install.  So, this is a new one for if you're, you know, if you are getting a conflict, if you're unable to update something, um, and composer's saying I can't update and it's giving you a whole bunch of stuff, um, I would normally use this to figure out, okay, what is requiring twig, and then what are the versioning strands of each.  

This absolutely does not mean, Andy, that I have three versions of twig installed.  Composer does not do that.  Composer installs one version, and it will look at these constraints and find the best version that fits these restraints.  So, basically, because Core recommended pings its dependencies, there's no wiggle room with this one, so this is basically saying, you know, 1.4.1 up to 2.0 or 2.12 up to 3.0, this one's saying 1.38.2 up to 2.0, but this one's saying you will use this version, and luckily, this version fits both of these constraints, and this is kinds of the advantage of pinned dependencies, because this Drupal Core recommended is basically guaranteeing that if you're using this, you're using this, because this version of twig has passed the Drupal test suite for 8.8.4.  So, we want this happening right here.  Is it a huge ordeal?  Um, if it was built well with the old template, no, in my opinion, it's not a huge deal.  Is there a little bit of work involved?  Yeah.  I mean, is it going to take you days?  No.  Is it going to take you an hour or two?  Probably.  There's a couple different ways of doing it, it's kind of outside the scope of this presentation, but it's not a herculean task, as long as your current repository, your current, um, composer.JSON file is in good order.  I routinely do it.  I've routinely done it for clients.  Why not is another great one.  Why not, basically, if you're trying to update something and it's not updating, and if depends doesn't give you the clue that you need, you can use why not.  So, generally, if you're trying to update something and composer complains, says I'm not going to update it because of this wall of text, well, you can ask composer why not.  Why not, you know, update Drupal cck, and it will give you a little bit nicer information.  

Sometimes, it could be a lot of information, but, um, normally, I use a combination of these two things, and I can figure out where that conflict is.  I just learned a really interesting one the other day.  Oh, you know what it was?  It was with, um, the Drupal, it wasn't with rector, I was showing some folks how to upgrade a module from Drupal 7 to Drupal 9, and 1 of the tools, the Drupal upgrader tool, I forget, I have to look at it, but it was interesting, because that required a version of a dependency that was older than the version of the dependency that Drush installed, um, by default.  So, there's a couple ways to get around something like that, and, basically, what we did was we un‑installed Drush, and then we did a composer require for, I believe it was the generator and Drush at the same time, that way composer can look at all of the dependencies and find the version of the dependency that both of them agreed on, and the only reason we were able to do that is because of the data we got, you know, with these two commands, and I think it took us about 10 minutes to solve.  So, there's that.  So, these are definitely two things that will kinds of, once you start using these and you have a win with these, that stuff will be like, hey, oh, I've leveled up.  I showed you validate already, so we're not going to dive into that one.  Okay, um, so, if you need to install a pre‑released version of dependency, composer supports that.  Okay, good night, go wash your hands.  Yeah, so, if you need an alpha, beta, um, or dev version of dependency, you know, there is some task for that.  

One thing to note, that when you use a dev dependency, it's cloned, so any other type of dependency is just a download, but when you get a dev dependency, it's cloned, which means you've got to get repo as part of that dependency.  Um, if you commit your dependencies to your project repository, that can be an issue.  If you aren't committing your dependencies to project repository, it's not an issue.  So, just be aware of that.  There are a few ways to get around it, if you're committing dependencies.  Um, the easiest, most manual way is just manually delete the dot get directory, and later versions of composer are actually a lot more friendly with that.  Thank you for the links.  I assume that is updating templates from the old one to the new one.  Composer patches, this is another kind of lightbulb moment, when you see this one.  So, there is a dependency out there called composer patches, so let's get that one installed, and what this allows you to do, we've all had to patch Core or patch a contribute module or something, what this allows you to do is specify that patch as part of your composer.JSON file and let composer do the patching for you automatically.  It's wonderful.  What we're going to do is I've already got a module and a patch all setup, so I'm going to require, oops, I'm going to do compose as a demo here, composer require Drupal slash the max length module, so I'm going to get that in, and there's a patch, and I'll, you know, I'll open it just so it's on the screen, but I'm not going to dive into what it does, because it's kind of irrelevant, but it's a patch, it's actually been marked as a duplicate, but it still applies, so I'm going to apply it.  Oh, no, memory error.  So, that happens.  I'm just going to re‑run it.  Live demo.  I did this entire session this morning for practice, of course, no memory errors.  I can stop, but then you won't see the scaffolding.  Oh, man.  Anyone know off the top of their head, there's a command to run composer, um, with unlimited memory.  I'll look it up here, so you guys can see me stumbling around the Google.

>> SPEAKER:  Negative 1 is the PHP memory limit.

>> SPEAKER:  All right, so yeah, I can do this, right?  Hopefully, this won't blow up my computer.  So, this will hold, oh, so this will just be for this, um, oh, no, this will actually update my actual composer install.  Oh, no, will it?  Yeah, I don't think so.  All right, well, we'll let this happen, and, hopefully, it'll magically all be fixed.  All right, see if we can get it this time.  Oh, that's just for one room?  Okay.  Thanks, Greg.  Appreciate it.  Oh, okay, I see.  I understand.  Okay, I can do it right here.  Okay, yeah, got it.  So, this is basically allowing me to run this one command with no memory limit.  I see it.  Thank you, Tyler.  I should probably create a text expander for this.  That would be helpful.  Cool.  So now, let's, um, so, we installed max length, um, I believe I already, did I do, um, yeah, and I have composer patches, so now let's edit our composer.JSON file, and this is going to be a little bit of a trickier show, because I'm just going to paste in what we need here, I'm going to put it at the very bottom, I believe it needs to go this level right here, make sure I put a comma there, and we get my paste, copy that, paste that, and I got to get all my one, two, three, and I know I've got a funky character from where I pasted it.  Let's do another composer validate, make sure I didn't miss any.  Okay, so that's good.  So, let me just show that to you.  

So, in the extra section of our composer.JSON, composer patches will now look for a patches, um, key, and you basically specify the dependency that you need to patch, and then the data is basically a description of the patch followed by, I just have to wait for my cursor, followed by the URL to the patch.  So, this patch exists on Drupal.org, um, so you're not going to the issue, you're actually literally putting the URL to the actual patch file right there, and then we can just do a, um, a composer install, and it wasn't very fast, but it happened.  If we look back up here, it re‑installs the dependency, and then it applies the patch.  So, I have Drupal 8 projects that have a dozen patches, you know, maybe one or two for Core and then a bunch of module patches as well, because the level of difficulty to apply patches and to maintain those patches goes way down when you're using this.  So, composer patches, if you're not using it, that's definitely something that will up your game, and I think we've got, um, one more.  Okay, scaffolding files, this is one of my favorites.  So, this new scaffolding plug‑in does a lot of things.  It allows you to remove, um, scaffolding files, append, edit, or even add new scaffolding files.  So, if you host somewhere that has a, you know, a YAML configuration file on its root, you can actually add that, um, file, um, via the scaffolding file.  

So, um, yeah, so let's do a quick demo of removing the read me file.  So, the way this works is, if we look at our project right now, well, let's look at the web drafter, that would be more helpful, I think, we want to basically get rid of this and never see it again.  So, the first thing we're going to do is we're actually going to just remove it.  So, let's delete it, but the next time the scaffolding plug‑in runs, it's just going to show up again.  So, we want to make sure it doesn't show up again.  So, the way to do that is we're going to update our composer.JSON file, and we're going to come on down to, where's my cursor?  There it is.  We're going to come on down to the extra section again, the Drupal scaffold section there, and, so, we're going to add a new section here, so the one that's there by default is location, that basically defines the location of the web root, so I put a comma there, I open up a new one.  Oh, let me, the new one, I have to call it file dash mapping, I knew that looked funny, then we get that.  Let me close that up while I'm here, and basically, what we want to map, remember, we're just copying, or the scaffolding plug‑in, um, is just copying, I can't talk and count at the same time, is just copying scaffolding files from a location in Core to a location in the project root or the web root, so we just want to modify that mapping.  Instead of copying this file, don't copy this file.  

So, what we can do is we can basically say, you know, we do not want to copy the read me.txt file to the web root, so this is like the to colon, and where do we want to get this file from?  We don't.  So, this is basically the destination, this is the source, that's the way I look at it, so we're basically copying nothing to this file.  I'm going to do, so, the next time I do a composer update or composer install, I need something that kicks off the scaffolding plug‑in, or you can just run, um, there's a scaffolding plug‑in command, so you can just run, this basically tells the scaffolding plug‑in to do its thing, and you can see that it has been disabled.  Up here, it's skipped, because we overrode it, and if we do, if we look in our web directory, we don't have a read me anymore.  So, you know, this is really handy, I mean, you can get rid of the install file this way, um, if you don't use web config or whatever, um, I've used it for a client to append, um, you can easily append stuff, so I've appended stuff to robust.txt.  You can actually provide a patch to patch a scaffolding file, um, so it's pretty easy.  Can you use a wildcard for txt files?  I don't believe so, although I saw that Greg was in here earlier, Greg was one of the authors on it, so he could probably answer that.  No wildcards.  Okay, so my guess was right.  Thank you.  Okay, um, yeah, so full documentation on the scaffolding plug‑in.  Again, this is, I think it's one of those things where once you learn how easy it is to mess with it, you're going to start messing with it, because it's pretty darn easy.  

Okay, um, yeah, and I've already talked about this, um, you know, the new, um, recommended project template does not include Drush or Drupal Console, but, yeah, just go ahead and require them, and this is another reason, in my opinion, to use composer outdated, because you will see, and it will kind of pin you to, hey, there's a new release of Drush, do a composer update on Drush.  All right, 4 minutes over, that's not so bad.  So, feedback, please.  I will, I can hang out, um, if anybody has any questions.  I was promised, I'm sorry, Andy, I'm 2 hours shy, or I'm an hour and, um, 55 minutes shy of that.  I don't think I missed any questions in the chat.  If I did, feel free to re‑post them.  Yeah, so, Drupal Console, the last I checked, um, Drupal Console had a, um, a dependency that is incompatible with Drupal 8.8.  I don't know if that's been resolved yet.  I had seen the same thing that you saw.  I want to call you Tom or Terry.  I don't know why.  That's just a guess.  Oh my gosh.  Holy cow.  That's amazing.  Have we met before?  Did I have that knowledge somewhere deep in my brain that accidentally came out of my mouth?

(Laughing.) 

>> SPEAKER:  All right, well, I'm glad, it sounds like, um, a lot of folks got something out of this.  I appreciate your time.  I did want to, you know, I meant to ask, David, I meant to ask you or Amy June before we started, is there anything happening this virtually?

>> SPEAKER:  Yes, and if Amy June is still here, there she is, I will give her the option to un‑mute to promote it.

>> SPEAKER:  So, yes, contribution day is still happening on Saturday, and it's virtual, so now it's a global event.  If you go to the contribution day page on MidCamp, you'll see, it's very much like how you entered the rooms for sessions, each initiative has its own room, and then there's a general contribution space for the people that just want to kind of openly collaborate on different issues and things, and then each of the rooms has a Slack space attached to it too, so if people feel more comfortable chatting, and then one of the rooms is for novice contributors, and there will be a contribution training in the morning, and then in the afternoon, Randy Fay from D dev will help people setup with the quick sprint tools that we use at Drupal Con.  So, yep.

>> SPEAKER:  Awesome.  Awesome.  All right, cool.  All right, well, um, I don't see any questions, so I think I'm done, unless, um, someone wants to start yapping at me, but thank you, everyone.  I appreciate all the kind words especially.