The Laravel Podcast

Matt Stauffer:
Welcome back to the Laravel podcast, Season four. Today we're talking to Jordi Boggiano, the co-creator and co-maintainer of Composer, which is PHP's dependency manager. Stay tuned. All right, welcome back to the Laravel podcast, Season four. Reminder, this season what we're primarily doing is picking one topic every single episode, and focusing on talking about that topic in a way that would be helpful to people who are new to the Laravel community. Hopefully, we're going to go into it and interesting ways where those of you who've been around for a while. We'll also have something to learn, but reminder, this is a target at the folks who are new.

Matt Stauffer:
So two episodes ago, we talked with Taylor about the ethos of Laravel. What is it about, and why do we do Laravel? What makes Laravel different and similar from other frameworks? And then one episode we talked about how to learn Laravel, and how to keep up to date with Laravel. And now, finally, I am ready to talk about technology. And so you would think that the first thing that I would want to talk about when we're talking about technologies, is Laravel. But if you're new to PHP, if you're new to Laravel, what you might not know is that Laravel relies heavily and collaborates heavily with lots of other parts of the PHP ecosystem.

Matt Stauffer:
And most important piece compared to anything else that allows us to work together with other folks is a tool called Composer. So I have invited a guest on, who I actually didn't ask how to pronounce his name. And if you've listened to my podcast for ages, you know that I normally get it right before I say it. But I know your first name is Jordi, and I'm going to ask you to pronounce your last name, who's one of the co-creators of Composer, and I think, the primary maintainer at this point. So could you say hi, keep me from embarrassing myself with your last name, and just tell a little bit about who you are, where you work, and what your relationship to Composer is.

Jordi Boggiano:
Hey. I'm Jordi Boggiano. That would be the last name.

Matt Stauffer:
Boggiano. Okay. I wouldn't have done that bad with it.

Jordi Boggiano:
It's an Italian name. Although, I am from Belgium, and I now live in Switzerland.

Matt Stauffer:
Keeping us guessing.

Jordi Boggiano:
It's all pretty complicated. But anyway, I find myself here in Zurich. Yeah. I've been maintaining Composer now for a little bit over nine years.

Matt Stauffer:
Wow.

Jordi Boggiano:
So that doesn't make anyone younger, but-

Matt Stauffer:
I love it. And right now you're a consultant mainly, right? You do PHP and other stuff?

Jordi Boggiano:
So I've had my own agency for a while, doing little websites and whatnot. And that didn't pan out very well, because selling to customers was pretty difficult. So now, actually, as over five years, I've been working on teamup.com which is a online calendar application. So somewhat like a Google Calendar or something like that, but more geared towards groups. And since, I think it's three and a half, or four years, I've also been working on Packagist that's funding my open-source maintainership for Composer and Packagist.

Matt Stauffer:
Got it. I love it. So the primary thing you would think of yourself as, as an open-source maintainer. And you're using some other things to maybe fund that work.

Jordi Boggiano:
Yeah. In a way.

Matt Stauffer:
I love that.

Jordi Boggiano:
That's a way to put it.

Matt Stauffer:
Okay. Well I love that. And sorry, I thought I had done my decent research, but obviously not.

Jordi Boggiano:
That's fine.

Matt Stauffer:
But my first question that I had for you before anything else was your Twitter handle. So it's S-E-L-D-E-A-K or A-E-K. And I just have to know. I've been seeing you for ages. What is it from?

Jordi Boggiano:
So it's A-E.

Matt Stauffer:
A-E. Okay. Thanks.

Jordi Boggiano:
No, it's fine. It's so common. I get so many people doing typos. It is from a book. It was the character name of some random character in a random fantasy book when I was 15 or something.

Matt Stauffer:
Was it random, or was it like your favorite book at the time?

Jordi Boggiano:
It was a random book.

Matt Stauffer:
You just liked the name and thought, "This is unique." Right?

Jordi Boggiano:
yeah, exactly. And it turned out the unique aspect, it turned out really well, because the name is always available on all the services. I just grab it. The got you is that nobody can spell it.

Matt Stauffer:
Yeah. I finally switched. I had an acronym that I created as an eighth grader, I think. And I finally switched over from the acronym, which is totally unique, but totally difficult to remember, to my first name and my full name. And it's been tough. I finally got MattStauffer.com, so that was a big moment for me. Okay. So what we're talking about today is Composer. And I was about to just go run into it. But my first question is always, if you had to describe this topic to a five-year-old, how would you describe it?

Jordi Boggiano:
I would say these days, probably, I would just describe it the same as I do to random people I meet that are not that into tech, is saying, it's like the App Store. And I guess most five-year-olds just get it.

Matt Stauffer:
Yeah. They get that. So let's take it a step up. Let's say you were talking to an adult who was tech savvy. Let's say they were a JavaScript programmer who knew nothing about PHP. How would you describe Composer to them?

Jordi Boggiano:
All right. So for a JavaScript developer, the simpler answer is it's like NPM, but for PHP. Obviously, there are a few differences there. Whereas NPM can be fairly flexible with the dependency resolution because JavaScript just lets you include libraries many times in different versions, for example, whereas PHP cannot do that. So we need to resolve dependencies in a much stricter way than NPM does. But essentially, it boils down to the same thing. It's like, you give it a list of dependencies, and you say, "Install me this stuff." And it just looks at all the requirements of all the dependencies and tries to find a solution of a dependency set that will actually fulfill all those requirements.

Matt Stauffer:
And like you said, with NPM, you can potentially have multiple versions, which has some benefits. But I've also been bitten by that, a lot of ways.

Jordi Boggiano:
Yeah. It's definitely different.

Matt Stauffer:
Yeah. And with Composer, you get one version of each dependency in each project and that's it.

Jordi Boggiano:
Yup.

Matt Stauffer:
Yup. So Composer is the tool that we use on the command line to pull that in. Could you tell us a little bit about other names we want to think about? I know Packagist is one of them. What are different things or concepts or ideas in the Composer world that we should be thinking about?

Jordi Boggiano:
All right. That's another big distinction to NPM, actually. Just thinking back to NPM, is that with NPM, NPM is the command line tool, NPM is the repository on... Like with a website, it contains all the packages. It's also the company that's behind it, now, that's been gobbled up by GitHub. So that's gone, I guess. So it's all fairly fuzzy and confusing. And so we tried to have different names for different things. And so Composer is really just a command line tool. Packagist is a silly name that came from package archivist.

Matt Stauffer:
I had no idea that was what... It made sense, but I'd never known that was where it came from.

Jordi Boggiano:
And so that's like the package repository, right? It's just archiving all the packages. And so that's the website where you can go find things. I guess that's really the main things you need to know about.

Matt Stauffer:
Well, there's one other thing that I think, and I don't actually know how different this is, but you mentioned the fact that in NPM, it's both the repository and the tool. With Composer, if by default you're pulling all your dependencies from Packagist, but you can also instruct Composer to pull dependencies from other places, which I don't know if that's unique. Is that unique about Composer?

Jordi Boggiano:
I don't think so. But I would say with NPM, you definitely can pull from other sources. I'm not completely aware of how that's set up.

Matt Stauffer:
Yeah. Okay. So it's pretty similar to what you're familiar with, if you've ever dealt with a package.JSON file, Composer.JSON is the same thing. Packagelock.SON is similar to Composer.lock. So there's some basic stuff there. So, this is going to be a little bit obvious for somebody who understands this, but I just wanted to walk through, especially if someone who's listening here, isn't familiar with NPM. There's probably some people listening who aren't JavaScript developers who might be old school PHP developers, who haven't had exposure to Composer before. So I just want to ask a couple of common use case, very simple questions. So what are the most common, a few tasks that people use Composer for?

Jordi Boggiano:
Okay. The main one really, that I can think of, almost the only one, is to install dependencies. You want to depend on this and that open-source libraries. Or even it could be internal libraries which are not open-source. So we can also support private Packages. That's not a problem. And it just glues all of that together. And the main other aspect of this is auto-loading. So every package describes how it should be loaded. And that way, you can just get them with Composer, you include the Composer auto-loader, and when you use a class name, it's just going to go and figure out where there is, and include that file for you. Which, if you remember using PHP like 15 years ago, that was a pain.

Matt Stauffer:
And that's a helpful distinction, because, either, if you remember PHP from back then, or if you're wondering how your classes just show up, because like in JavaScript, you would have to require it or include it. So there's that one line that has to be in your app somewhere that they include vendor/autoload. But Laravel and other frameworks already run that one line for you. So if you're showing up to Composer for the first time, if you define some dependencies and the Composer installed, those dependencies are instantly available in your app anywhere. You don't have to worry about it. So that's one really cool thing about that, in terms of the autoloading.

Jordi Boggiano:
Yep.

Matt Stauffer:
So we talked about Composer.JSON, and it's got a list of all of your dependencies' baselines. We understand there's an object somewhere in Composer.JSON. It's keyed and required. It says, "Here are the things to require." But what other pieces of information are in the Composer.JSON file that you think people might be running across in their early time? Some of the flags or some of the other blocks required to have. Could you talk through a couple of those?

Jordi Boggiano:
All right. So you would have, required, there would be the equivalent of dev dependencies, I think, it's called in NPM. Where you have just tools or libraries you would need in development time, but not in production. So these you can exclude them by running install--no-dev. And they would just be excluded. Whereas, while you got the autoload configuration for your package, you get a whole set of configuration options. I can't really of the most popular ones there, but-

Matt Stauffer:
Minimum-stability is one of the ones I see the most, I think.

Jordi Boggiano:
Minimum-stability is one, and that's actually a good one, of thinking ahead to what's something that people don't really use. Yeah. If I may jump ahead there is-

Matt Stauffer:
Please go ahead. Tell us about it a little bit. So you have two ways to define stability. And I think that's the whole concept of stability, is generally speaking, not well understood. And that's actually thinking to other package managers. There's a massive difference there. Most package managers have just tags. So you push releases. And we, from from the get go, wanted to support branches as well. And that is very convenient, because it means that you can just push to your master branch, and we reflect that as a dev master version. So dev-master, and we just add this 'dev' prefix to indicate that it's a development thing. It's not a tag. A tag is fixed its point in time snapshot of a repository. But a branch is just something that's fluid, and can really change at any time.

Matt Stauffer:
So stability is, by default, we run with minimum-stability of stable, which means that anything that's alpha, beta or dev, will just not be seen at all by Composer. And you can either change that with minimum-stability and that changes it for all the Packages at once, which is like a nuclear bomb of options.

Jordi Boggiano:
Right. With alphas and betas and release candidates that you weren't expecting.

Matt Stauffer:
Yeah.

Jordi Boggiano:
For everything, which might be a little bit much. And so the other option we offer is that you can also add, behind the requirement of any package, you can add '@' and then stability. So @dev or @beta. And that would change the minimum-stability just for that one package.

Matt Stauffer:
Yeah. I don't feel like most people know that. So I'm really glad you're bringing that up. And could I retell it, and then make sure that you tell me that, "Yeah. This is the right way," just so I can rephrase it for folks?

Jordi Boggiano:
Sure.

Matt Stauffer:
So like if you were to imagine in Composer.JSON, you've got this require block, and every single entry in that block.. So it's a JavaScript object, so it's like a key value, key value, key value. And the key is the name of the package. So it's going to be something like Titanco/Tlint. And then on the value side it's going to be your version constraint. So it might see, say caret 1.0, caret 2.0 or whatever. And so, one of the things that Jordi just said was, if instead of doing caret 1.0, you did dev hyphen and then branch name in GitHub, or wherever your source control is, you can load any branch that way.

Matt Stauffer:
So if I'm working on one of our Packages and I want to test it on one of our apps, I'll push up a branch with my name in it. MES slash working on whatever. And so I could load it with dev-MES/whatever, and it would work. But only if my minimum-stability was set right. And so what we normally do in this circumstance as we go add a minimum-stability key to the whole project set to dev. But I love what you just pointed out there, which is when you do that, now all of your Packages are getting the dev versions of the beta and alphas. So instead, what I could do, and tell me if I'm getting this right, is, dev-MES/whatever@dev. And so within the version constraint it's @dev, is that right?

Jordi Boggiano:
Right. So it is right. There's just one little thing is that, if you do explicitly require one specific version like you mentioned, like a dev something, you don't need to add the @ part because we just infer it for that.

Matt Stauffer:
Wow. Okay. So you don't need @dev if it's a dev-branch. But you do need if it's a person?

Jordi Boggiano:
Yeah. But it's just a little optimization we do if you exactly require a version, and we know its a version, that's like an alpha or whatever. Then it's just no point in making you repeat yourself.

Matt Stauffer:
I appreciate you saying that because I actually didn't know that distinction. So I didn't know why it works sometimes and other times. So what he's saying here is that you only need this @dev thing if you're using a tag, if you want to use like a 'get all tags' that... His face says no. Tell me more.

Jordi Boggiano:
It's getting complex. So you only need to @ if you use a version constraint, I would say, like a range constraint. If you use a specific constraint then with another version then it's fine.

Matt Stauffer:
Right. So at tilde 1.0 or a caret 1.0 or something like that. All right, thank you. Yeah. You're 100% right because if you hit a specific tag, 1.0.0, then it would pull that. But if you were to say, "Caret 1.0.0 @dev," then it would give you something that matches that version constraint, and it would allow things that are stable, stability of dev. Like a beta or an alpha. Okay, cool. Thank you. That's what I needed. I'm sorry everybody. We jumped ahead, and I was clueless. We were talking about the different things that are contained in a Composer JSON file. So you mentioned requiring required dev, you mentioned some config options. Are there any other things that you commonly see in a Composer.JSON file?

Jordi Boggiano:
Commonly see.

Matt Stauffer:
Like, I remember one of the things is that there's some metadata at the top, like the name and the description and the tags. Is it Packagist that mainly uses those?

Jordi Boggiano:
Yeah, no. That's a very good point. These are so common that I just-

Matt Stauffer:
It's so common that you don't even think of it. Totally. Yeah.

Jordi Boggiano:
Yeah. So the name and description are only required if you're actually publishing the package. So yes, this would be needed to put it up on Packagist.org. And then all the things, like all the other type of what we call links, which are like dependencies between Packagist, right? So you have required, you have require dev. But you also have replace, and suggest, for example, and conflict. And those are not that common, but I think they're also fairly valuable, because that's the part where we go into this more advanced dependency resolution compared to NPM, is that we do offer all these full-blown features of a dependency manager, which is to replace another package, or to say that you provide a certain API or something like that.

Matt Stauffer:
Yeah.

Jordi Boggiano:
But I wouldn't say this is total beginner stuff, and most likely you won't need it from the get go. But it's just good to know that the concept exists. And if you think you made need it, just go and look it up.

Matt Stauffer:
Go Google it. And so those were replaced, which says this replaces another package. And what were the other two?

Jordi Boggiano:
Provide, which typically it's used for providing in an API or another package. But it's mostly used for like PSLs and stuff like that, where there's a name that's like a virtual package that people can provide if they implemented that interface. And then people that rely on one instead of requiring in specific implementation, they would just acquire these virtual package. And then you can require whichever implementation you want, and through the provide and the require, they meet each other and interesting that satisfies the requirement.

Matt Stauffer:
And so if someone were familiar with PHP, the virtual package would be the interface, and then the real package that's providing that would be more like the concrete implementation?

Jordi Boggiano:
Right.

Matt Stauffer:
All right. So we've talked a little bit about Composer.JSON, and obviously there's a ton of other stuff there, but I appreciate how much you're holding yourself back by not talking about all the nerdier stuff or trying to keep it beginner. So, in most projects you're going to have a Composer.JSON and a Composer.lock. Some folks haven't gotten familiar with how package lock works, and some folks might not be familiar with it at all. And it might not be JavaScript folk. Could you tell us just a little bit about what Composer.lock is, and how it works?

Jordi Boggiano:
Yes. So when you do a Composer update, and I'll maybe take this opportunity to really explain this distinction between update and install, which is one of the main things I see people are really misunderstanding. So you have the two main comments are like updates and install. When you do an updates, really, what this does is it takes the requires, it compiles this list of dependencies, figures out what you need, and it writes that down into the Composer lock file. And essentially, that's the update. That's just updating the dependencies into this log file. And then you have another step which is install. And install really only takes the lock file. It doesn't look at Packages at all. It just reads the lock file, and it applies that to your vendor directory. So it just goes through the Packages. It looks at what might already be installed. It sees, "Okay, what are the differences? How do I get your vendor directory up to speed with the lock file?"

Jordi Boggiano:
So if it's a fresh project and you have nothing, it just installs to the entire list of Packages. If you already have some stuff, it might do some updates and like upgrading Packages, downgrading some, removing some, whatever. It just does what it needs to do. But it's really only based on this lock file. Now, I think what confuses people, and it's something we did to be convenient, but it's also maybe confusing, is that when you run an install and you don't have a lock file, it's just going to generate it for you and then install.

Matt Stauffer:
It's like Composer update, without even having typed, "Composer update."

Jordi Boggiano:
Exactly. And inversely, if you on Composer update, we update the lock file, but then we also run the install implicitly, because that's most likely what you want to do. So they both kind of do the same, but not really. And depending on the state of things. And so, I fully understand why people do get confused. But I think the distinction is very important, because in some cases, like the way people communicate things, are actually very confusing when you know these concepts. Because, especially for me, when they report issues, and they're like, "While I'm installing it, it's super slow," or something. I'm like, if you're an install, it's just reading the lock file. There's no way it can be slow because it's reading a list of 50 Packages and inserting that.

Matt Stauffer:
And then the math, the calculus or whatever, that it's doing to figure out what is the right dependency here and there, if there's a Composer lock file, it doesn't have to do any of that math because it's already been done.

Jordi Boggiano:
Exactly.

Matt Stauffer:
Composer.lock is like the cache of those calculations. And so anytime you run Composer or install it, or Composer install has to have a lock file, otherwise it'll generate one for you. So that's why sometimes running Composer install, will run a Composer update for you beforehand.

Jordi Boggiano:
Yep. And then just to go back to what it is, so now that we hopefully understand the concept, let's say the main benefit of is that it ensures that several people can walk on exactly the same versions, right? So if you're in a team or more importantly, if you're just deploying to production, let's say, you want to be testing. In development, you have some versions and then you have maybe your CI, I like build server that should also run an install. It should not run an update. It should run install because it should have the Composer, that lock file, which should be committed, absolutely. So that you know that the CI is running with the same versions as you do, and they know that production will also be running with the same versions as you do.

Jordi Boggiano:
Because if not, then suddenly you might have a different version in production. And you see a bug and you're like, "What the hell? On my machine it doesn't work. On prod'." There are enough other opportunities for this to happen without having different dependencies. So let's just minimize the chances of things going wrong.

Matt Stauffer:
I love it. And that actually brings to a really interesting point, which is that knowing when to run Composer update is really one of the things you're getting at here. And one of the things you said here is, don't run Composer update on the server. Don't run Composer update on your continuous integration tool. But I think that further, I think that a lot of people don't know exactly when is appropriate to run Composer update. And further, I would actually even say, and some folks don't know, "When should I run Composer update?" And, "When should I run Composer update, and then pass the name of a package?" So, could you give us some good general practices of... Like for example, let's say you are responsible for maintaining ongoing Software-as-a-Service application. And I know that you've worked in Symphony, so let's just imagine it's Symphony. But for those who don't know, Symphony and Laravel share. Laravel has a whole bunch of Symphony's components in it, so they work very similarly. If you were working on a long-running two, three year long project, how often would you be running Composer update? And would you do Composer update frequently, or you would you be picking one package at a time?

Jordi Boggiano:
So I would say on a day-to-day basis, it would probably be running like updates of specific Packages if I need it. Like if I know I need the latest version of some dependency, I would just go and update that one. Doing a blanket update of everything, I would say it's something that you should be able to do. Like in an ideal world, you should have enough tests, and everything that you should just be able to run an update and run the CI, and know that it's going to be fine. In the reality, it's not always like that. So you probably want to be a little careful. But let's say I... I tend to do this. It depends. Sometimes it goes like for a few months between really updating everything, and it's usually not great when you do that, because you end up having to update a lot.

Matt Stauffer:
Yeah.

Jordi Boggiano:
So usually, after I went through that, I try to update more regularly, again, and then eventually you just get busy and slips up.

Matt Stauffer:
Goes back to a few months again. Yup.

Jordi Boggiano:
But when I find myself in this situation where you run an update. And a good thing you can do there is just, run update with dash dash dry run. And that will just show you what it's going to do, but it won't actually do anything. So there you can get a feel for how much trouble you're in. But more importantly, what I usually do is, I run that and then I see, "Okay," like this and that package, I know we're using super in-depth. And so I really want to go check the change logs before I updated them. And then other things I know are like just using this one little function that does all the magic. And I just assume it's going to be fine because you're going to have to weigh the risk and then potential for damage, according to how you're using things. And there's no silver bullet of how you can really do this. But I would say if you do have enough tests, running updates very frequently, is probably better because you get security fixes and bug fixes and all that.

Matt Stauffer:
But you never hit that moment of terror when you have to update six months of Packages and you don't know how long it's going to take to catch all the bugs or whatever.

Jordi Boggiano:
Yeah. No, that's the other thing is, when you update everything at once, and something goes along wrong, you don't know.

Matt Stauffer:
Yeah. And I really appreciate that, because one of the things I've often had to train out of junior PHP programmers is, you can't just Composer update all your Packages when it's been months, without re recognizing that you just increase the version multiple points on many, many, many Packages. And so it's not that you shouldn't keep up to date, it's not that you should never run Composer update on its own without passing a package, but you got to be aware of what you're doing, and when you're doing it. And it is helpful if there's a couple key Packages to really consider just upgrading them more frequently on their own, if you can.

Jordi Boggiano:
Mm-hmm (affirmative). That just boils down to... It's always like that. When you have enough experience, the answer always becomes, "It depends."

Matt Stauffer:
Yep. It's so true. It depends. Yeah. I would say that this is something I'm not going to ask Jordi to sign off on. But baseline, one of the things that we at Titan often get asked to do is to come into software programming projects where it's been running the same PHP app for 10 years, or they've had a whole bunch of transitions or something like that, and they just say, "We need it to be normalized. Tell us what's the best practices for the PHP community and the Laravel Community." And so what we do is set up some really bottom line baseline standards and say, "Let's start by getting to these, and then we can work on better practices."

Matt Stauffer:
And so with this one, this is not global or anything, but one of the things I've worked with, with a few of the folks we work with, is just say, "At bare minimum," and it helps that Laravel has a six month recycle, as does symphony. "At bare minimum, every six months, on a bigger project, set aside a week, upgrade your Laravel version, upgrade all your dependencies, do a Composer update, do a full QA scan, check everything in your whole application." And for lot of smaller applications, that'll take six hours, or four hours, or two hours. But for some people who are really been relying on this and have tons of people on it, that might take a little bit of time. And it shouldn't take a week. But the good news is, if you get your boss to sign off in a week, and it only takes you eight hours to do, you can spend the remaining four days running the tests, so next time it's not as scary. So I wouldn't recommend everybody only do their upgrades once every six months. But if you're doing it less frequently than that, that's your first bar to hit. And then from there, really go back and listen to some of the things that Jordi just said.

Jordi Boggiano:
Yep.

Matt Stauffer:
All right. Let's move on a little bit to challenges in got yous. So what is one of the most common misconceptions people have either about Composer as a tool, or about what's something good or bad about working in Composer? What do you think lot of people have mixed up? You did already mention install versus update. Do you have any other, or is that your main one?

Jordi Boggiano:
So one that plays into that and that just adds another layer on top, maybe, is the 'require' command, and really what happens when you run require. So yeah. I was saying, most people I think... Not most people, but some people, I think, only require only rely on require to update Packages. So just to quickly boil down what to require does, essentially, it does and edit of the JSON. It's like opening the JSON file, changing the requirements connected to require statements you have there, for dependency, and then running an update for just that one package you just changed. And then as we discussed before, that update will run an install, all right? So when you run require, you're actually running a require which runs updates, which runs install. And that possibly adds to the confusion.

Matt Stauffer:
Got it. It's more of these things where you think you're only doing one thing, but it's doing multiples.

Jordi Boggiano:
Right.

Matt Stauffer:
Yeah. Well, interesting. I want to go to a point there. I think there's two practices that I've seen recommended, that I've been telling everybody, "Stop doing." And I know it's not exactly, but I want to ask you if I'm right on these. So the first practice is relevant to this, is that for a long time, a lot of people were saying, "Here's how to add my package to your local project. Edit your Composer.JSON, and add a line there, and then run Composer update." And what I would say is, "I want you to do Composer require that package instead, for two reasons. One, because you get the dependency check as you're adding it in. And two, because you're only running an update on that package rather than the entire thing all at the same time." Am I right in that, or do you have any nuance to give there?

Jordi Boggiano:
No, I think that's absolutely correct. And just to add something to that, I can in Composer tool, which is not out yet, and probably won't be by the time you hear this, but we've been hard at work on this for the last few months. And so what happens there is, we changed require a little bit, so that in most cases, it just will do what you want. Like previously, there were some cases where it just was failing to do the update because it just wasn't updating enough Packages, by only updating this one new one. So the thing that's going to help us well, to reduce problems there. But what you said, I think, is absolutely correct.

Matt Stauffer:
And so Composer too, will actually make what I just recommended even more valid of an option, because it's going to handle the... Okay, great. And the other thing is the idea of whether or not you commit your lock file to your repo. So the rule I've been giving people and I want you to tell if I'm right or not, is that if it's a project, you commit your lock file. If it's a package, you don't commit your lock file. And package, meaning something you're going to put up on Packagist. Is that a good rule or not as much?

Jordi Boggiano:
So the general rule, I like to give orders for projects, like for applications. And so everything I said before like about the lock file, you should absolutely commit it. Yes. You should never run update on CI or production. That's also true for applications, and then projects. For libraries, it's always a little bit fuzzier because it's more in the, "It depends," category. Some people prefer to just not have a lock file there. And we actually recently added a new option that you can put in the config. You can have a no lock. Sorry, it's a flag. But the config is just called lock. So if you say lock false, it just won't generate the log file anymore. So if you're really one of these library developers that does not want to have a lock file, you can just completely forego it now. And it's just a long debate, and then people don't agree. And so I don't really want to pronounce myself. It just-

Matt Stauffer:
You know what helps for me is, I actually don't care what package authors do.

Jordi Boggiano:
That's the thing.

Matt Stauffer:
My intention is more to say, "You may have seen people out there saying, "Don't commit a lock file." That's only for Packages." Not only is it only for Packages, but you're saying it's even an opinionated thing. Great. That's even more helpful. But the important note for me is, when you're building an application, that's not for you. When you're building an application, commit the lock file, period.

Jordi Boggiano:
All right.

Matt Stauffer:
Okay, cool. So you're on with that one. You don't want to step into the package argument, but in an application, commit the lock file?

Jordi Boggiano:
Right.

Matt Stauffer:
Great. Cool. Thank you. Okay, so let's talk about this one right here. So my next question for you is, what do you think is one of the hardest to resolve problems you see people run into with Composer? What gets them the most stuck?

Jordi Boggiano:
Most likely it's when the dependency resolution just goes boom. Which, as we mentioned, is more likely to happen with Composer than with tools like NPM, just because we do have to resolve these to a single version per package. And we cannot go through this nice hack of just saying, "If two Packagist require two different things, well, whatever. We'll just installed in both." So in this case, what we have to do is just like throw an error, and print something that sometimes looks like a wall of text. And usually, I don't know. If you do open source, you'll sooner or later figure out that most people just do not see error messages. And then when they tend to be like really, really long, than the chances of being read are going to be lower.

Jordi Boggiano:
So I think that's definitely one of the big challenges. And that's also something we really worked hard on addressing in V2. So it's not going to be magically telling you, "You have to solve it that way." Because that's the problem, is, we don't know how to solve it.

Matt Stauffer:
Yeah. That's why you're seeing the error.

Jordi Boggiano:
Yeah. So it's still going to be an error, and you still have to read and then figure it out. But the wording has been improved quite a lot. And we try to detect common problems and try to hint at solutions when we can.

Matt Stauffer:
Yeah. So I maintain a couple projects that for various reasons, have conflicts often. One of them would use the replace directive. And so we had a long time where people would get into weird version, dependency mixes. But also a few of them are globally installed. And we won't get into this on the podcast, but just a quick note, if you have a globally installed Composer package, you're probably a little bit more likely to see dependency conflicts, because let's say you have the Laravel installer and Laravel Valet, and then three other Laravel based packages, and you install them all at different times. Each of them will have brought in different versions of their dependencies. But it's not like they're in the same app, they're just in the same computer. So just know that if you're using globally installed Composer packages, and Jordi, you can speak to this if you want, but I'm trying not to derail too much. You're using globally installed Composer Packages. One of the best things you can do is just frequently get them all up to date to their latest version. And at least with the ones I've worked with, it often addresses a lot of those dependency issues.

Matt Stauffer:
But the reason I was mentioning that is because, one of our most common GitHub issues that we deal with in those projects is, "I'm trying to install this thing, and getting this error, and I don't understand why." And most of the time, we can just say, "Oh, well that's because you have this other package that has version five of this, and this version you're trying to install it needs version seven of this." And you can just update it. Every once in a while, it doesn't make sense to us. And I think I remember there was a tool. Is it Composer why-not, or something like that, that gives them more detailed explanation of why you can't install a package?

Jordi Boggiano:
Yes. So there's Composer why, and Composer why-not, which shows you why something is installed, which backtracks the dependency three to show you which of your require led to this being stalled. And why-not, it's more like, "I have this package and I..." The problem was why-not is it only works, as far as I remember, if a package is installed. But it's not installed in the right version. So if you're wondering, "Why is this version not being installed?" It might help you. But if it's not installing it at all-

Matt Stauffer:
Got it. So if you asked for two, and it's only giving you one... Yeah. Okay. So is there any trick other than, "You know what? Go read the error messages." If you can try to install something new and you get an error... Like one of the tricks that I've tried that my brain tells me has worked before, but I bet you you're going to tell me it doesn't matter, is, sometimes it feels like if I delete the vendor directory and delete vendor lock and then Composer install, sometimes they get more success than when I run Composer update. Is that true or no?

Jordi Boggiano:
That is most likely true in V1. And that's definitely one of the big pain points that we've seen is that, in V1, the way it behaved is it always looked at the installed Packages, as well as looking at Packagist and so on. And in V2 we just completely removed that. So when you run an update, it only looks at Packagist, and only looks at the remote repositories.

Matt Stauffer:
Great.

Jordi Boggiano:
And the lock file, if you're doing a partial update. But the install stuff just does not play at all in the update. And that solves tons of these weird edge cases where it's like, "Oh, it works there, but it doesn't there, because I had this previously installed." This has really held debug, and just generally speaking, it was usually ending up in strange situations.

Matt Stauffer:
Yeah. So, in V1, which we're all using today and have been using for nine years, in theory, it's unlikely, the first thing you should do is just go read the error logs. But in theory, you could find yourself in circumstances where, when everything else fails, you've read the error logs, your conflict doesn't make sense, try deleting the vendor directory, deleting your Composer.lock, and then installing. And that whole problem will be going away as soon as Composer do comes out. Fingers crossed.

Jordi Boggiano:
Yes.

Matt Stauffer:
Awesome. I love it.

Jordi Boggiano:
Well, you'll still get conflicts. And then at that point, let's say, you really have to read your message.

Matt Stauffer:
Yeah. Right. But at least you're not in this place where like, "Oh well, it might say that, but the problem is really whatever else." Man. I could talk your ear off all day, and I'm really enjoying this. But I want to make a little bit of space for you to talk about whatever's on your mind, and then also for our normal final followup stuff. And so I want to skip a couple questions and move on to my main question, which is, is there anything you want to talk about? Is there anything on your mind that you wish you could share, or you wish more people understood or you could talk about, about Composer or about Packagist, or dependency management in general?

Jordi Boggiano:
So I guess I did mention that already, I think, lots of things. On my mind right now is mostly V2, because I've been looking at this in the entire week, just trying to push forward there a lot. I just published a blog post today, which I guess, will be pretty old by the time this is published.

Matt Stauffer:
I'll still put it in the show notes.

Jordi Boggiano:
But whatever. It's still should be news to most people because I don't expect everyone will go jump on V2 immediately.

Matt Stauffer:
Sure.

Jordi Boggiano:
But the blog post is essentially asking people to go and test it a little bit more, because we really opened up. It was up there on GitHub for the whole time, but we started asking people a few weeks ago to test. We got tons of feedback, and issue reports, and a bunch of new features as well. And now it's really getting to a point where I feel like we're almost there with a release. So getting more eyes on it and more people do test is definitely critical.

Matt Stauffer:
Well, can I ask you a question about them, about Composer Two, real quick?

Jordi Boggiano:
Sure.

Matt Stauffer:
So let's say I finally just got a handle on Composer One, or maybe let's say, I'm just getting started in Laravel. I read this, I listen to this podcast, and it's May 10th, or whatever, and you haven't released Composer Two, but I know it's coming. What does the upgrade path look, both in terms of my code, and also in terms of my knowledge? Is it going to be completely seamless? All your Composer.JSON files look exactly the same using the same commands? Is it going to be a little bit different or is it going to be a pretty major difference?

Jordi Boggiano:
I would say for most users that are just using the command line tool, it should be seamless. We're aiming for seamless. I think the main pain points are going to be on plugins, because plugins all require a specific version of Composer. And that means that to upgrade to V2, you're going to have to upgrade to version of those plugins which supports V2.

Matt Stauffer:
Yeah. When you say plugins, you mean Composer plugins like prestissimo, not-

Jordi Boggiano:
Absolutely. Yes. Yes. Yes. So yeah, Composer-specific plugins, which, depending on the community, are more or less like... I'm not entirely sure about Laravel, but I know in some, mostly like in the more CMS-y application style stuff, they did tend to have lots of plugins that do like values things, sometimes for legacy reasons. But anyway, there are quite a few plugins which are really popular. And so that's going to be the biggest hurdle, I think, in terms of update. The rest, like for most end users, this really shouldn't change much. I think it's going to get faster, it's going to get more reliable, more deterministic, and much better error messages as well, when things don't go right.

Matt Stauffer:
Love it. So don't hold off on learning Composer now, because you know V2 is coming out. Don't worry about Composer V2 coming out or anything like that. And just for everyone to know, if you aren't familiar with the idea, as far as I know, there are no common Composer plugins used in Laravel community. There are folks who are really excited about a Composer plugin here, a Composer plugin there. But if you hear that phrase, Composer plugin, and it doesn't trigger a memory in your mind, then you're probably not using any, and you probably don't need to worry about that upgrade path. So again, if you're not already nerding out about customizing your Composer with a plugin, don't stress that that's going to make it hard to upgrade your Laravel apps, because you probably don't have any in there.

Jordi Boggiano:
All right.

Matt Stauffer:
Awesome. I love that. Before I dig a little bit further, last couple of questions, is there anything else you wanted to talk about today?

Jordi Boggiano:
Well, just one little plug maybe, would be about Private Packagist. So just to mention private Packagist, because that's our bread and butter. So that's something we started a few years back, as I mentioned. And it's essentially like private hosting, if you have private source code that you want to install as dependencies. But it also does mirroring of all the open-source stuff you're using. And we also have now, adding security notifications, and automatic updates and so on. So that's a paid service that we run on the side as well. That's for Packagist.com, and it's like the commercial version of Packagist.org in a way. And that helps us fund all the open-source development as well, and run the servers and whatnot.

Matt Stauffer:
Who would be the primary target of Private Packagist? Would it be a consultancy like me, or would it more be like a company that has their own internal apps that they're running?

Jordi Boggiano:
I would say both. We have both types of customers. We have consultancies that actually have multiple organizations that they run for their customers. We have just products that are using it as well for their own stuff. We also have a marketplace product that, like if you want to sell Packages, and offer of a Composer repository for your paid Packages, let's say, we offer that as well, with an API so you can manage like tokens and so on. So yeah, those are a few options of a good use cases.

Matt Stauffer:
Awesome. I'll ask you for more plugs later, but I got two more questions for you before we get to plugs. Thanks for sharing that. Number one, if somebody wants to learn more about Composer, if they want to dig deeper into how it works, or just learn more about it in general, where would you recommend they go?

Jordi Boggiano:
So I had a good thing there, and I really don't know.

Matt Stauffer:
I got one. If you just go search Jordi's name on YouTube, there's five or six talks that he gives the going into various aspects of it. So that's a start.

Jordi Boggiano:
Right. There are a few talks. So actually, that's the only one I found, was a talk called Composer Best Practices by Nils, which is the other co-maintainer on the project. And I think I would say that one is mostly like, if you're looking for a tutorial or something, this one will actually explain things. My talks were mostly about like the open-source process, and so on, which might be interesting anyway. But not really-

Matt Stauffer:
Yeah. When you gave one at Laracon EU five years ago, that was a deep dive into Composer. And I think that would be a good next step as well. So maybe those two, your deep dive talk, and then Nils'... I forget what you called it. But Nils' talk about it.

Jordi Boggiano:
Yeah. I'll link you up afterwards.

Matt Stauffer:
Okay. And I'll put all this in the show notes, everybody. Okay. All right. So my last question for you before we talk about any other plugs or ways to follow for you, you have, on your Twitter profile, a place where if anybody wants to support your open-source stuff, they can go buy your software off an Amazon list wishlist. And I saw that you have four or five Japanese whiskeys on there. So I have had Japanese whiskeys twice. And to me it tasted like scotch, but smoother. So I'm very interested. Let's say the listener only knows about American and Irish and whatever else, whiskeys, and doesn't understand anything about Japanese whiskey. Could you give us a really quick introduction to Japanese whiskey?

Jordi Boggiano:
Yeah. So I think actually the way you described it is very accurate. I find that they tend to be really, really smooth. But to be honest, it's not like I have an obsession with Japanese whiskeys. I think it's just I had a few weeks he's on there, and all the others gone.

Matt Stauffer:
So those are just the ones that were leftover? Oh, that's hilarious. I was just like, "Oh, this guy's like a connoisseur or something."

Jordi Boggiano:
No. I do like them, but for some-

Matt Stauffer:
Okay, let me step it back then. If you had other stuff on there, what is your like top favorite whiskey or scotch or whatever of all time?

Jordi Boggiano:
So I mostly enjoy the peaty ones, I have to say. They tend to have more of a strong, smoky taste. But I find if not that, then I find the Japanese ones, which are very smooth, a good counterpoint to that.

Matt Stauffer:
Okay. Do you have a favorite peaty whiskey? Because I know the main ones, like Lagavulin and stuff like that. But I don't know if those are the main ones, and there's the better ones or-

Jordi Boggiano:
Well... Lagavulin is definitely a good... It's a good thing you'll find everywhere, and it's a decent taste. I'm not really one to pick favorites.

Matt Stauffer:
That's fine. If I gave you a good whiskey, you're going to drink the good whiskey. It doesn't have to be better than the other one, right? Cool. Well, it's still good to geek out on this a little bit. One last question for you there, do you like scotch much?

Jordi Boggiano:
Yeah.

Matt Stauffer:
Have you ever had the Balvenie?

Jordi Boggiano:
I'm pretty sure.

Matt Stauffer:
Okay. Balvenie is like one of my favorites. It's relatively approachable. It's on the high level of, you can buy it at every liquor store. So it's not like the super fancy, but it's not cheap either. And it was the first scotch I ever had. So it's got like a special place in my heart. So every time I talk to somebody about scotch, I've got a plug that they should go try, one of the 18 or 12, or something like that of Balvenie. All right. Thank you for letting me nerd out about that for a minute. So before we go, how can people follow you? Are there any other plugs you'd like to make? So you said Private Packagist. Are there any other plugs or anything that you want to just pick up before we head out for today?

Jordi Boggiano:
No. I think that's but it for me-

Matt Stauffer:
Links to your website and your Twitter-

Jordi Boggiano:
Mostly Twitter, I think, is really the only channel I use for communication, at this point.

Matt Stauffer:
So how do you say the handle? How do you say the guy's name?

Jordi Boggiano:
Seldaek.

Matt Stauffer:
Seldaek. Okay, cool. I didn't know if it was 'daek, or 'deck. Okay. Cool. At this point, nobody knows.

Jordi Boggiano:
Yeah. I'm French speaking originally, so I would just say Seldaek, in French. So you pronounce more the 'ae'.

Matt Stauffer:
Right. Got it. I love it. Yeah. We can all make it up in our heads and say it a little bit different each time. And when we see you in person, each of us will choose our individual pronunciation of your Twitter handle to greet you.

Jordi Boggiano:
Sounds good.

Matt Stauffer:
All right. Jordi, this was a ton of fun, and I really appreciate you taking your time. All this will be in the show notes, you all. So you'll know how to follow him, and how to catch up with him, and learn all this stuff he did here. And as always, if you have any questions for either of us about this, hit me up. I'm Stauffer Matt at Twitter, he's Seldaek on Twitter, and I'm sure we'll be happy to answer any questions that came up. So thank you all so much and I'll see you later.

Jordi Boggiano:
Thanks.

Matt Stauffer:
Thank you.