Matt Stauffer:
You are now listening to the Laravel Podcast.
Hello, everybody and welcome back to Laravel Podcast, season six. I'm your co-host, Matt Stauffer, and I got Taylor with me. You want to say hi to the folks?

Taylor Otwell:
Hey, everybody, how's it going?

Matt Stauffer:
So as we have shown you what we're going to be doing for this season, with every episode, we're going to give you an update of what's going on in the world of Laravel and then talk about any topics that are really relevant to us. So this one is completely separate from anything that's going on in the world with Laravel, but I just wanted to hype that screencasting.com just pushed out there first or only, I'm not sure, video and that's Aaron Francis, Laracon speaker, who's been doing a lot of great screencasts lately and I bought and consumed a pretty decent amount of it and it's got a lot of the nuggets that I've learned painfully over the years in ScreenFlow and doing this kind of stuff and so I was really grateful. Taylor, do you do a lot of video editing?

Taylor Otwell:
I have in the past. I haven't done as much lately, but back in the old days when Laravel first came out, I used to actually make those little screencasts pretty often actually, just showing off the little Laravel features and I would use ScreenFlow for that. I haven't done it in a while, but Aaron, we actually do have him cooking up something for Laravel Nova right now, just on the side, a little intro video screencast type thing for Laravel Nova that we're going to put on a revamped marketing site for that.

Matt Stauffer:
That's awesome.

Taylor Otwell:
I'm curious to see what he comes up with.

Matt Stauffer:
Yeah, I remember you used to make those videos, but I never knew if you edited them or if you paid somebody else to do the editing.

Taylor Otwell:
Yeah.

Matt Stauffer:
Okay. So you know this world.

Taylor Otwell:
Yeah, I edited them.

Matt Stauffer:
Yeah.

Taylor Otwell:
A little bit.

Matt Stauffer:
I've made lots of YouTube videos in the past, but right now, I'm literally today I'm editing the last video of a course I'm about to do and it's my first time ever doing a course and I've realized that a course has a whole new set of responsibilities in editing that just popping out a video on YouTube is not quite the same. So it's been fun, as I'm finishing up editing, seeing his course where he talks about the recording of his course through that process. So if you're interested in doing Screencast, if you're interested in doing YouTube or whatever else, check out screencasting.com, friend of the pod, Aaron Francis, longtime Laravel community member and Laracon speaker.
All right, so let's talk about new things that are happening in the world of Laravel. So one of the things we have on our list here is talk about the Livewire version of Breeze. And I don't know, in writing my book and talking about the various stacks that you can choose for the various Laravel tools, I don't think everyone even fully understands that there are these stacks and the list of stacks available for each of them aren't the same. So could you talk a little bit about how Breeze and Jetstream have the different stacks and what they have optional right now and what this introduction means?

Taylor Otwell:
Yeah, so Jetstream and Breeze being Laravel's two main starter kits and the main difference between them is Jetstream has more features, it's a little bit more stuff out of the box, like team management, two-factor authentication, some other stuff. Breeze, a little bit more streamlined, like the old school Make Off command if you've been around Laravel for a while, basically continues... It's the spiritual successor to Make Off, you might say. And they have different stacks, so basically they have either Inertia, which lets you use Vue or React, or they have Livewire, which lets you use Blade. And in Breeze's case, it also has just a plain Blade stack with no other additional things on top.
And the reason for that is... To give you some history, I didn't want Laravel to be very dogmatic about one particular way of doing front end. And I think this is a little bit different than something like Ruby on Rails, which has been in the Twitter space lately with the whole TypeScript drama where David, the maintainer on Rails, I think is very much JavaScript in moderation you might say. And I didn't really want to take any hard stance either way because I actually personally really like Vue. I enjoy React as well, but I think Livewire is also awesome and I wanted everyone to be able to choose their flavor. So yeah, Breeze comes with a few different stacks. It's historically had just plain Blade, Inertia paired with Vue or Inertia paired with React. And now this week we launched Blade paired with Livewire, which just supercharges Blade and lets you build modern reactive feeling applications without actually writing much JavaScript at all, which is really cool.

Matt Stauffer:
And Jetstream, I don't know if you remember off the top of your head, but I remember when I was writing the book, the latest version of the book, I was noticing that the list of stacks available to Jetstream and Breeze aren't the same primarily because Jetstream requires reactivity whereas Breeze doesn't, right?

Taylor Otwell:
Basically, yeah. So Jetstream has either Livewire or Inertia in Vue. There's actually no Inertia react stack, and partly because it's just a lot. Jetstream has a lot of stuff and it's a lot to maintain all these different stacks. And when you add another permutation onto the list of stacks, it actually-

Matt Stauffer:
Lots of maintaining it.

Taylor Otwell:
... greatly balloons up how many things we need to maintain. So it's a lot easier to add a new stack to Breeze because it's only six or seven pages maybe so it's pretty doable.

Matt Stauffer:
And so that was what I wanted to point out is that Jetstream, each of these stacks is a huge amount of code. It's a huge amount of templates, it's a huge amount of reactivity code and everything like that. Whereas Breeze is... For those who aren't familiar, the old Make Off, it's login, sign up, password reset, email authentication, I think. There's just a lot less going on there that you have to code. And also that ends up being the reason why there was a classic Blade stack with Breeze where there was never a classic Blade stack with JetStream. And as I was talking to folks about it, I just realized that wasn't always something that people are super familiar with. So I just wanted to cover that real quick.

Taylor Otwell:
Okay.

Matt Stauffer:
We've got a Livewire Breeze now, so that's fantastic.

Taylor Otwell:
Yes.

Matt Stauffer:
So I know that I've been talking to people about prompts and not everybody actually knows about prompts. So before we talk about the new feature we have in prompts, could you just give a quick intro to what prompts is if people haven't seen the intro videos?

Taylor Otwell:
Yeah, so back of, I don't remember how long ago, several months ago, me and Jess were talking about how these CLI libraries in the node ecosystem just looked awesome. They had awesome text prompts, awesome spinners, cool loading indicators, progress bars, and they just looked so much better and more modern than anything we had in PHP. And so the goal was to bring that kind of CLI experience into PHP, if it was even possible. I mean we thought surely it must be possible because you can do anything you want to I guess.

Matt Stauffer:
Yeah.

Taylor Otwell:
But, anyway, Jess was the one that really cracked how to do all that. And to be honest, I have very little idea how it works.

Matt Stauffer:
Love it.

Taylor Otwell:
But basically it's a composer package you can pull in actually to any PHP application, not just a Laravel application. And it basically gives you seven or eight namespaced functions like text, spin, progress, table, different things like that. And it just looks awesome. All the prompts look really modern. There's validation, there's searching capabilities that does little dropdowns in the console and lets you select your search results. So yeah, it's pretty wild.

Matt Stauffer:
Yeah, it's the type of stuff where I don't spend as much time in the node ecosystem anymore. And so I was seeing her demo and being like, "Oh, there's a lot you can do here," because having written stuff to output to the CLI, I don't even understand the concept of how you can have stuff that changes while it's still in the same spot in the screen in the CLI. I didn't know you could do that.

Taylor Otwell:
Yeah.

Matt Stauffer:
So you said that there's a new feature here called MultiSearch. Can you talk to us about it a little bit?

Taylor Otwell:
Yes. Yeah, so we have had a search function since Prompts came out, which basically it brings up a text box and as you start typing, it drops down a little box that is filtering as you go, but behind the scenes you could be hitting a database. So as you're typing a user email address, the list of users is filtering as you type and it's querying the database on the backend and it's just a little search dropdown like you might see on the web, really. But it only let you select one option. So we just shipped MultiSearch, which lets you filter down your search results, arrow down with your keys, and then hit space bar to select multiple things you want to select and it gives you back an array of the selected options. So a pretty cool little feature. And with that, I forgot to mention, we shipped Progress Bar this week as well.

Matt Stauffer:
Nice.

Taylor Otwell:
As you would expect, you call a progress function, you pass it a callback, it increments the progress bar, but it just looks really good doing it and you can adjust the labels as it goes and show percentages and all of that stuff.

Matt Stauffer:
That's awesome. And I've been living in Valet a lot lately, which is not built on Laravel and it makes me wonder can I pull prompts in and do some fun stuff there. So I think might be digging into it after I get off this.

Taylor Otwell:
Yeah, I bet you can.

Matt Stauffer:
Awesome.

Taylor Otwell:
Yeah.

Matt Stauffer:
So another thing that's been talked about a little bit on the Twitter sphere is Pail. Can you talk to us a little bit about Pail?

Taylor Otwell:
So I think it goes back to a tweet maybe last week that Jeffrey Way made of Laracast fame and he said something about, "I feel like there should be a tail command in Laravel." And then I responded and said there actually did used to be a tail command in Laravel and it was in Laravel 4 or 5, where basically you could run Artisan tail and it would just tail your log file for your application. And I can't remember if it would work remotely or whatever, but anyway it would tail your log file. So Nuno thought that was just really a cool idea and he loves building CLI type tools and he likes building pretty CLI outputs. It's behind the renovations of Artisan Serve and all of the new output for the CLI in general in Laravel. So he started working on this package called Pail, as his own little experiment just to gather some community feedback and basically it works a little bit different than the old Artisan tail commands.
So what it does is when you run Artisan Pail, it actually hooks into the report function of the logging and exception handler so that even if you're not using log files, imagine you were sending all of your exceptions to Century and you're actually not logging them at all. The old tail command wouldn't really help you in that case because it was actually reading just the log file, the text file, whereas this hooks into the report function. So everything that goes through report, which typically is everything that you're sending either locally or to some external service you see right there on your CLI output. And of course it's all codified and color coded and has nice stack traces and everything.
He also added filtering capabilities so that you can filter on a given string or even a given authenticated user, like --user=1, and you get only the exceptions that that user is seeing. So actually pretty nice I think for simple use cases, just to be able to tail something for a specific user. If you're trying to diagnose something in production, which is something we do fairly often, we may need to impersonate a certain user, click around and see what is actually going on and we can tail or Pail that output right there. So anyway, I think it's a pretty simple package. I think we'll probably just ship that out pretty soon.

Matt Stauffer:
Okay. Yeah, I really liked seeing the filtering aspect of it because one of the things I've done often with logs is try to get information out of it that I did not send, and it's often user related information and I'm like, "Oh crap, I need to now embed it in there." So yeah, the ability to say for this user, for this particular string or whatever and actually get the realtime trailing reports as well is really, really, really cool. I'm excited to play around with it.

Taylor Otwell:
Nice.

Matt Stauffer:
Okay, so moving on from announcements a little bit, we still got a little bit of announcement stuff going on here. We had a couple of questions that had come in around hosting and I know that there's been some hosting changes. So I said I wanted to address those questions first and have a conversation around how to host Laravel and then move in from there to what's been going on with Forge and Envoyer.
So the biggest question that we had from several people is what are the actual options for just deploying a Laravel app to the internet today? And I know we talked a little bit beforehand about what the various options, so I'll let you run with it and I'll chip in as possible, but if you were to say, "Here are the options for hosting a Laravel app today," what are the main, maybe not the actual companies, but just the main categories of hosting option that we actually have available to us.

Taylor Otwell:
So as far as I know there's probably still the old option of having a server that you FTP files into, any virtual private server. I guess that's still a thing. Like GoDaddy or DreamHost or whatever. So of course you could always just get a server that has PHP installed and upload the files that way. That'd be the most old school way to do it. Our options internally at Laravel are Forge or Vapor.
Forge is a tool that links to your Digital Ocean, your AWS account, a place where you can spin up virtual private servers. It installs everything for you. It links to your GitHub and then when you push it deploys out to your server using Forge.
Vapor is a serverless solution built on AWS Lambda where it packages up all your code, ships it to Lambda. It provisions everything you need on AWS once you link your account and you don't really need to think about the underlying servers as far as picking how many servers you need, load balancing traffic across them, doing backups, doing operating system updates. You don't really need to think about any of that. So those are the two options we have internally. And I'm sure there's some other third party options. I think you can still do Laravel and Heroku, you can ship Laravel on fly to IO. So those are the main options I'm familiar with. I'm not sure if there's anything else out there.

Matt Stauffer:
I see a little bit more of the world than you do unfortunately because I see some nasty stuff there. But yeah, most of what we see is self-hosted, so there's a ton of companies that just run their own hardware, whether it's in the cloud or something they have locally, but it's basically they completely spun up the infrastructure and they are, like you said, they're doing whatever the deploy system, and sometimes it's somebody's SSH is in and they get pull and sometimes it's actually FTP or whatever.
You've got the shared hosting, which is the old school DreamHost and Blue, whatever that one was that we all used for a while and a couple of those. And so shared hosting, the upside is it's super, super cheap. You pay $10 a month and you have basically unlimited sites. The downside is, I mean there's a million downsides, but one of them is you don't have your own box. You're sharing with other people. And if somebody else is a bad actor who's on the same box with you, then your site's just going to slow down and at some point they're going to say there's no way to keep the site from slowing down other than paying for your own box. At which point you're moving up to the next one, which is VPS, virtual private server, where you basically have your own, it's not actually a full server, but it's much more segmented than shared hosting is. And that's things like Digital Ocean and Linode and AWS-EC2, and that's what Forge lives on top of.
Forge is a tool for managing your own VPS, but you could do your own VPS yourself if you wanted. Then you've got true serverless, which we were talking about earlier. AWS Lambda and Vapor on top of it are what people think of when they talk about serverless. But then you made a point, we were talking earlier, that there's also other things where they effectively manage it for you even though it's not on top of Lambda. And that's things like Heroku and Fly.io and stuff. And I don't know if people traditionally call them serverless, but there's definitely things spin up and down. And I think maybe the difference between serverless and Heroku is mirrored like a managed VPS maybe. So I guess you've got VPS where you have one box and then you've got managed VPS where you don't even really think about the boxes you have, you just, Heroku calls them dynos. But it's like you just upload the stuff and you can just drag a little slider to make it more or less powerful.

Taylor Otwell:
You still have to manually scale up your dynos.

Matt Stauffer:
Yeah. And then you've got the most further kind of thing, which is serverless, where it's purely just like, hey, throw whatever you want at the server, and it's just going to scale up and down and charge you accordingly. But I don't think anything else has really changed there in terms of hosting. I think those have all been, I mean, serverless is probably the newest edition. Managed VPS, VPS, shared hosting, self-hosting, those have all been around for ages. It does feel like serverless is more relatively new and Vapor on top of AWS is certainly the place I would go if I was doing something, although Chris Fidow works at Fly.io, so it's coming up in my feed a lot more. I don't know a ton about it, but it definitely is interesting to me.
But all this leads a little bit into one of the conversations that you had about a new feature, which is the ways that Forge and Envoyer have been touching each other a little bit. Now, Envoyer isn't technically a hosting platform. You can hook it into an existing VPS, but I know that not everyone has a full understanding of what Envoyer does and the value. So could you start by giving an intro to Envoyer and then also tell us about this new feature?

Taylor Otwell:
Yeah. So I wrote Forge in 2014 and then quickly followed up with Envoyer in 2015. And Forge still to this day, doesn't really have zero downtime deployments built in, where the traditional way of doing zero downtime deployments in PHP is by putting the new code in a new folder and then SIM linking your currently serve web directory to that new folder in one atomic operation. And that's what Envoyer does. So you tell it your server information, the IP address, where your code's located on GitHub or GitLab or Bitbucket, it sets up all the SIM linking, all the folders and it pulls down the fresh code, does the SIM linking, runs your deployment hooks, runs your migrations if you want, all of that stuff. So it's more like a code deployment platform, not really a hosting platform, but Forge and Envoyer pair really well together because you can build your servers on Forge and then you can do Envoyer or do the zero downtime deployment if you need it. So a lot of people actually just don't care, just run my deployment script from Forge. I don't care if there's two milliseconds of downtime while the pull runs or something goes wrong because we just don't have enough traffic to care about that or whatever.
But a lot of people want to do zero downtown deployment if they have a lot of traffic or they have customers on the website. But historically it was like Forge and Envoyer had no idea about each other at all, which felt really weird because they're both built by Laravel.
To give you some background, when I first wrote Envoyer, I was trying to do this favor for the whole PHP ecosystem where there was some criticism of Laravel like, "Hey, Laravel doesn't really..." They're of all about Laravel, they don't really contribute back to the PHP ecosystem. And Envoyer was a concession to that.

Matt Stauffer:
Yeah, exactly.

Taylor Otwell:
Yeah, a concession to that argument of like, "Hey, we actually do care about the wider PHP ecosystem. Here's this tool that any framework can use or any host can use, not just Forge." We didn't even put it on a Laravel domain. It's Envoyer.io unlike all of the other Laravel products.
So anyway, historically Forge and Envoyer didn't really know about each other, and that just started to feel really silly. So a few weeks ago, or maybe a month ago, we launched a new feature in Forge where you can say, "Hey, I'm using Envoyer to deploy this site," and Forge lets you link in your Envoyer API token. And the Forge UI more intelligently reacts to the fact that this is an Envoyer project. If you go to the environment variable tab, it tells you, "Hey, you actually need to manage this over on Envoyer," and links you over to the page and the deploy tab, it says Deploy with Envoyer, and you click the button and that actually triggers an Envoyer deployment from Forge. So it all feels much more integrated.
So what we launched today that's actually new is the ability to link an existing site to Envoyer. So previously a month ago when we launched that integration, you could only do that for new sites on Forge, a new site that we're configuring fresh. But there's a lot of Envoyer sites already on Forge, probably literally over 1,000 I'm sure. So you can link those existing sites to Envoyer. And how that works is basically you go into Forge to that existing site, there's an Envoyer tab, Forge will see that this site is using current/public as its web directory, which is typically what Envoyer would use for its web directory. And it's like, "Hey, it looks like you might be using Envoyer, are you?" And you can say, "Yes," and select the Envoyer project from a dropdown that that site is linked to. And then Forge just knows about Envoyer at that point and everything works well and you can deploy with Envoyer from Forge and yada, yada yada.
So anyway, that was a collaboration between James Brooks and Joe here at Laravel, and I'm really happy with how that turned out and I honestly feel really silly that we didn't do it years ago. But anyway-

Matt Stauffer:
right now or not?

Taylor Otwell:
I think it's a pretty big upgrade.

Matt Stauffer:
I love that. And as someone who uses Envoyer pretty frequently, I'm really happy to hear that. What our flow would often be is we still want to use Forge to spin up the site and the server. So we'd use Forge, spin up the site and the server, and then I'd go to the domain and it's like, "All right, do you want to add the code or whatever?" And I'm like, "Oh no, I remember now when I'm using Envoyer, this is where I just let it just sit there in this awkward intermediate state."

Taylor Otwell:
Yeah, very weird, awkward state.

Matt Stauffer:
And then I go over to Envoyer and I set it up and it has no knowledge of Forge. And so then I'm doing things in Envoyer and I get why I was there and I was just like, "Yeah, this is just the nature of the thing," but now that you're naming it, I'm like, "Yeah, that's a very non-Laravelly way to experience it. So knowing now I can just do it because I think of some of the steps of setup that had to happen in an Envoyer as being more like a Forgey thing. And so now you're telling me I can do those in Forge. I'm like, "Great, I love this."

Taylor Otwell:
So I think what's cool is when you configure a new Forge site that's going to use Envoyer, it actually uses the Envoyer API to add the server to the Envoyer project to add the SSH key back onto Forge to make sure the connection is good.

Matt Stauffer:
That's great.

Taylor Otwell:
All of those steps that were so manual now is all automated, which is good.

Matt Stauffer:
That's so great. Love an API token that you can just do that kind of stuff with.

Taylor Otwell:
Yeah.

Matt Stauffer:
All right, well we had one last topic for the day, which is we keep getting this same question over the years of podcasting. And also I'm sure you get this on Twitter, so I just wanted us to cover it, which is people keep asking about what your experience of working with pull requests to the framework is like. And we've got things like what's your process of working with pull requests and why did you merge somebody else's pull request when you didn't merge mine doing the same thing? And are there things that have been PRd multiple times that you didn't feel great about, you would merge them as great or things you regret merging? So just in general, people are really kind of asking about that. So could we lead with just what is your general thought process and approach when a third party PR comes into Laravel?

Taylor Otwell:
Sure. So I pretty much start every morning by looking at PRs across the whole Laravel organization because I'm really the only one that merges PRs across the whole organization and has the final say into what is merged or not. And we keep that number pretty low. So I need to deal with about 15 pull requests a day to keep it sustainable. So what I'm looking for, I mean first of all, I'll look at the amount of files changed in the pull request. If it's like 40 files, I start getting nervous, mainly because Laravel is just used so widely throughout the world and it's so easy to break an edge case because someone is using Laravel in a way we didn't expect. So I'm very cautious about any potential breaking changes and I'm pretty good at identifying where they could be in any given pull request. So typically I'll look for those. I'll see if the pull request has tests. So there's two canned responses I have on GitHub. One is if the pull request doesn't have tests, there's an insufficient pull request canned response where it says, "Hey, thanks, but this doesn't have tests, so feel free to resubmit it when it has tests," or something like that.
And then the other thing I'm looking for is do I want to take over ownership of this feature forever because maintenance ownership, I mean. And that plays into how many files are changing, how complicated the code is and what bang for the buck am I getting on this pull request, which is something I mentioned before. So the best pull requests are least amount of files change, but huge user experience impact, that's like an instant merge PR. Whereas a bad PR would be a lot of files change, very minimal developer experience improvement, probably not going to get merged. So I'm looking for bang for your buck and yeah, do I want to maintain it forever, because there have been situations where someone is very involved in the framework, they send in a lot of PRs and then maybe they change jobs, maybe they have an illness, maybe something happens in their life and they're just not around anymore. Literally they're just gone and now the feature is ours and we have to maintain it and know everything about it and fix bugs in it. And so do I want to take on that responsibility?

Matt Stauffer:
Yeah.

Taylor Otwell:
And to your second point about PRs that come in several times and they get closed and then they finally get merged, which is something people get a little bit frustrated about sometimes. And I think when I say no to a PR, it's sort of no for now because sometimes a pull request will come in and it will be a feature request and it may be the first time I've seen it and I'll think, "Eh, I'm kind of on the fence," so I'll close it. But if it comes up again or maybe three times or four times, it's like "Hmm, maybe there's actually some demand for this and some needs for this more than just one person." So extreme examples of that would be the app models directory, which was requested thousands of times before it was like, "You know what? Fine."

Matt Stauffer:
Let's do it. Yeah.

Taylor Otwell:
People want it, apparently. Another one recently is actually the make a view Artisan command, which had requested maybe seven or eight times. And finally once we built Folio and Volt actually where we felt like we were doing a lot of view centric work, Nuno was like, "Taylor, we have to do make view, it's time to do make view." And once we merged it, a couple of people popped up and it's like, "Hey, I did this three years ago," and I sympathize with that, but it just, it kept coming back up and finally it felt like, okay, the need is there at this point.

Matt Stauffer:
Yeah, yeah.

Taylor Otwell:
I don't know how to fully solve that problem, but that's sort of the thought process behind it is just seeing if it's a need that bubbles up again and again and validates itself by repeated attempts at pull requests.

Matt Stauffer:
I think there's also just a concept there of we are as open source maintainers, we are grateful for the PRs that come in from other folks and want to make sure that people get as much credit as possible, but in the end, we have to do what's best for the framework, which requires us to, or the tool or whatever, which requires us to do what's best for our sanity. Because if we can't take on this responsibility to maintain the thing, we're going to be in a bad space. So what that means is prioritizing credit where credits due as much as possible, but at some point doing what makes the most sense for us as a maintainer. Because as the maintainer who decides what to merge and takes on the responsibility for maintaining it, it does have to be your decision, your vision and your burden in the end.
So all these things are at most making it easier or harder or whatever towards the maintainer's desire to provide something to the community and also to take on that responsibility to do the work to continue providing that to the community. And so yeah, I would never want anybody to feel like they're not being considered, whether it's because theirs didn't get merged and somebody else did, or theirs didn't get merged and then you wrote it or I wrote it in our respective things that we maintain. But in the end, it is not about credit. That's not the most important thing. The most important thing is providing a good experience for the community, which requires us to be able to work in this flow that's not always just about giving people credit. So we can both say, "I want you to get credit for your idea, but that's also not the most important thing. And sometimes this is just how it pans out."

Taylor Otwell:
Yeah, pretty much.

Matt Stauffer:
Cool. I used to ask you all the time, is there anything that somebody could PR to Laravel that you'd be grateful for them to do? And I think it got pretty early on to the point where you're like, "I don't know because if we had the idea we would've done it." But it still seems that there are times where you do get a PR where you're like, "You know what? I could have had that idea or whatever," but I'm getting insight into how people use Laravel or would like to use Laravel based on these PRs. So it doesn't seem like you're at a point where you're like, "Nobody should ever PR anything." There's still welcomed contributions through PRs.

Taylor Otwell:
Right. Because yeah, like you said, businesses are extremely varied and they surface blind spots I would have to the framework where it's like, "Hey, this aspect of the framework actually really sucks and here's why." Because I'm doing this in the real world and if I'm not doing that in the real world, I would never see that, so there's no way I could know to fix it. So yeah, still a lot of value there for sure.

Matt Stauffer:
And one of the things that really helps for those types of PRs or PRs where someone describes a use case that is made better by this PR that is hopefully minimal number lines of code and helps share how that use case is not just something that's just them. Some of the ones where I'm like, "You did a great job of describing your use case and I just don't think anybody else is going to have it." Whereas somebody else would describe a use case and I would get 35 emoji responses on the thing saying basically effectively communicating, "Hey, that's my use case as well." And I can imagine how a lot of other people have that use case, that makes it much more compelling. "Yeah, that's not me. I've never used Valet that way, but wow, I get why you care about that."

Taylor Otwell:
Yeah.

Matt Stauffer:
Well, that is our last topic for the day. Is there anything else about how you handle PRs or things that have been PRd or things that you regret merging? I assume you don't want to talk about that, but is there anything else about PRs that you want to share before we cut for the day?

Taylor Otwell:
Not really, other than if you're thinking about submitting a PR, keep in mind that whole bang for the buck thing. Try to make your PR hopefully as simple and small as possible, but a big impact on user experience. And not just for Laravel, but I think for any open source project, I think those are the kinds of PRs they want to see and merge.

Matt Stauffer:
Yeah, I love that. So small code change, big impact, preferably big impact, not just for the most people, but also the most benefit for each individual person. And I forget what the third one was, but yeah, you said those for sure. So sweet.
Okay. Anything else you want to chat about today, Taylor? Or do you feel like we got through things on your mind?

Taylor Otwell:
No, that was fun. We covered a lot of good stuff.

Matt Stauffer:
I know, I know in only 30 minutes. Go us. Well, thank you all for hanging out with us for today and we will see you all in two weeks. So take care.

Taylor Otwell:
See you.