The Laravel Podcast

Matt Stauffer:
Welcome back to The Laravel Podcast: Season Four. Today, we are talking about packages with Freek Van der Herten and Marcel Pociot, the package master authors. Stay tuned.

Matt Stauffer:
All right. Welcome back to The Laravel Podcast: Season Four, where every single episode is about a single topic. And today we're talking about the last topic of the season. I'm very excited about this cause I have two of my friends, not just one to talk to today about this topic, two people who are completely knowledgeable and capable and reputable and all this kind of stuff in this particular topic. So I'm going to do, I know that you all know, like sometimes I'm like, "Oh, I don't want to make sure that I make the valet." People feel better than whatever. So I always do it alphabetical. So we're going to start with Freek, can you introduce yourself and say, Oh, sorry. The topic is packages. And so we're going to talk about packages, package ecosystem, package development, all that kind of stuff. So, Freek, could you say hi to the people and tell them how you introduce yourself when you meet people. Whatever way we meet people in the middle of a global pandemic.

Freek Van der Herten:
Hello everybody. Yeah, I'm Freek. Usually when I introduce myself to people, I don't say what I do for work. I just say, "Hey, I'm Freek. How are you?" That's maybe my introduction. I'm like a modest Belgian who doesn't give away much of himself in a first introduction, but since this is a podcast where people are listening for like the package development and Laravel knowledge in general. Yeah. I'm the goal owner of a company called Spatie. We do a lot of Laravel development and we do a lot of open source development too, which gets used in the projects. That's like the very short intro, I guess.

Matt Stauffer:
Perfect. And then, Marcel.

Marcel Pociot:
Hey everybody. My name is Marcel. My natural introduction would also probably just finish right there. So it's always weird to talk about yourself, but I also have my own company. It's called Beyond Code, where we do mostly developer tools and video courses for everything around the Laravel ecosystem. That's about it.

Matt Stauffer:
Yeah. It's very interesting to me because I've discovered it's very much a cultural thing about whether people instantly jumped to talk about what you do versus not. So there's some cultures in which, what do you do is the first question that someone asks somebody when they meet them and then some cultures in which it's absolutely not the original top of conversation. It's almost considered like uncouth to just jump right to that. And so I've always been fascinated because I definitely grew up in a space where like, "what do you do?" would be one of the first questions you'd ask an adult and spent more time since we're places where like I can spend multiple days with somebody and not have any idea what they actually do for work, because it's like, is that really what defines us? So anyway, I appreciate you guys bringing that up.

Matt Stauffer:
I know I'm the one who asked the question, but it's really interesting you said that. Okay. So, today, we're talking about packages. So before I even blab on about what packages are in the world, I want to talk about what is a package. And once again, we're going to go alphabetically. I might do reverse alphabetical later so that Marcel gets to start sometimes, but let's keep alphabetical for a minute. So we're going to do our traditional question of explaining it to a five-year-old. So as folks with kids, I think we're a little bit, it's a little bit easier for us to actually be able to explain things to a kid, even if your kids aren't five years old. So let's see how you do. So I'm just going to ask each of you to do the same thing. Explain what a package is in our world to a five-year-old. So Freek, can you start?

Freek Van der Herten:
Yeah. Sure. So when you think of like a web application and if you can think of it, like some as bricks, just stacking, stacking together, like Lego blocks.

Matt Stauffer:
Marcel's face tells me that's the same, what he's going to use. That's okay. Keep going, Freek.

Freek Van der Herten:
So if your application is built up by bricks, what is a package? A package is just one kind of brick in your application. You would need for an application, you need like a red brick to go into your application. And then the package is basically your sack of red bricks. And you can have like the same red brick in other projects as well. So it's basically sharing building blocks and it has many advantages, but I don't want to take too much speaking space because Marcel wants to answer as well.

Matt Stauffer:
Yeah. And we'll definitely get into that. That's a really great introduction works with kids. So Marcel, imagine that Freek had not just said what he just said. You don't have to compete. I just want to hear, how would you pitch this?

Marcel Pociot:
Yeah. So I can tell that we both have kids that love to play with Lego. That was my immediate thought as well. When I thought about this and it's really hard to come up with something different because I think this really explains it well that those are just building blocks that you can use to extend your application. And then you can just take them and share them across other Lego buildings and use the same building blocks and share it. I think that's like the perfect explanation for the topic.

Matt Stauffer:
Yeah. I love it. I like that you all did, I think, a better job of explaining it to a five-year-old than I did in my brain, because in my brain I was always reaching for something a little bit more complex. I'm like, "every single time you build a car, you have to build a seat. Well, maybe you had a whole thing of seats." It makes sense, but I think that sometimes complicates it a little bit. So I just, I love this idea of the building blocks, the Legos. If you both came up to the same conclusion, then obviously it's a good explanation. Right. So, okay.

Matt Stauffer:
So I think Marcel, I'm going to ask you to start on this one. If you were to try and explain to somebody who had, cause we didn't have a package ecosystem in PHP for a long time. Even when we had pair packages, it was very complicated, stuff like that. So until Composer, we really didn't kind of have that same concept of it that everybody else did. If you were to talk to an old PHP developer who just hadn't had the experience to work with packages, could you explain to them what our packages generally in the PHP world and kind of what's the ecosystem around them?

Marcel Pociot:
Yeah. So, I mean, me being someone that also works with PHP pre-Composer era, back then you were basically just copy-pasting classes from PHP classes, which is a website that still exists. And then you would go and copy like a whole bunch of files or download the zip file. And now with packages, you get not only the source code of the thing that you want, the specific tool, but you also get all of the dependencies bundled within it. So, packages, I think once again, the Lego example is really good. It just allows you to share common used codes in PHP with others, and then basically just package everything together in just one bundle that you can then reuse throughout multiple projects.

Matt Stauffer:
I love that. And since we're talking a little bit about the history of it, Freek, could you talk a little bit about how using version control and packages kind of allows us to do things that we couldn't when we were just downloading zip files. What's the role of a versioning system and Packagist, which is the site we use to deliver them, and Composer. What role does that play in packages relative to ...? Let's say I had a package and the PHP classes day, which was really just, "Hey everybody, here's some code." What's different between that? Marcel just told us a few of them, right? Like we get our dependencies bundled with it and everything like that. But what are some of the other differences that come along with using a version system and all that kind of stuff to deliver them?

Freek Van der Herten:
Well, let me start off with something that is seemingly really strange for the modern PHP developer. I think when you still had the PHP classes and you need to download code into your project, what you needed to probably do as well is to load those classes and not all classes did it in the same way. So, you have your own load of file where you, the auto loading part of all of your stuff there. And with modern package development and it's basically just Composer that whole auto loading thing goes away because it's standardized. All the packages do it in the same way. Now, to answer the other part of your question. So, if you would just create or grab a class from PHP classes and you need to update that, that would be a manual process to do, and it can be tedious.

Freek Van der Herten:
Imagine that you have maybe four or five projects that need the same class. You would copy paste it into your own project with how would you know, like I did it right correctly because if you do manual stuff, you're going to make mistakes because we're all humans. Whereas with modern packages and with Composer, it is just a command and it's automated and you really know this is the right version that I'm going to get. I'm not going to jump into that now because that's like a section on its own. I think we also have, I think, a semantic versioning where you can specify. I only want to have bug fixes or I only want to have new features or I want to have the latest version, but I have to adapt my codes a little bit on it. So in general, it's just much easier to pull in updates because it's just a command it's automated. They can run the same commands across all of your projects.

Matt Stauffer:
Yeah, that's great. So normally the next section of this would be when I would say, when's the last time you used blah, blah, blah system, obviously that's even silly. But I would say, I am actually super curious, which package, Marcel, that you did not create do you install on every single application or almost every single? What's what's your most common?

Marcel Pociot:
I think without doing some advertisement now, I think it would be Ray from Spatie because this is just a really good helper package. Besides that it would be the Laravel IDE Helper one. So I guess it's mostly just little helpers during development. I Don't have this one package that I always use within all of my projects. It really just depends on the project itself, but all these little tools that help with development.

Matt Stauffer:
I think that's a perfect introduction to the idea that packages can be something that aid the actual application in doing something that's doing, or they can be something that we call dev packages. And so it goes, instead of require, it goes and required dev. And those are things that are meant to be an aid to us in the development process, but they're not actually a part of the application functioning.

Matt Stauffer:
So, I really appreciate you bringing that up. And we've already done an episode that that talks about Composer. So we don't need to dive too far into that. And if you all are listening and some of these things are unfamiliar, I'd recommend you go take a listen to the Composer episode. But that's a really helpful note that if there is anything you're going to require every single time, it's going to be about development. Cause lots of the other things that aren't development tools, often are specific to the needs of the application you're developing. And if every single application needs something in production, there's a good chance it might just make its way to the core. Anyway, Freek, same question for you. Of the things you have not created, is there anything that you bring in on every app or almost every app?

Freek Van der Herten:
Well, while Marcel was answering, I opened up a project to take a look because my normal answer would be Debugbar because it's the most common one, I think, because it's just so powerful. But also, I wanted to see if there is like another one that I could mention. And then, I'm coming out on the other one from Barry vd. Heuvel who created the Debugbar and that's the IDE Helper. So this is a package that can help your IDE. In my case, PHP storm understand some of the magic of Laravel. So, you get like better all the completion and stuff. And that's something that is on every project.

Matt Stauffer:
I love that. And for-

Freek Van der Herten:
Thanks. Thanks Barry for both of those.

Matt Stauffer:
So can you say his name again for me so I can get it right in my head?

Freek Van der Herten:
I think if you pronounce it correctly, it would be Barry.

Matt Stauffer:
And his full name, sorry. vd. Heuvel?

Freek Van der Herten:
Barry vd. Heuvel.

Matt Stauffer:
Heuvel. Okay. Thank you. Cool. I've never actually heard it said out loud until right now. So it took me a second to figure out. So for anybody who doesn't know, that's Barry and then V-D-H-E-U-V-E-L. And if you've ever used the Laravel IDE Helper or the Laravel Debugbar, those are both things he did. Is he Fruitcake or somebody else? Fruitcake?

Freek Van der Herten:
I think he is. I think he's for Fruitcake. I think he's the founder there.

Matt Stauffer:
He also created the Laravel course package that so many of us used before it got integrated into the core of Laravel.

Matt Stauffer:
This is really helpful because it kind of gave us a little bit of context and grouping around the type of packages we're talking about. If you were to think about packages, are there any other kind of sub groupings and this question's to both of you. Are there any other sub groupings of type of package you think about? So we just talked about their packages that actually function in the application and do something application, which would probably require and then there's applications that aid us in development, which we're probably going to live in require dev. Are there any other sub groupings among those two that we should think about, or as you think about it, are those kinds of mainly how we organize our packages and in our minds?

Marcel Pociot:
I think we also have to differentiate between package dependent between application dependencies and global dependencies. So for example, things like the Laravel installer or your tool, Lambo, would be a package, but it's not something that you install into your application. It's a global package which is available throughout your whole development system.

Matt Stauffer:
That's a really good point. Let's talk global. I think global is going to be a much smaller section, so let's just kind of get it out of the way, but I really appreciate you bringing that up. So other than the Laravel installer or a tool like Lambo or Valet or something like that, are there any other kind of globally installed Composer packages that you use in your day-to-day work?

Freek Van der Herten:
I think those two for me are the main ones, I think. I'm trying to think if there's anything else I use. No, Valet, isn't the package. That's more of a tool on itself.

Marcel Pociot:
Hmm. For me it would be Expose. I'm biased but I'm using that one instead of NGrok.

Matt Stauffer:
So if anybody doesn't know, Marcel has a tool called Expose. That is a PHP powered version of basically what NGrok does. So it allows you to share your local development sites with an actual public URL. So you can expose up to web books or you can give it to somebody else to view directly from your machine. I'm sure there's probably some other ones, there's probably another one that I made that I use because I love little command line tools like that, but none at the top of my head.

Matt Stauffer:
Okay, cool. So, let's say we're primarily talking about application dependencies. Within application dependencies, are there any other sub groupings or does it really just kind of fall into? I mean, we can make some arbitrarily, right? These ones are about databases. Here's the thing.

Freek Van der Herten:
I think you could also make a distinction between very large packages and small packages. They feel a lot more different. Some of the packages that also have UI components too, that we can touch upon that what you can do in the package. Most of the packages don't, but some of the big ones, they have a whole different feel to them, I think.

Matt Stauffer:
That's a good point. Can you guys help me have an example of one of the smallest packages you use and one of the biggest packages that you've seen so we can actually set that in people's brains?

Marcel Pociot:
I think there are a lot of smaller ones just to help her functionality, like converting XML to an array and stuff like that, which is something that is just way easier. If you let a package handle it, then do it with simply XML yourself. Things like that.

Freek Van der Herten:
And I think maybe an example of a bigger one could be Lifewire or something which just grabs its hooks into the view system of Laravel. That's like a totally different beast than a small helper package.

Marcel Pociot:
And for the UI, it would be something like Nova, which is a package, but it's basically an application on its own wrapped inside a package.

Matt Stauffer:
That's a great point. Okay.

Matt Stauffer:
So we're talking about all these different types and sizes of packages and kind of what involves in them. I think it's a really good moment to talk about two things. First of all, actually, second of all, let's talk about all the things that packages exposed. But first of all, what are all these Illuminate packages? And I know that we probably covered it in one of our previous ones, but if someone looks at the Composer.JSON of the Laravel app, they're going to see actually not just Illuminate. They're going to see a whole bunch of stuff out of the box. Like I'm trying to see what's the latest version.

Matt Stauffer:
Honestly, it might be worth us doing just a quick look at the Laravel framework itself to just try and figure out like, what does it, or sorry, not Laravel framework, Laravel slash Laravel, to see what do we actually get out of the box? We don't have to go through all of them individually, but first of all, I think let's just start with a real quick reminder. Can either of you just kind of give us a quick reminder of what the Illuminate packages are?

Freek Van der Herten:
Yeah, sure. I'll take this one. So Laravel itself is built out of packages itself as well. Going through a project here now and I'm opening it up. So Laravel itself consists of several packages in the Illuminate namespace. I think Illuminate was the code name of Laravel and these are not your regular kinds of packages. I think some people would say these are tightly integrated packages. I'd say they are just beautifully working together and they're built for each other. And it's basically a way to organize code, to have all the functionality of the art system goes into the package. All the functionality of the broadcasting system goes into the broadcasting package. And it's basically just a way of organizing code. That's that's how you should think about it.

Matt Stauffer:
Yeah. In theory, you can use many of those packages independently. If anybody's interested in that, I have a project called Torch where I actually show you how to use each package on its own. And it's not just on its own, like often in each of those examples. You'll probably new up an Illuminate container and then you'll pass it into your Illuminate database thing you're working with. So, they depend on each other a little bit, but you don't have to have the entirety of layer well, to work with them which wasn't the case originally. And Taylor's put a lot of work into trying to make that possible for folks.

Freek Van der Herten:
That's why I'm here at, I should thank you for those storage things because I've used them, I've read really horrible Frankenstein projects, Core Zend Framework, but it's uses blade shoes and the coffee. And that made the whole Zend experience much better.

Matt Stauffer:
And that's where it came from. We were converting a CodeIgniter app that we had running for ages and I started doing Laravel and I said, this needs to Laravel. And so I started bit by bit just every time we'd convert something in, I'd add it to Torch. Basically, that's the story. And then a lot of people have said, "Hey, when I'm working with legacy stuff, I still want modern sessions. I still want modern Eloquent, or whatever."

Matt Stauffer:
I'm happy to hear that though. So Marcel, if you look at the Composer.JSON, for like a modern Laravel app in Eight.X, can you walk through the required block and just give us a real quick note? It's funny cause I'm seeing Laravel course. I was thinking that Taylor recreated Laravel course. No, He just actually brought the Laravel course package in. But, can you kind of walk through those packages and just kind of tell us what each of them is doing?

Marcel Pociot:
Yeah, sure. So the first one that we see is actually not a package, but it's a PHP, which is like one extension?

Matt Stauffer:
Cause normally it's extensions there, right? Like PHP is the only one that's not an extension that we use this way.

Marcel Pociot:
Yeah. So in there we basically specify the version constraint of PHP itself that Laravel project needs. And with the latest version, it's 7.3 and up or PHP 8, than it would be the proxy package from Chris Fidel. That's the right way to pronouncing, I think. And the proxy package basically allows you to define a trusted proxies where things like SSL or the IP address, if you want, for example, to retrieve the IP address of the incoming request and the request is going through a proxy, for example, in Vapor or if it goes through one of those AWS proxies or Cloudflare, thing could adds this as a proxy so that you got the real IP address instead of getting the proxy IP address. Then we have the course package that we briefly mentioned, which allows you to set up cores rules, which is probably something that everyone that ever deals with APIs runs in.

Freek Van der Herten:
And gets mad about sometimes.

Matt Stauffer:
And we covered that in the episode with Rizqi. So, if anybody didn't get a chance to listen to the security episode, that was freaking fantastic. He's brilliant. So take a listen if you've gotten mad at courses and haven't heard that episode, go, listen.

Marcel Pociot:
Next up is Guzzle, which is an HTTP client, which Laravel then uses to build its own HTTP client using the HTTP facade on top off to simplify things. And then we have the Laravel framework package, which like we said, we have all these Illuminate packages and they basically get builds automatically out of the framework package, which sort of includes all of them. So instead of listing all these Illuminate packages, we just say that we require the framework. And last but not least, we have Tinker, which gives you the PHP Artisan Tinker command, which was in the core. And then it got pulled out into its own package.

Matt Stauffer:
Yeah. And then note there, before I asked Freek to continue, Taylor has often kind of found himself in circumstances where individual tools in the framework get to a point where they're developing at a different pace or the dependencies are sometimes problems for people and he'll extract these, not because they're more optional, they still come out of the box, but it's just helpful to develop them outside of this context of the Illuminate framework or whatever. I can't remember the specifics around Tinker, but that's definitely kind of, so I don't think that this is assigned to anybody that now Tinker. It doesn't matter as much, if it comes out of the box, it's still attended to be used out of the box.

Marcel Pociot:
And I also think that with the Laravel release cycle, if it's in its own package, then it's basically out of the specifically released cycle that is for the framework. So if for whatever reason, we want to have a new major version of Tinker, we could do that without having to rely on the standard.

Matt Stauffer:
That's a really good point because it actually can be. And it also can be the opposite. If, Tinker doesn't change very often, you can see Tinker's constraint is at 2.5 right now. You don't have to constantly be bumping versions of Tinker when nothing's really changed. And of course, just little plugs and I'm trying to not make this a full plug episode cause we'd never talked about anything else because you all both have so many things to plug, but I will plug that. Marcel has a great tool called Tinker. Go look it up. It's Tinker in the UI. All right. So Freek, can you kind of walk us through the required dev block of the Composer.JSON?

Freek Van der Herten:
Yeah, sure. So require-dev, let's first explain why it is separate from regular require. So, require, that's what your application basically needs and that's the packages that you are going to pull in on a production environment. Require-dev, those aren't needed by our application code itself, but these help you test your code or provide tooling to help you write the code. And if you deploy using a sensible strategy, then these packages only will get installed locally, maybe on staging, but not on production. You probably won't need it there.

Matt Stauffer:
Yeah.

Freek Van der Herten:
So let's start off with the, I think six packages that are in there. So the first one is already a very fun one. It's called Facade Ignition, and it's something that Marcel and our team have co-created. And this package basically contains the error page that you see whenever you mess something up while coding your application, so it shows the error messages, so it shows a trace, and maybe a solution. So, that's Ignition.

Freek Van der Herten:
Then we have Faker HP/Faker. This is the library where you can just generate the pieces of data that you can use in your tests. So if you want to have an email address, then you can ask the Faker library, "Give me an email address." Or if you want to have a number between certain limits, then you can just ask Faker that. Yeah, tons of functions to help you generate fake data.

Freek Van der Herten:
Next up we have Laravel Sail. This is I think the newest one here. This provides functionality to interact with Laravel's default docker environment.

Freek Van der Herten:
Then we have Mockery. This is a package that you'll use in your test to mock objects. And this could basically be, yeah, I think an episode on its own.

Matt Stauffer:
Yep, definitely.

Freek Van der Herten:
So a mock is basically just a class that mimics another class, and you can basically test which kind of behavior it has. But yeah, that's basically a listen on it's own.

Freek Van der Herten:
Then we have another package by our friend Nuno Maduro. It's called Collision. And this one basically gives you very nice error outputs in the console. I think he showed this at Laracon Online, I'm not sure, or it's a talk I saw with him before. But if you don't have collision, you get a really nasty error message, and this one makes it really, really good. So I think it's very nice to have it in there.

Freek Van der Herten:
And the last one, it really needs no introduction because everybody that has been developing Laravel for a while has gotten in touch with this package. It's called PHP Unit, and that's basically the de facto test runner for PHP until Nuno reaches world domination with tests. We'll see if that happens. And those are the-

Marcel Pociot:
Which still uses PHP Unit, just to...

Freek Van der Herten:
Yeah.

Marcel Pociot:
Yeah.

Freek Van der Herten:
Indeed.

Matt Stauffer:
Love it.

Freek Van der Herten:
Its world dominion will be built upon PHP units.

Matt Stauffer:
Yes.

Marcel Pociot:
Yeah.

Matt Stauffer:
And that's a really good point though, because I think a lot of the things that we rely on, just because we see packages here doesn't mean there's not other packages that these ones are relying on. So if you look at, for example, Laravel framework, the Illuminate classes have very significant dependencies on the Symfony classes. And so if you are new to the PHP world, you may not even know what these Symfony classes are, so just a quick note about that.

Matt Stauffer:
Symfony is another PHP framework, and they originally pioneered this idea and the PHP world of creating your internal dependencies as classes that can be used by everybody else. And I think their creator actually gave a talk saying, "Hey everybody, here's all these classes. Why don't you go create amazing things with them?" And Laravel took that to heart and Taylor actually took those classes.

Matt Stauffer:
So when you're dealing with, for example, a representation in PHP of a request, it's a Laravel request object, but you'll see it extends a Symfony request object. So as you're learning to source dive and dig into what methods are available to me here or what does this type-in actually mean, just note that each of these dependencies often has dependencies underneath them. Ignition is built on top of Whoops, right? Am I right that it's built on top of it?

Freek Van der Herten:
It used it, but it could be independent of that. But as of now, it's built upon it.

Matt Stauffer:
Yeah. And I'm sure plenty of the other ones here, like Collision. I know that Nuno knows a lot about working on the command line. And so every single time I look at his packages, I often see underneath they're using this color format or in that table format, so I'm sure that Collision is built on a lot.

Matt Stauffer:
So it's helpful for us to know that when you look at a package and you want to thank that person, also note what else is going on underneath there, not only to give them credit, but also if you are considering doing similar work in the future, but this package doesn't do exactly what you want, you may find that some of its dependencies are doing that one piece you actually care about. So as you think about packages, or maybe you one day being a package author, it's really good to take a look at the composer.json of anything you really appreciate.

Marcel Pociot:
And just to chime in on this, I think that's also really important when you think about ways of how you could create your own package. It's not just about coming up with this brand new genius idea that nobody ever thought of. A lot of times it can also just be take this dependency, which looks too complex for you, and then create the API that you want on top of that, and then basically just wrap it. And even if it's just for yourself, so it doesn't need to be this one package that nobody ever thought of, it could just be some decorating package.

Matt Stauffer:
I love that. And I mean, the HTTP facade, the entire tool in Laravel was originally a package that Adam Wathan made called ZTTP, which was him saying, "Guzzle is miserable to work with. What is the API I actually want when I'm interacting with external calls?" Basically wrapping around curl or whatever. And that's what ZTTP was, and then he and Taylor basically rewrote it and put it into Laravel as HTTP. So I love that note.

Matt Stauffer:
And one of the things that Taylor and Adam have both mentioned often on the podcast is that it's their own intolerance for inconvenience that is what leads them to create some of their best tooling. It's like, I deal with this thing every single day, but it just drives me bonkers. Well, why don't you write out the API that you'd like to work with, and then maybe you can create the package that gives other people that same kind of experience.

Matt Stauffer:
There's also some other ways to think about package creation that I think is really worth noting. Freek, you mentioned this on the podcast a while back, but you mentioned that a lot of your first packages that you released under Spatie was actually... They were Zen packages that you... I don't know if you all had written them or other people had written them, but they were from the Zen world, and that you said, "Oh, we want these available for the Laravel world." And so you tweaked the code, of course because it's PHP, the PHP classes moved fine, and you probably just had to rebuild the bridge between those classes and the framework, and then you released it as a Spatie package.

Matt Stauffer:
So, sometimes it's even taking something that you or somebody else has written. Of course, if it's somebody else it's with their permission, and lots of credit and everything like that, and repackaging it saying, "Hey, I want to make this available to other people." Adam Wathan had written a thing about how to do method overloading in PHP and he put it in a gist. And I said, "I don't know if anybody's ever going to want this as a package, but what do you think if I wrap this thing up as a package just in case somebody ever wants it?" And he's like, "As long as you're the one willing to take on the maintenance responsibility, go ahead."

Matt Stauffer:
And so I've used it in the package like once or something like that. It's probably the least popular package I've ever made, because not a lot of people are doing method overloading. But again it's that same concept, I was like, I want it to be accessible if somebody wants it. So it's cool to think about what are the difference, especially for you two. I mean, since we're already here, are there any other inspirations you want to list out for what has motivated you to make a package at any particular moment?

Freek Van der Herten:
For me, it's basically what I need in a project. So, if I need something in a project, and I think this could be useful for others, then I create a package. And it's also the thing that you mentioned before. It's just a low pain tolerance to things that are difficult. They should be easier to understand. I think all three in the skull have this urge to make things better and easier. And those are mainly the two big motivations for me. Maybe sometimes I also make a package because just a subject interests me and I want to learn a little bit from it. I'm by far the most motivated if I can use the package myself. That's my motivation.

Marcel Pociot:
For me it's sometimes the other way around.

Matt Stauffer:
Yeah?

Marcel Pociot:
Which, for example, with Expose, this ngrok alternative, I didn't like the UI of ngrok, so I wanted to build something nicer. But going for, "Hey, let's rewrite this in PHP," might be a bit weird. So it's also just this way of seeing, can I actually do this? Would it work with PHP or same with the Laravel Websockets package that I did together with Freek? I guess that's also not the typical PHP package. Writing a Websocket server in PHP.

Matt Stauffer:
Yeah.

Marcel Pociot:
So this is really something that interests me in package development is just to see-

Matt Stauffer:
Can it be done?

Marcel Pociot:
Can it be done? Yeah.

Matt Stauffer:
I like that. That's cool. Yeah, I love that, because I think one of the things that interests me a lot is that things that I know I don't know how to do. I think I'm a little bit less likely to push the bounds of what can be done than you are, Marcel. But I think for me, it's often like, well, I want... The same thing that Freek was talking about, I want this API to be more enjoyable, but I know that I don't know how to do it. This package would be a really great opportunity to learn it, right?

Matt Stauffer:
And so Lambo originally was me recognizing that every single time I create a new project, I do the same things over and over and over again. I bet you can do that with bash scripts. I don't know how to write bash scripts. I'm going to teach myself how to write bash scripts and then build this Lambo thing. And then later somebody came along and said, "Well, what about Laravel Zero instead of bash scripts?" I was like, "Well, I don't know Laravel Zero, but sounds like a fun thing to learn." And it took us like a year and a half, but now it's rewritten in Laravel Zero, and it's way better and way more testable. And I'd never written with Laravel Zero before that.

Matt Stauffer:
So it's a fun opportunity for me to try something that I've never done before. Even if I knew it could be done. I think Marcel, you're more like, "Nobody in the world knows if this can be done." For me I'm like, "I know a smarter person than me can do it, but I want to learn the thing anyway." So there's lots of different motivations. And I appreciate you guys talking with me about this.

Freek Van der Herten:
Okay. For me it's also a little bit sometimes for... I create a package as a vehicle to propose things to the core.

Matt Stauffer:
Yeah.

Freek Van der Herten:
I think last week even, Taylor tweeted out something that signals can now be processed in aresenal commands.

Matt Stauffer:
Nice, that's awesome.

Freek Van der Herten:
And I thought, hey, yeah. In this example, we just use Symfony, but we can make it so much nicer. And then instead of PR'ing it to the framework itself, I thought, let's create the package and then yeah, I let the Laravel people know, if you like any of these things, just steal slash borrow them.

Matt Stauffer:
Yep.

Freek Van der Herten:
I'm happy now because I can also already use this. And if you like some of it, but then it can go in the framework. And I think a bigger example of this could be BladeX, which I don't want to take or let my team take all the credit for Laravel Blade components, but BladeX was certainly a big inspiration for adding depth to the framework. So I think it's also a good as a vehicle to propose new ideas that might be a little bit too wild to include all in a short time span, but it's good to let these ideas gestate in a package.

Matt Stauffer:
Yeah, I like that. And I do want to do a big note. I am the Five Minute Geek show. A couple of years back, I did something and I think I was called Share the Shine. I'll try and find it. But for me, it's really, really, really, really, really important for people to get credit for the work that they do. It's just absolutely vital. And when I find people in the community trying to credit hog or credit grab, it really bothers me a lot, because there's nothing that is more annoying to me than people who value their own benefit over the needs and the benefit of other people, right? And that's one of the reasons why I say if you see a great package, go look who's behind that package, right? In the Laravel world, a lot of the packages that say Laravel hyphen something else, like it's the Laravel version of this, if you look at it, it's 80 lines of code on top of a PHP one, right? It's just a bridge to that one. And that doesn't mean you shouldn't use it, but know who actually did the work to do it.

Matt Stauffer:
So that was to say, I think sometimes people can build with the mindset that you just mentioned, Freek, with the intention of getting their name in the composer.json require block, because then their name will be famous or something like that. And I want everyone to hear that I think that a lot of the people who you know about have worked with Taylor or the core team to contribute things that don't get their names in there at all. I mentioned Adam, doing the work on HTTP. Adam Wathan pairing with Taylor is responsible for a good portion of our coolest features with Adam's names not attached to them at all, right?

Matt Stauffer:
And I know that's true for the rest of us because I know that Caleb Porzio, in his work on Livewire, worked together with Taylor a lot. And of course, Taylor did the work, right? But their brains were involved, right? And Caleb was involved a lot in the view components as well, because he was developing Livewire at the same time and shared some ideas with Taylor, and Taylor shared some ideas with Caleb. So it's not as if Taylor's just stealing other people's ideas. No, not at all. But when we contribute, our greater desire is for the broader community to have access to these things, not for us to create a package that then gets included.

Matt Stauffer:
So I love what you said. What you did not say was, "I created this little component around handling signals in Tinker so that that component could be the one that got included in the require block." To me, everybody, that's not the way we should be doing these things. If that's the way it works, okay, cool. Like Fideloper's trusted proxy, Fruitcake's Laravel cores, it makes so much more sense for those to be brought into the core as dependencies. But a lot of the stuff that we do isn't the case.

Matt Stauffer:
I was just talking with Taylor a couple of months ago saying, "You know what? I'm dealing with this thing where my client and I are working on this thing with, we need to do basically, we have encoded JSON objects, and we want to be able to modify those JSON objects on our eloquent thing, and then save them back in. And we discovered that it actually really wasn't very easy to do that. So I threw together a proof of concept for how we were doing it. And I said, "Hey, Taylor, here's the proof of concept I'm working on. Does this make sense? Would you make any modifications?" He's like, "Yeah, I would probably split it up." Because mine handled both object and array syntax. He's like, "I'd probably split it up into one object, one array one." I was like, "Cool, we might do that, but here's the code." And then Taylor rewrote it in the Taylor way, and then put it in the core. I didn't need my name there, whatever. He's the one who helped me even think about how to write the thing in the first place, but I got to collaborate with everybody else having access to that thing, right?

Matt Stauffer:
And I just want everybody to hear that the people who you see their name publicly, there's a lot more going on where their desire is for the good of the framework. Their desire is for the good of the community, not for their name to be celebrated.

Matt Stauffer:
And I know I took way too long to talk about that, but I feel like every once in a while, when people see like, "Oh my gosh, this person got famous from making amazing contributions," whatever, their desire is to come in and be the next that person, right? I want to be the next Adam, or whatever. And a lot of times what comes up is that they do so in a way that, unlike an Adam or a Taylor, they say, "Well, they got famous, therefore, I'm going to get famous like them." But the thing is, those guys got famous by helping people, right? The two people on this podcast became reputable by trying to create things that help other people.

Matt Stauffer:
And so I just want to note to everyone in the community that, not like you're going to be caught by the police or something like that, but I'd really encourage your number one priority being helping people, not becoming popular. So, I'm so sorry. That's just a really strong thing that I'm very passionate about. So I just wanted to go on a rant about it for a second.

Freek Van der Herten:
It's an important subject. So I think you rightly took the time to say this.

Marcel Pociot:
I don't know if you want to talk about this some more, but I think one important point about this is that you mentioned becoming famous or popular packages. And I think there's this double-edged sword where if we take a look at, if I'm searching for a package that I want to include in my application, I'm obviously looking for things like GitHub stars, which shouldn't be something that I should consider, because I mean, it's just a point where people click which gets bigger based on the reputation of the people, and doesn't necessarily mean that it's a better package than something that has less GitHub stars. But for some reason-

Matt Stauffer:
We still look that way, yeah.

Marcel Pociot:
It's still something that I look at it.

Matt Stauffer:
Yeah.

Marcel Pociot:
And I also think that this shouldn't be the reason why you create a package. It shouldn't be that you want to reach 1,000 GitHub stars or anything. And there's also articles out there like, "This is the perfect readme to get 1,000 GitHub stars," and stuff like that.

Matt Stauffer:
I did not know that.

Marcel Pociot:
And this shouldn't be the motivation at all for this. So if your package solves a problem that you personally have, just be happy that you sold it on your own. And if other people chime in and want to use it, that's even better. But yeah, there's this little double-edged sword that, if I'm myself looking for other packages, it certainly is a factor that I consider.

Matt Stauffer:
Yeah.

Marcel Pociot:
Because if something is more popular by having more stars, it might be something that might be better to include.

Matt Stauffer:
And if our systems work, starring or looking at packages downloads, then those things became more starred or got more packages downloaded because more people found them helpful, right? Google is evil, but the original value that Google provided as a search engine was not linking based on... Not giving you search order based on manipulations of whatever, but by saying how valuable is this to people?

Matt Stauffer:
And if anybody doesn't know, I used to do search engine optimization. The original innovation of Google was largely around recognizing what are the signals that other people find value in this particular search link for this particular topic? And so they did all this analysis to try and figure out, and that's why their answers were so helpful at the beginning, is because if you search for fishnets, they're not just going to look for the number of instances of the word fishnet, or just the word fishnet in your domain. They're also going to say, how many other people who are talking about fishnets linked to this particular website?

Matt Stauffer:
And so it's the similar thing. If our systems are working well, we're doing a really good job of exposing valuable packages to people. And also us as people who are on Twitter and me as a podcaster, if I'm doing my job well, I'm exposing the thing that is going to be useful to you, and so that person doesn't have to be a marketing executive in order to get it out there, it's just the usefulness. Now granted, there's a little bit of the if they build it, they will come mindset. We do need to do some marketing, right? And we all laugh in the Laravel community about the marketing we do around things.

Matt Stauffer:
But again, what's the motivation? Are you marketing it so more people can use your thing and it could be become very useful? Or are you marking it because you want to be the next Adam Wathan, or whatever? So, okay. Sorry.

Freek Van der Herten:
I think this is also a good distinction between packages that we haven't made yet. You have free packages, but you also have paid packages. And motivations are totally different there because with free packages, I totally agree, you shouldn't do it for your popularity. I think a healthy reason would be just for learning and helping others. That's a basic motivation there. But for paid packages, it can be different-

Matt Stauffer:
Totally different. Absolutely.

Freek Van der Herten:
Because yeah, you want to sell it, right?

Matt Stauffer:
Yeah, yeah.

Freek Van der Herten:
And there are other other concerns there.

Matt Stauffer:
Yep. And just to be clear, because I think sometimes when people hear me go on my rants about, "Let's all just be Mr. Rogers to each other," they think that I now have a problem with people making money or getting value, those things. Not at all. If you want to sell a package, awesome. That's totally fine. If you capitalize on the popularity you got by helping people and turn it into a full-time job like Adam did, that's freaking awesome. You know what I mean? Adam worked at Titan when he wrote his first book that acted on his popularity and was able to go full-time, and I am so freaking happy for him. Caleb Porzio did the same thing, so freaking happy for him.

Matt Stauffer:
So there's nothing wrong with getting value. For me, it's more about what's the goal in the end, right? And it's a totally tiny nuance. But to me that nuance really makes the difference between, do I look at this person as one of the helpers, right, or do I look at this person as someone who's basically helping themself under the guise of helping other people? Because that's a very different, very small, but very impactful distinction for me.

Matt Stauffer:
But I know that's not what this episode is about. I'm sorry, everybody. This is just my personal passion. So, okay. So the next thing I wanted to talk about with you guys is when we're talking about packages, there's a lot of different ways that individual packages can expose functionality into your application. So I figured why don't we just go there and talk about what things that can do?

Matt Stauffer:
So, arbitrarily I'm going to randomly pick... Or actually no, I'll just say it and one of you two can pick it. I think the first thing it exposes is literally just PHP classes, right? So can one of you two tell us a little bit about what it looks like for a package to expose PHP classes into your application?

Marcel Pociot:
Sure. Yep.

Matt Stauffer:
All right.

Marcel Pociot:
So, exposing PHP classes I think is already kind of the wrong words-

Matt Stauffer:
Okay, yeah.

Marcel Pociot:
Because basically what a package does, it just tells composer and then therefore the application that requires it, "Hey, I have a number of classes that are, for example, within this namespace that get auto loaded automatically so it's available." So yeah, maybe by that it exposes it.

Matt Stauffer:
Yeah, I think so.

Marcel Pociot:
Yeah, right. And that's pretty much all that the package does. So composer basically just does the auto loading, and therefore your application just knows without you having to do anything that certain classes are available so that your package could then provide additional logic within these classes. I think that would be the simplest way to say it.

Matt Stauffer:
And usually those are under some kind of a namespace that is often your first level namespace. So I'm talking about PHP namespaces would be usually the name of your vendor, right?

Marcel Pociot:
Right.

Matt Stauffer:
It would be Beyond Code or Spatie. And then the second one would often but not always be the name of the package. And then they often will have their own sub-namespaces under there.

Matt Stauffer:
So the main thing the majority of the simplest packages do is give you some PHP to work with, right? Like, "Hey, here's a class." And somewhere that the class is defined as having these particular methods available to you. And when you were talking about converting XML to JSON or something like that, it might be a single class, maybe even with a single method, it might be just an invokable class that just literally just says, "Hey, pass me some XML, and I'm going to output some JSON, and we move on with our days."

Matt Stauffer:
And that's a perfectly valid thing, right? It's not quite the same as the JavaScript world where we talk about a left pad function that literally has one line of code or something. But it makes the API of something that's maybe a little bit miserable to work with a little bit easier.

Matt Stauffer:
Okay. So what's the next most common thing that you guys think, and either you can answer in this, that a Laravel-facing package would expose to the application?

Freek Van der Herten:
Let's start off by saying that a package can basically just do anything that you can do in a project.

Matt Stauffer:
Yeah.

Freek Van der Herten:
So any of the Laravel specific things comes to mind. Maybe the first one that comes to mind is a config file. Maybe you want to configurator how a certain package should behave. Then your package can actually have a config file, and that config file is loaded by a service provider, a service provider like you know and love in a regular application. I'm already diving into the rabbit hole here.

Matt Stauffer:
Well, let's just start with service providers, because that would give us the hook for a lot of other things. So if your package wanted to have a service provider, why? And what does it look like to register it?

Matt Stauffer:
And just so everyone knows, we're going to talk a little bit, hopefully not too deeply, but we're going to talk a little bit about the structure of what creating a package looks like. Only because I think for everybody as package consumers, it's helpful for us to know what's actually happening when these service providers are auto-registering or whatever else. So this is a little bit like Inside Baseball, but I think that it's going to be really helpful for you as a package consumer and maybe a potential package author, dear listener, to hear how some of these things work and what it can do.

Matt Stauffer:
So, Freek, please continue. When you talk about a service provider-

Matt Stauffer:
... these things work and what it can do. So, Freek, please continue. When you talk about a service provider, why would you create a service provider in a package? And what does it look like to integrate with that service provider with Laravel apps who knows how to run it?

Freek Van der Herten:
Yeah. So I should first say that not every package has a service provider.

Freek Van der Herten:
Laravel specific packages have a service provider, probably. If you have a framework-agnostic package, then you probably don't have a service provider at all. Then you must set up like the package using the provided PHP code of the package. But let's talk about Laravel specific packages because the audience is probably familiar with Laravel a lot. So the package service provider is basically a class where you just register all the things that your package needs. It's a class where you put like bootstrapping code to make Laravel aware of, "Hey, there's like a command here that they can use. Hey, there is a conflict file that I should feed here. Hey, here's a piece of middleware that maybe we can use."

Freek Van der Herten:
And that's something that you set up in a service provider. Now, probably when you've installed a package, I think, if you done Laravel in the past two years or something, you didn't have to register that service provider into your application. So in the old days you must have registered the service provider in a coffee file of Laravel. But, nowadays, it happens automatically. It's something, now that you're accrediting people, it's important to create people. This is something that was added by our buddy Dries Vints. Laravel, actually has a mechanism to discover the service providers of a package. You see that whenever you type Composer updates, there's an entry at the end, I think, like discovering packages. And then basically Laravel goes to every package in your offender directory. And it takes a look at which composer.json file mentions a Laravel service provider, and then it will load that up. That's basically in a few sentences how that works.

Matt Stauffer:
That's great. So we've talked about service providers have the load and you kind of gave us a quick hint that one of the things they could load is a config file. And I think one of the next foundational things for us to talk about is publishing. Marcel, could you talk to me a little bit about what publishing, basically, what does it mean for a package to publish stuff and how do we call it and what type of things do they publish?

Marcel Pociot:
So, like Freek mentioned, when a package has a service provider and has a conflict file, most of the time you want to have the contract file be publishable so that the user of your package can modify the conflict file. Another common example of things that you want to publish are migrations. Or if you have a package with a UI, you might have something like CSS or JavaScript files like Nova publishes, those files, for example. And then in the service provider, you would basically just tell the framework, "Hey, this package can publish a file in this location." And when you do publish it, copy adds to this new name. And then you can give those published commands, also certain tax so that I could say, "Oh, this is a list of conflict files that I publish." And this is a migration.

Marcel Pociot:
And then the user can run PHP, artisan vendor:publish, and then provide the service provider name or choose it from an interactive list. And then the framework is going to basically just copy the files that you specified to the locations that you want. That's basically what publishing is. It's just registering with a framework, 'Hey, these are files that I want to copy to a certain location."

Matt Stauffer:
Yeah. And some packages require you to publish things in order to work. Like if there's CSS or JavaScript that needs to be shared publicly from this package, you have to publish them or the CSS of the JavaScript won't work. Some of them allow you to publish, right? They'll have a default that you can change. And I think that's often the case with config, or if you publish a template and they say, "Hey, we've got this default config, we've got this default template that we're going to use in our package," but you may want to change how the template looks or you want to change some of the config values.

Matt Stauffer:
A lot of packages allow you to change the config values without publishing, because they tell you what environment keys those config files are reading by default, but sometimes you don't want to use environment keys, or sometimes the package author didn't do it that way. And so, that allows you to publish it.

Matt Stauffer:
So we talked about publishing, we talked about config. We talked about customizable templates and service providers, and migrations as well. Are there any other things you all think about that are common for Laravel packages to allow to be, basically hooks that they make into that framework?

Freek Van der Herten:
I think some things that we didn't mention yet are, that the packages can also have salt to work with. They can expose for salts. And you can also do bindings in the service provider if you want to buy into certain client as a singleton or something. That's something that you can also do in a package service provider. I am saying package service provider, but all service providers are basically equal. So anything that you can do in your project, you can also do in the backup service provider.

Matt Stauffer:
But that's a good point though. So one of the things that I see a lot in, and when I say bridges, everyone, just so you know, a lot of the best packages in the PHP world are not intended for Laravel, they're just PHP packages. One thing that's very common for people is that they'll build a bridge because if you go to, let's say a package that makes it possible for you to interact with Stripe or something like that. So let's say, and this is not true for their Stripe SDK, but let's say you were to go to Stripe. And they said, in order to use Stripe, you have to run these 15 lines of code before you actually use the thing. And that's in the PHP world.

Matt Stauffer:
Well, in the layer of Laravel world, you'd take these 15 lines and you'd go make your own Stripe service provider and run them once in your Stripe service provider and then you're good. If that's the case, however, somebody might build what they would call a layer of L-Stripe bridge. And that package probably just requires the Stripe thing. And then it publishes a config file. It has its own service provider. And then that service provider, it just runs those 15 lines of code for you in a very Laravelly way. That's a good way to think about service providers, whether or not we're talking about packages. It's running the setup stuff that you'd only need to run once, but you need to run before you use the things that you need.

Matt Stauffer:
So we've talked about the packages that come out of the box and learn. We've talked about what things that the packages commonly are able to interact with in terms of our space. Are there any other kind of like intro to packages we should talk about before we start talking about Gotchas and any of the other concerns there? Are there any other things you think we should be covering just for people to have a really good understanding of packages and learn our world?

Marcel Pociot:
I think what Freek mentioned that, anything that you can do with a service provider in your own application you can do within the package. I think that's very important to understand, because it really, I think, demystifies package development, especially for Laravel, because if you want, you could build a monolithic application and then split it up into different packages and each sort of the framework works under the hood and then each part could be its own package. So, I think, that really made it click for me that basically whatever I can do in a service provider I can do within the package. And sometimes I also just do this to quickly scaffold a package. So I just create a service provider in my app and then prepare stuff in there.

Matt Stauffer:
Yeah. Imagine that it's going to be a part of the package, even though right now it's not. And I think that's one of the cool points about that is we've actually, at times, had to extract internal packages for clients where that package never made it on packagist our packages at all. But that doesn't mean it wasn't still a package, right? So we said, "You know what, we have three applications we're building here that are all going to have this same sets of logic. And it was a couple of models and some foreign requests and a couple of other things." And we said, "these are going to be accessible across all of them. These three very different applications being run by three different teams. They need the same stuff." So we pulled all that shared logic out into something we call Project Name-Shared, and then it had versioning.

Matt Stauffer:
And now there's pains that come along with it. Right? Because now if you need to make a change to that model, make sure the tests still work on all the other people that are consuming it, publish the version. So, it's not free to do that. But in that particular context, it made sense. And it's very similar to the whole concept of when you split your thing out into microservices. Well, do the costs, basically measure well with the benefits you're getting from it. But even that, I mean, in theory, you could take your entire application and make it a package and then have your app have nothing but that one dependency now, why would you do that? Who knows? But like you can wrap literally anything you want no package. And that's a great point.

Marcel Pociot:
Well, one thing that you'd just briefly mentioned is that you can also, which I think is very important, is that you can have that are privates. So far, we haven't even talked about how packages get discovered or published. And I think that's also something that is quite important. So there's packages, which allows you to discover all the public packages, but you can also set up a sort of like a private packages, which also exists as like an enterprise solution so that you can support Composer, but you can also set it up yourself and hosted on your own. And then you can have dependencies that are private, that you can install an update through Composer, but only certain people can access it.

Matt Stauffer:
W can go down that road. And just one second, but Freek, was there something you wanted to say?

Freek Van der Herten:
Yeah, there is something maybe high level that we haven't touched upon yet. And for us it's obvious a bit, I think for a newcomer might not be that obvious is that like, this can also live in a package. So the it's not only production codes that lives in the package, but the tests as well. Now, if you require a package dose, this arm's going to be in your project if the maintainer did that properly. But if you go to any package that has a bit of reputation, then it probably will have a test, a directory where all the tests of that package live.

Matt Stauffer:
Yeah. And, the note about what you said, if they configured it correctly, just so everybody knows, there is a thing that you can configure in your get configuration that tells which of the things will and will not be installed to basically with the package. So you can have, as a package author, you're going to have files that are committed to get, but don't actually get installed when somebody uses Composer to install them. So, all right.

Matt Stauffer:
So let's talk about distribution and publishing real quick. So because we've already done a package episode, I'm just going to breeze through it. I won't even make you guys talk about it because you all should go listen to that Composer and packages episode. But Composers, the tool we use, it's like NPM for PHP. It's central repository rather than also being named Composer like MPM does. It's central repository is called Packagist, P-A-C-K-A-G-I-S-T.org. And that is pulling primarily from GitHub. I don't know if it can even pull from GitLab or anything, or if it's GitHub only, but everything I've seen is from GitHub.

Matt Stauffer:
So people will put their packages up, open source on there, and then you'll get them distributed there. So everything that you see on packages, you're also able to see on GitHub and that's how the distribution happens. Unlike NPM, you don't have to individually publish things, using some command line tool. It, instead as a package author, it just synchronizes the state of your Composer or your GitHub repo together with packages. So when you want to do a new release, you just do a new release or a new tag in GitHub. And then it pushes that tag over to packages. And that's it. So it's a lot simpler. There is something called private packages with March, which, which Marcel mentioned, which is packages.com, and you can either sell-post or pay for a cloud version where you also get all those same values that you're getting from packages, and they manage it for you, but you have to pay them for it.

Matt Stauffer:
But then the other option, which Marcel mentioned is that you can also in Composer, like we talked the Composer episode, you can expose things that are not paying for private packages, but are just private packages on your version control system, Bitbucket, or GitLab or GitHub or whatever else and your Composer configuration. All the consumers will have to go add that as a repository.

Matt Stauffer:
Again, go listen to the Composer episode if you don't remember this, but basically the simplest thing is I can say, "Hey, Marcel, I've got this private package. You can use it. Go add this line to your composer.json. And now all of a sudden you have it, as long as you have credentials, your local credentials show that you have access to this thing on GitHub.

Matt Stauffer:
So you would have to make sure that whoever your deployed user is on your server also has access to that package. Or they'll just get something saying, "Hey, we can't install that cause we can't see that repo."

Matt Stauffer:
So there's lots of different ways to get access to these packages. But the number one most common way to do it is to either, a) put it up on open source in GitHub and just make people add it to the repository as a vcs thing, meaning they link it there, but not through packages. Or of course the absolute, most common is for somebody to publish it on packages. And then you can just require it with a simple strings like you're used to seeing.

Matt Stauffer:
There is one other thing you can also do in Composer, which is that you can reference a path on your local machine. So, you can go near repository section and say, this is a path type one. And then you just give it a relative path on your server and then it loads that in. So, if you're developing your own packages internally, it doesn't even have to pull it down from GitHub. You can just clone it at a directory, parallel to the one you're in right now.

Matt Stauffer:
I know I breezed through that really fast, but again, go check out the Composer episode if that's something that you're unfamiliar with.

Matt Stauffer:
Okay. So we just talked about a whole bunch of things before I kind of plow through further. Is there anything else that this picked up in your brains that you guys want to talk about?

Freek Van der Herten:
Maybe something that we should mention, but it's probably also in the Composer episode is, I want to name drop Sophos because that is the name, the self host. It's private packages that you can install and you can have like authentication on there or not. I just want to name drop that.

Matt Stauffer:
So I actually don't know the difference. What's the difference between private packages in Satis? Or have you do you say it?

Marcel Pociot:
I think private packages gets ... With Satis, you have to keep it in sync with the war codes on GitHub or whatever it is yourself. And I think the private packages basically works like packages. It does this for you, I think.

Matt Stauffer:
Okay. And Satis is free, right?

Freek Van der Herten:
Yeah, this is free and it's self-hosted. Private packages like the SAS version of packages, I guess. Yeah.

Matt Stauffer:
And that's, S-A-T-I-S. And of course, we'll have all the links in the show notes.T hat's a good note because there is a self-hosted version of private packages, but it's still a SAS. So you're still paying 1,260 Euro per year. So, self-hosted private packages cost money, but does all the work for you. Satis is free, but you got to do all the work. Thanks for calling that out. For some reason, I'd always thought that Satis cost money. So today, I learned.

Matt Stauffer:
All right, anything else you guys want to talk about before I move us forward?

Freek Van der Herten:
Yeah. Maybe requiring a package locally. Why you want to do that? That's basically just for like this thing out, you're your own package. That's what I do mostly when I create new packages, just create a new larval application. And inside of that composer.json, just point to the directory, where developing my package and then you can just basically just use whatever you want and comfortable symlink your package into the vendor directory of your project, which means that you can just type in your packages, just program it and all the changes without having you to run Composer update will be available in your local application. And that's like a golden way of developing packages, I think.

Matt Stauffer:
Totally agreed. Yeah. And if you've ever developed Nova components, if you do moat Nova packages, by default, it sets up your Nova package that you're developing in a Nova components directory, but they're already kind of moving you in the direction of thinking, "Hey, I'm going to put all this package in its own little independent space and it's getting at LinkedIn" so that if you want you just rip that directory out and make it its own GitHub repo, and then you're instantly there.

Matt Stauffer:
I think, I like the idea of what you all are talking about is, if you build your code and you say, "man, this one thing is really separate from the rest of the app," it really has a kind of a minimal exposure to the rest of the app. And it really makes sense for it to be its own thing. Well, maybe at least start by putting its own piece of the PHP namespace, if nothing else. So at least that code is going to be in its own folder. And then you can start thinking, "Oh, well now that's already in its own folder, and it really only takes one dependency, that'd be really easy for somebody else to inject. Maybe it's a time for me to extract it out and maybe extract it out just to another folder," in your site's directory or whatever, and give it a name and pull it in with that Composer path thing, and that's it. Maybe you never expose it anywhere else, but if you start building it that way, it makes a lot easier to extract it later, for sure.

Matt Stauffer:
All right. So, normally the next step that we talk about is Gotchas, and I think there's a lot of Gotchas in the package world. So let's talk less about Gotchas for package offering and more about Gotchas for package consumption. What are things that you see people regularly tripping up on as they consume packages or they upgrade after they have a lot of packages or as they try to install y'alls packages and run into problems. What are some of the Gotchas in the package consumption world?

Marcel Pociot:
I think in general, what always is a problem is, if you have a lot of dependencies from third parties and a new layer of old version comes out, you end up having to basically update all of the dependencies because the semantic versioning of Laravel package might only work with Laravel 8.whatever. And when Laravel 9 comes out, then those packages won't automatically work anymore until the package maintainer took care of it. This can be pretty frustrating because, often, it means waiting for the package maintainer to go and add support for the latest Laravel version, or in the worst case, having to fork it, send a PR, and keep track of that fork for as long as it's not merged. I think that's like the biggest issue and drawback that you have, especially if you have a lot of dependencies that Laravel updates will become more painful.

Freek Van der Herten:
I also think what a drawback is for backups users is that if you're unlucky, your package, may become unmaintained. Maybe the maintainer of your package just doesn't want to work on it and it's perfectly in the right of a package maintainer to do so. But yeah, this can happen and this can be annoying. But I think a golden rule when you install a package is that either you should be able to take care of the GOAT yourself, or you should be able to switch to an alternative. If those two requirements are met, then it's probably safe to use a package because you're not too dependent on it.

Matt Stauffer:
Yeah, absolutely.

Marcel Pociot:
I think nobody really thinks about, because I mean, you want to use a package because you don't want to deal with it, then you don't want to find an alternative.

Freek Van der Herten:
Yeah. But then you think the risk, that's something that you need to be in. You need to keep in mind as well, that you might end up with an unmaintained thing that you don't understand how to use. Now, something that I also see people tripping up, this is a very small thing. I think, I basically see because when I create a new package, I also think you do as well, Marcel, if you create a package, then you mostly target the latest PHP version. Right now it's PHP 8.

Freek Van der Herten:
And whenever a new PHP version comes along, people need to install a new PHP version. I think that the large portion of people aren't aware that the PHP version in your browser that handles web request can be different than the PHP version of the C-live version. And what I see a lot is that people say, "Hey, I could install your package, but in the browser it says it has a syntax error." And that's basically because the PHP version that handles the web requests hasn't been updated yet. And this is something that I see people tripping over and over again, actually.

Matt Stauffer:
It used to happen in Valet a lot and we fixed it. So anybody who uses Valet, go update to the latest version of Valet. We had discovered this bug where sometimes you'd update Valet, but there'd be a socket still open. And so the web version PHP-FPM was still using the old version and you had to delete that socket file for it to refresh. So Dr. Byte, Chris, updated it so that it deletes that socket file manually, doesn't always need to because when the things are working right, it doesn't need to, but he just added an extra check. So Valet people, you're much less likely to have this problem, just so you know.

Freek Van der Herten:
And that would, that's what we mentioned, Dr. Byte, Chris, I'd like to thank him for all the work that he does, maintaining our permissions packages as well. He does a lot and not only for our package, but for Valet and other stuff as well. Thanks for all your work, Chris.

Matt Stauffer:
He's a good guy. So, you mentioned the suggestion of, don't take on something unless you know there's an alternative or you're able to maintain it on your own. I definitely think that there's going to some people who are going to say, "well, then I'm never going to install any packages." And of course that's not the response, but I would say that every package you install introduces the possibility that at some point the author of that package no longer wants to maintain it. And so I think what the healthy response it can give us all is a little bit of skepticism with every package. Because some people say, "Hey, I could write this code, but with the package, I don't have to." That's not good enough reason because maintaining your own code that is very simple is sometimes easier than and healthier long-term than maintaining, bringing in a package that does the same thing, but also does 10,000 other things that might introduce breaking changes cause your use cases, not as common or the person may get burnt out.

Matt Stauffer:
But on the other hand, that could be saying, well, then never use a package if you can write yourself. And that's also not true because every line of code that you write is now code that you're responsible for maintaining. So in the other hand, if you could write it yourself, but the package does it in two lines and you would have to write it in 40 lines and you wouldn't think about the security concerns that the package offers or thought about whatever. Well, then use the package. And so it's so weird because every time we think about a package, there's this line, it's not a really easy answer of whether to use the package or not. There's good reasons not to use a package here and there's good reasons to use a package here.

Matt Stauffer:
You just got to develop a sense to try and consider all those ramifications, what long-term maintenance costs am I introducing by bringing this package that may not be maintained or may later break, or may not be updated for level eight and time or nine at a time, but also what maintenance costs am I introducing by writing this code myself when I'm probably not as good at knowing all the nuances that need to be considered, like the number of times I've seen people try to write things to themselves and then introduce security bugs as a result of that has been high.

Matt Stauffer:
However, I would say that the number one problem that I see when people decide to write it themselves, instead of going the other way is not third-party packages, but as internal packages. So, if you think you're going to write your own code better than stuff that comes with Laravel, you're probably wrong.

Matt Stauffer:
I'm just going to state like, it's not just Taylor, although Taylor's brilliant, but Taylor plus the tens of thousands or hundreds of thousands of people who've used that code. Look at that source, I mean, if we're talking about using, we're talking about millions of people, but look at that source code who know that particular topic really well and have pull requested all the little edge cases and nuance and stuff like that, the likelihood that you're going to catch all of that by rewriting that thing yourself is basically zero. So, when it comes to Laravel core functionality, just don't rewrite it. It doesn't matter how cool you think you are or how much you hate stuff that other people wrote. Just do it yourself when it comes to third-party packages. I think that concept should be introduced a little bit because just because a package exists for something doesn't mean that they're going to maintain it doesn't mean that they're actually really good at writing this thing in the first place.

Matt Stauffer:
Be a little more skeptical and try to balance that. Do I introduce the cost of my own code being maintained or do I introduce the cost of package? Both of them have costs. You just got to balance them.

Marcel Pociot:
I also think that as we briefly touched upon looking at packages and discovering how and deciding when should I use which package, I think one important factor is, does it have tests? Because even if at the point of requiring it or not maybe thinking about, 'Hey, can I take care of this later on?" If it has tests, then you at least know that somebody thought about having writing tests for this in the first place. And if it comes to the situation that you have to maintain it yourself or keep working on it extended, then you can use those tests as a guidance. I think that's also a lot that even if it's something simple that you could ride your own, maybe you haven't thought about that edge case that a certain test covered.

Marcel Pociot:
... maybe you haven't thought about that AG Case that a certain test covers.

Matt Stauffer:
Right.

Freek Van der Herten:
Yeah. I also want to add, because maybe I was a little bit too harsh with those two rules of when requiring a package. I don't want to demotivate people for using package for the right reasons. I think you're also good if a package is very popular. Because if a package is very popular and the original maintainer abandons it, probably the community will step in to do that. And that's happened a while ago with something that's even in the composer.json file for Laravel itself with the Faker library where the original author didn't had any motivation or time or whatever, any reason as good to abandon the package, I think. And he said, "I'm not going to do this anymore. Does somebody want to take over?" And I think a bunch of people, I think Taylor and Graham and a bunch of other people, they just stepped in and are maintaining it now under another vendor name. So-

Matt Stauffer:
Which I'm sure we will see spring up in the Laravel composer.json soon, it'll probably pull. And so it'll just push over and everybody will migrate and that's fine. And I think that's a really good... I was going to go somewhere else, but now I'm going to go somewhere with this. The attitudes people have towards open source maintainers can sometimes be a little bit unhealthy. And so I want to make a quick note that when somebody opens an open-source package, they are taking a little bit of responsibility on themselves for longterm maintenance.

Matt Stauffer:
Like when Daniel Colburn worked at Titan and he wanted to make Ziggy, the first thing I told him was, "Daniel, just so yo know, the moment you make Ziggy, you're going to be in this moment of excitement. But you're now... This is your baby. You're going to have to take care of this baby," I said, "forever." And he's like, "I totally understand." But the thing is, it's not necessarily forever. You should intend to be able to do it longterm before you make the package. For sure. Don't make a package that you don't think you can maintain, but that doesn't mean that those intentions are going to be true forever. You have no idea what your life is going to be like six months from now or a year from now or whatever. And so it is a completely valid thing for open-source maintainers, who are giving that time for free to abandon a package or to not have time to respond to your issues, your pull requests. That's just life.

Matt Stauffer:
Now, the good thing is there's a lot of people in our community who have taken up the mantle of saying, "Hey, I may not have package ideas of my own, but I love helping package maintainers." And so you're going to see people like Chris. Now, Chris also does have packages of his own, but Chris, Dr. Byte, or you also see Tom Witkowski, Dev Gummibeer, both of them and quite a few other people just love to go around and help people run their packages. And we are so, so, so grateful for those folks because they end up being the lifeblood of those packages more than the people who originally created them.

Matt Stauffer:
I am the formal maintainer of Valet. I didn't write Valet in the first place, and I still don't do the majority of the code review. So I'm the one who basically is pulling the switches and doing the releases. And I have a little bit of input on the direction of the thing, but in the end, Dr. Bight is the majo... He's the primary maintainer from a code perspective. And neither Taylor nor Adam really touched Valet at all these days, and that's not a problem.

Matt Stauffer:
So I think we need to recognize that the people who are creating these things, they were not paid for it. They do not owe us anything. I think the number one thing, if would ever expect a package author to owe us, is to tell us if they're going to deprecate something. I think if I ever get mad at a package author for non-commitment is if they let the thing die, but they never say they're letting the thing die. And I'll open an issue, usually, just saying, "Can you just tell us if you're letting this thing die so that we can respond appropriately."

Matt Stauffer:
But we all have lives, we all have jobs and we can't predict them. And we can't predict global pandemics. And so I think it's really valuable for us to just say, "I recognize that the individual people maintaining this are humans." Because I think the type of issues that people open, "Is this really doing this public?" Yes, it really is. And there's probably some context or reason you don't understand that may have to do with a sickness in my family or... And sometimes they're upset about the lack of response or sometimes they're upset about the thing not working the way they were expecting. Well, turns out, sunshine, you're not the center of the universe and I wasn't thinking about you when I wrote this thing.

Matt Stauffer:
So remember when you're interacting with these package authors that they are doing this work for free for you and for the rest of the community. And if you really want things to be different and you don't see a way for it, well then it's either, you've got to put up with it being the way it is, or you got to put the work in to make it different. And this is not just from package authors to package consumers, because as package authors, we can do this to each other as well. Let's just all be gracious and aware that these are human beings that we're interacting with.

Matt Stauffer:
Interestingly, the thing I was about to say speaks to almost the opposite end of this. So I think that it's good to say both of them at the same time. One of the things that you can note, not just whether or not there are tests in this package, is how many open issues and pull requests does it have? Because, that can often tell you a lot about how able are they to maintain it. Now, the number's not a perfect gauge. I have quite a few packages that have a lot of issues and protocols open, but it's because they're long running things that we still have not figured out rather than things that haven't been addressed. So it's not that it's a perfect thing you can look at. But I would say if you see one package with five issues and five pull requests and a bunch of stars in another package with similar number of stars or whatever validating things, and it's got 300 pull requests in 2000 issues, there's a big note there to you about what their ability to address the work coming their way it looks like.

Freek Van der Herten:
Yeah. If we're talking about metrics that you could use to determine if a package is something trustworthy to use, something that I also take a look at is when was the last change made? This isn't a watertight thing because sometimes packages are just finished. All features are there, it isn't abandoned, it's just finished.

Marcel Pociot:
It just works.

Freek Van der Herten:
Yeah. But more often than not. Then if there's like some activity on a package, that's a good sign. Not having activity is not per se a bad sign, but having recent activity is a good sign.

Matt Stauffer:
That's a great point. All right. So we're getting near the end of... Well, we're already way past the normal time, but I knew this one was going to run late, so that's total fine. But I want to ask, are there any other got yous, any things that you think people get stuck on as packaged consumers that we have not covered yet?

Marcel Pociot:
I think without diving too much into semantic versioning, something that can bite you is that sometimes package authors might not stick to semantic versioning the way that they should or, well... Yeah, they should from a consumer point of view, and then you would just pull in a new bug fix release, for example, and it breaks your code. So this is something that can always happen that you just need to be aware of. That even though we have semantic versioning in place, and even if you're composer.json restricts to pull in updates that could break something, we're just working with other human beings that might make errors and publish a tag that shouldn't be published. And this could just happen every time.

Matt Stauffer:
A quick reminder to everybody in theory, if you've got three versions of your version, you've got let's say 1.1.1, if the increment... The last version, it should only be patches. So no breaking changes whatsoever. So you should always be able to allow those changes in. If you've got 1.1, so if you're going from 1.1 to 1.2 it should still have no breaking changes, but it should allow for new features to be added. So in theory, you should also be able to upgrade that second one without any breaking changes. The only time breaking changes should be introduced in Symfony is that first one. So as long as you lock it to anything between one and two so that would be ^1.0.0 Is the most common way of doing it or, right? No ^1.0? God, I still I'm bad at these. So if you do that, it'll allow you to go anywhere up to 1.9.9.9.9.9.9.9 but it won't let you go up to two. So if you have a constraint like that, in theory, that package should never break.

Matt Stauffer:
But Marcel's saying that's in theory, and we got to recognize that people aren't perfect. And I've released breaking changes on packages. And thankfully I always figured it out either immediately, as soon as I released it or within 24 hours and I immediately pushed out another release that fixed it. Every once in a while, I'd push out a release that broke things at the same time was changing a PHP version constraint in the release, and then it's even harder. Sometimes it's a pretty complicated dance. So again, this is not asking for grace, although hopefully you can have a little grace for the package authors, but also just saying, and Marcel, if I'm understanding you correctly, just know that just because you put your constraint right doesn't mean you're perfectly protected from things breaking. Another reason to have tests. Right?

Freek Van der Herten:
Yeah. And I also want to add, and I don't want to put more horror on requiring a package in your application, but in theory, every release can be breaking. Because imagine that the package exposes some clause or something and you extend from that clause, you add a function on that and then on the base, on the package, the author adds the same function with a different signature, your application will break. So breakages can happen. You need to be aware of that and even if the author did everything right, it's can still break in your project. Now that being said, it's a little bit uncommon that that happens, but it can.

Matt Stauffer:
Yeah. All right. Any other got yous we want to cover before we wrap up for the day?

Freek Van der Herten:
I think we got the most important ones. I think I could ramble on with people that just require the namespace of a clause not the facade and then things start breaking because things gets called statically. Stuff like that, but they're more smallish things. I think we covered the big ones.

Matt Stauffer:
Okay. So normally I'd say, where can people learn more about this, but unless you guys stop me, I don't know if there's any places that really teach you about packages really well. I think there's some things that teach you about package development really well, but I don't know if there's anything that teaches you a ton about packages. So I would say check out the composer episode of this podcast and also check out next season where I'm going to be walking you through individual packages. If there's anywhere I would think about where I learn about packages, I would say the Laravel News Podcast. They talk about packages a little bit, not in great depth, but is there anywhere else that you all think about that teach you either about new packages that are coming out or just about using packages in general? I don't know if I know of anything.

Freek Van der Herten:
I think in the Laravel documentation that there's a page on it.

Matt Stauffer:
Oh. Is there? Okay. Is that what you're going to say too, Marcel?

Marcel Pociot:
No. I wanted to mention there's a community project that John Brown, is his name, he created which is called laravelpackage.com. And it's basically a full documentation about everything about package development in a written form. So yeah. It basically teaches you everything about the development of a package.

Matt Stauffer:
That's very cool. Yeah. I just looked at the docs and the docs that talk about packages are literally just telling you about the third party or the first party package that Laravel has, it's not actually talking about... But it is good to know about all those. So go check them out.

Matt Stauffer:
So let's talk about if I wanted to develop packages. So we've got a free one here from John Brown that is called laravelpackage.com. And it's a really nice, easy to read thing. Thank you so much for that note. It's just telling you about how to do mail bills and jobs and notifications and models and setting up your development environment. This is great even talks about test bench, which is the way... It's a little bit complicated, the way to run... To write tests in your packages that give you a pretend version of Laravel to work with. This is awesome.

Matt Stauffer:
So if I were not just to want to read this, but if I were to want to per se watch a video course about package development, I think there's a couple options out there. Marcel, would you talk to me about yours first? And then Freek, could you tell me about one too?

Marcel Pociot:
Well, yeah. I mean, Freek and I, we both published and created video courses about package development. So yeah, mine-

Matt Stauffer:
What's yours? What's the name? What's the URL? And then Freek can tell us.

Marcel Pociot:
Yeah. It's PHP package development and it's available at phppackagedevelopment.com. It is about generic PHP package development and also covers Laravel specifics. But it's basically, we're starting with an empty folder, create a package and at the end, integrated it into Laravel and publish it packages.

Matt Stauffer:
Yep. Freek.

Freek Van der Herten:
Yeah. I created a course as well. I think both courses are quite on par. I think it just depends if you prefer a German accent or a Belgian accent explaining all the things there. Mine is at laravelpackage.training. We have a fancy .training domain there. And in addition to a building framework, not sleek packages and building a Laravel package, there's also some videos on source diving existing packages so you can just see what are things that we did in our packages. So what techniques that we used there.

Matt Stauffer:
Awesome.

Freek Van der Herten:
Yeah.

Matt Stauffer:
Okay. I will talk at another date about sponsoring, so we don't need to go into large detail here. But I would just say, if you use packages, go check out the GitHub page for the packages that you're using and that's a place for those folks to say, "Hey, you can sponsor us." So if you see something... And they don't necessarily even necessarily have to talk about how to sponsor them, sometimes they say sponsor me by, there's something called Treeware Earth and they say sponsor me by donating trees or sponsor me by whatever else. At Titan I'm actually working on a thing that says, "If you like our packages, here's all the people whose packages we like, go sponsor them." So I'm actually going to make a page for that because we don't need the sponsorship.

Matt Stauffer:
Actually, I actually made a Titan sponsorship page, fun story, with the idea for people could give a little bit to us, but we would just turn around and give that money away. Or maybe there was going to be like a $1 tier just to say, "Hey, we like you. Thank you." And the folks at Titan looked at it and they're like, you know what? That feels gross because our whole pitch is that we think that we can make a consultancy, able to... Our whole pitch is, and nobody else needs to do this way, but we can make our consultancy fully viable, such that it funds 20% time. And 20% time is when we make our packages, so why should we ask for money for it? And that's again, that's not how other consultancies do it, there's no shame. But they said that to me. And I was like, "Yeah. You're absolutely right. Thank you for bringing that up." So I scrapped the entire thing. I'd written it, I had applied for a sponsorship, we'd gotten it all. Scrap the whole thing and we're just going to do a little thing.

Matt Stauffer:
So everyone considers... But I think the idea is if you use a package regularly, go look and see if that person has mentioned what thank you looks. Like Spatie's, thank you looks like... At least for the longest time was send us a postcard. I think you have sponsorship now, right?

Freek Van der Herten:
Yeah. We have sponsorship with every call of action for paying products. And then we have the postcard ware which is still still mentioned.

Matt Stauffer:
Yeah. Postcard ware. So, but no matter what, I would just say, find the ways to support them. And if they have paid things like both Marcel and Freek do, then go look at their paid things and see if you can get them. I mean, I would say that they're paid things are great anyway, but maybe that can be like a, "Hey, I got free value from this so I'm going to buy your paid thing." So just but in general, when you look at a person, especially if you run a company, if you're a CTO, something like that, recognize the free labor that has gone into basically making you have to do less work to make your thing work and just go see if those package authors are potentially asking for you to support them financially, support them with postcards, support them with trees or by buying their paid products or something else like that. Again, I'm going to talk about this in greater detail at another date. So, all right. Anything else that we didn't cover today that you guys wanted to cover before we wrap up?

Freek Van der Herten:
Maybe I want to end by just by saying that if you want to get into package development and it seems like a lot and confusing, don't be too scared. It is a lot and it can be scary. Personally, a few weeks ago I tried creating a package in another language, in Ruby, and it was like, "Whoa, what is this all?" And I can imagine that if you're starting with Laravel or PHP package development, you'll have the same feeling. I'm going to give the advice from the hitchers guide to the galaxy, don't panic, be calm, follow the show notes that you, Matt, will probably put here or there will be probably a lot of helpful resources, reach out to people. Personally, I can say if you're getting stuck with package development, tweet at me, if it's something that I can help quickly with, I will do that.

Matt Stauffer:
Love it. Marcel. Anything else?

Marcel Pociot:
Yeah. One thing that I recently saw, which I really liked is there's this great Larabelles build initiative from Susanna and she built a package live on stream and Tom Witkowski helped her along with it. She also had no knowledge of package development and they built, I think it was a Blade Component package from scratch over the course of two streaming sessions. So yeah, as Freek said, don't be afraid of this.

Matt Stauffer:
It's a great idea.

Marcel Pociot:
Yeah. Just ask for help.

Matt Stauffer:
I'll put those YouTubes in the show notes and if you're getting nervous, it's a great way to do it. Susanna is brilliant in many ways. But I think that one of the things I appreciate her the most is her willingness to do things when she says, "I don't know what I'm doing and it's very nerve wracking to do it, let alone do it publicly." But the first stream she ever did was I was just like, "Hey, can you come on some streams with me?" And she's like, "I hardly even know Laravel right now." I was like, "You're great." So I think that she does a really good job of making us all feel a little bit less nervous because she does it and she does it great. And she does it with grace. And so that not only should that encourage us all to try it, but I think the specific reference to those videos, we'll put those in the show notes as well. So thanks, Marcel.

Matt Stauffer:
All right. So the fun moment at the end of everything, I've had both of you in the podcast multiple times. So, I could run out of fun moments, but I thought of something earlier today that I really like. So if PHP and Laravel, which just to everybody knowing this is not going to happen, I promise. If PHP and Laravel just completely fell off the face of the planet, and for some reason there was just unfixable unmanageable things and it was just completely useless, what job would you move to next? And whoever wants to start can. Take your time.

Marcel Pociot:
Yeah, for me it would... Doing something with computers was always clear from the very beginning that I want to do something with this. So I guess it would still have to do something with it. And if I would absolutely need to do something completely different, I would love to explore becoming a board game inventor and come up with... A board game creator.

Matt Stauffer:
I like that. That's Cool.

Marcel Pociot:
Come up with that.

Freek Van der Herten:
Yeah. That's also a sort of package. A board game and pieces in it. Yeah?

Marcel Pociot:
I love it.

Freek Van der Herten:
Yeah. I think if I were to go... It doesn't have to be economically viable at all. I would do something with music, probably. That's my other passion. Yeah, probably I would do that.

Matt Stauffer:
So I know you do music and you do it in a couple of contexts, I think. You have a band, but you also, were you deejaying? Are you still deejaying? Like what would your dream job be in music?

Freek Van der Herten:
Oh, it would be definitely be in a band. I'd also make some music on my own, but in a band it's just so much nicer. I think there are so many parallels to developing and being in a band, that's also an episode on its own. But what I like being in a band is that you can be like a leader where people can look up to you and follow you and you can be the lowest guy, you just need to follow at the same time. It's something that I got from an artist called Moondog, it's a German, I think blues artist. And he said, I asked, "Where do you get the name Moondog from?" "Well, sometimes you're the moon sometimes hear the dog." And that's something that's that stick with me. So definitely I want to play in the band and not the whole time on my own.

Matt Stauffer:
Okay. Got it. My joke is always that I would go off and become a farmer. But now these days I'm thinking a little bit more like I would like to do something with woodworking just because I'm enjoying it so much. But in reality if PHP and Laravel went away, I would just change Titan. I mean, Titan already does as much of View and React and View Native Script and React Native and other things as anything else. So I would probably just move over to Elixir and keep doing what we're doing but it's nice to imagine the whole computer world went away what would we do? So I like it guys. All right. So-

Freek Van der Herten:
I think for Spatie, if we had all the computers have blown up, probably we would become cooks or something because we have so much people that just love eating and love making good food. So they would be a cooking company. They'd send you packages with food.

Matt Stauffer:
There you go. Packages of food. I like it. So, for each of you, I'll do reverse alphabetical this time, I want to ask you how can people follow you and how can they pay you money? And it's funny because I say that at the end of many episodes and most people don't know how to answer it. I know you all do know. So maybe just pick one way for them to pay you money because otherwise we'll be here for the rest of the day. So how do they follow you on whatever major social networks and then how can they pay you money? Number one, option Marcel.

Marcel Pociot:
Yeah. If you want to follow me, Twitter would be the social network of choice. @marcelpociot is my Twitter handle. And if you want to spend money on Beyond Code stuff, you can check out beyondco.de with all the, hopefully, great dev tools and video courses.

Matt Stauffer:
Love it. Freek. `

Marcel Pociot:
Yeah, for me, it's almost the same. It's the same format. The social media network of choice is Twitter. My handle is @freekmurze. I also have a blog freek.dev where I blog about Laravel development a lot. If you want to spend your hard earned dollars or currency of choice, head over to spatie.be/products where there are paid products and video courses to spend your time and money on. And you could also consider spending money at ohdear.app, which is a monitoring service that I built together with my buddy Mattias.

Matt Stauffer:
I love it. All right. So this is the last episode I actually had to pause and check to make sure this is the last episode of season four and I've had so much freaking fun. Thank you to all the guests. Thank you to you two. Thank you to all your listeners. There is a season five coming, I already know what it's going to be. A little hint, this particular episode happens to be the last episode for a reason. So season five is going to touch on some of the things we've... same things we're going to talk about here, but I'm going to take a little break and I'm going to do a little bit work on my own podcast and streaming. So we'll be back in a couple of months. I promise I'm not going to take a year to find the music this time. I swear.

Matt Stauffer:
But thank you guys so much for doing this blast roundup episode with me, this was a ton of fun. It was really cool having the both of you on, I've gotten to know you guys over the years and I enjoy both of you and you're both really brilliant in this particular area as well. So thank you so much for your time and listeners, thank you so much for tuning in every week. And I won't see you next time on this episode, but I'll see you next time in the podcast. Thanks guys.

Freek Van der Herten:
Bye everyone.

Marcel Pociot:
Bye.