Subscribe
Share
Share
Embed
We have such a rich ecosystem of packages in the Laravel and PHP community. But can there be too much of a good thing? What do we consider before adding a small package to our projects?
- 00:00 A healthy ecosystem of packages
- 01:02 Too much of a good thing?
- 02:48 Risks to consider
- 04:13 Other ways to share
- 05:34 Think before you promote
- 08:02 Consider the friction
- 08:39 Silly bit
Would you like help auditing the packages in your Laravel application?
Creators & Guests
What is No Compromises?
Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.
Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.
Aaron Saray (00:08):
And this is Aaron.
Joel Clermont (00:16):
One of the things I really like about the PHP ecosystem, and maybe more specifically the Laravel ecosystem, is there are an abundance of packages that you can pull into your application, that maybe take complex or difficult tasks and, with relative ease, let you pull it in and use it. I think of things like the roles and permissions package, we use this all over the place. And we could write that, we could build our own system, but why? Right. Just use the package that exists.
Aaron Saray (00:49):
Right.
Joel Clermont (00:49):
They're well documented. That particular package is well-tested and there's a lot of people using it, hammering on it, finding bugs, adding features. So that's great. But sometimes, and I'll kind of put this in the context of us as a consultant coming into a project, we'll see tons of packages pulled into an application. When you look at it, some of them are really inconsequential. I'm not going to name names, right? But I'm thinking of one in particular. It was literally a single file that contained a single function, and it was about 30 lines of code. I don't know, Aaron, what are your thoughts on this? Where's that balance between pulling in a package and using it and just like, "You know what? I could just write that. That's not something that complicated."
Aaron Saray (01:43):
Yeah. There's a number of things that we have to remember about adding packages to our projects. And mainly it's surrounding risk and usability. Usability first of all, is it may make it easier to do a thing but depending on the architecture of that package and how that person put it together, they might have also locked you into only one way of doing it. Which is an inefficient way for your style of programming.
Joel Clermont (02:10):
Sure.
Aaron Saray (02:10):
Or maybe it's insecure or anything of those things. Then using that as jumping off point, the risk side is security of the package. You need to look through it all. What if the author unpublishes it? Now your app can't work. Are there any tests on it? I think the example I'm remembering that you were saying is there wasn't any tests in there either.
Joel Clermont (02:34):
There were not, not even a test folder. Like, sometimes you'll get the test folder with example tests. This didn't even have that. Empty, nonexistent
Aaron Saray (02:43):
Well, good for them for cleaning that out.
Joel Clermont (02:45):
Okay. Sure, there you go. What a positive take.
Aaron Saray (02:48):
We didn't have to look in there and be like, "Argh, there is no tests." But there's a lot of risks to adding a package. Not saying that you shouldn't but every single package you add, you add a little bit more of a vector of attack or some risk to it, and whatnot. Especially when you're looking at these ones that are like really small things like that. You asked what I think? I don't understand why. I'm glad people published them and show us their way of doing it but I'm not going to install that into my project.
Joel Clermont (03:16):
Well, you raised a good point, maybe they published it because... There's different models of working, right? We tend to dip in and out of a relatively small number of projects throughout the year, right? We tend toward longer engagements. But there's companies, like an agency model, they might support a hundred Laravel apps. And I could see maybe in that scenario, "Oh yeah, you know, we use this thing everywhere. Well, now when we want to update it, we have to go update a hundred apps." Maybe it makes sense in that case to publish a package, even for internal use, but to put it on Packagist and then someone else might see it and want to use it too. Yeah, I'm not yelling at people for publishing a small package but it's more on the consumption side. Like, "Does it make sense for me to pull this in?" And a lot of times it doesn't. I think we're in agreement on that.
Aaron Saray (04:05):
Yeah. And I know we've talked about this before, but I guess one of my questions is, whatever happened to just teaching people? Why don't people write blog entries?"
Joel Clermont (04:13):
Okay.
Aaron Saray (04:13):
Like, if you have a five line function, you could just write a blog entry about it and share it on your favorite social network. And then say this is how you would solve this problem that's repeatable. You don't have to publish a package and develop art for it and all this different stuff.
Joel Clermont (04:31):
A fancy logo?
Aaron Saray (04:31):
Yeah.
Joel Clermont (04:31):
No, this one did not have a fancy logo, so.
Aaron Saray (04:34):
Okay.
Joel Clermont (04:34):
That would make me more mad is if there was like really fancy logo and branding and still no tests. Then it's like, "Well, why are you spending your time on this?" But no. It had a 'read me', I'll give it that. And it had a code example but it didn't... No tests, no other real information. Again, I can say this because we're not naming names. But internally it had to make an HTTP request and it was using curl. And this was a package specifically for Laravel. I get if it was a PHP package and you didn't know where it was going to be pulled in, you didn't want to add a whole dependency for something.
But if this is for Laravel, there's an HTTP client built-in, which can be faked and has testing support and stuff. So pulling this in, now you have to do a lot more gymnastics if you wanted to mock that particular API interaction that's coming from the package too. That's another thing I think about, is how well is it written is kind of a way of looking at it.
Aaron Saray (05:34):
Yeah. I think the last thing I would say about this is there's probably... I guess, I can't say this for certain. I'll ask you then.
Joel Clermont (05:40):
Okay.
Aaron Saray (05:41):
Do you think there's a responsibility in people online who are sharing these links to packages then to verify that it's worthwhile?
Joel Clermont (05:54):
You mean like just, "Hey, I saw this on Twitter or something, share a link to it."?
Aaron Saray (05:58):
Yeah. Because I'm always scared that someone will write a package. And I almost thought about doing this myself just to demonstrate it. But write a package where it actually has a security hole in it that can do something nasty and then try to seed it into other things and then have people share it around. Because if you can get the branding and your audience write, you could possibly get this in the hands of everyone.
Joel Clermont (06:20):
Sure.
Aaron Saray (06:21):
From my experience, a lot of people don't seem to look at the source code. They just look at the docs or something and say, "How do I use this package? I should use that immediately right now when there hasn't been any people reviewing it."
Joel Clermont (06:32):
This probably won't surprise you, but I'm going to take a little bit of a nuanced approach. I don't think there's anything unethical about sharing a package that you saw and you thought looked interesting and you haven't done a complete audit on it. And I don't think that's what you're saying.
Aaron Saray (06:47):
No.
Joel Clermont (06:47):
But I would say you should have at least tried to use it. Because, again, just scanning the docs or even looking at the code, the thing might be completely broken, right? I mean, I would be more inclined to share something, and I would find it more valuable if somebody shared something, that they had actually tried and they're like, "Yeah, this worked well. It did what it said it did, and it was easy to use." To me, that's worth sharing more than just like, "Hey, I saw this thing exists."
Aaron Saray (07:13):
Well, just to make this fully muddy then. I want to take the opposite side. Which is, I think it's impossible for everyone that wants to share and aggregate content to have used everything. Like, if you have an aggregation site, for example, that you share 10 links-
Joel Clermont (07:32):
Sure.
Aaron Saray (07:33):
How are you going to test all those things? You talk about nuance, there is, I guess, a ton of nuance to it.
Joel Clermont (07:39):
Yeah. And maybe even say that, "Hey, I just saw this, it looks cool. Has anybody used it?" Is it different than? "Try this out. This package is great," and the link and you've never even installed it.
Aaron Saray (07:50):
I got you, yeah.
Joel Clermont (07:51):
There's some context to how it's being shared too, but that's a valid point. One last thing, I think you said last thing already, but I'm going to pull-
Aaron Saray (07:59):
Well, we're done. Goodbye.
Joel Clermont (08:02):
I think we've mentioned this before too. But let's say it's a well-written package, it's documented, there's no security holes, it has tests, there's still a little bit of friction now when the next version of Laravel comes out. And this one package, the guy's on vacation, he hasn't updated it. We've bumped into that, it's a pain. And you don't have to be on the bleeding edge of upgrading to Laravel but you also don't want to introduce unnecessary friction. So I'll just throw that in there as one more point to consider before taking on a new dependency.
Aaron Saray (08:39):
So I know I've mentioned this before that I'm pretty significantly colorblind. You know, it was rough growing up because they'd be like, "Put the red circle in the toy," and I'd grab a green thing and it wouldn't fit or something. And they're like, "What's wrong with you?"
Joel Clermont (08:55):
Was it a circle though? You don't have shape blindness, do you?
Aaron Saray (08:59):
Oh, no. But, I mean, I don't know. Like a cylinder.
Joel Clermont (09:03):
I get what you're saying.
Aaron Saray (09:04):
You know that or during the fall time in the Midwest, the trees change colors and my parents would take me for a drive when I was little to enjoy all the beautiful trees. And I was like, "What are you talking about?" I never understood that. And then I started looking at the rest of the world and I think there's either a lot more color blind people than we realize, or everyone just wants to mess with us. And I can give you an example. I think of a common rhyme, which just drives me nuts every time I hear it, when it starts out. Are you ready?
Joel Clermont (09:37):
I'm ready.
Aaron Saray (09:38):
"Roses are red, violets are blue," et cetera, et cetera. Guess what? Violets are purple, they're not blue You know what? If you think they're blue, you probably have red-green deficiency like I do. So basically what we see is you're either messing with me or the person who wrote this rhyme has color blindness too.
Joel Clermont (09:55):
I also think there's a third option, which is they are taking poetic license to make the rhyme better.
Aaron Saray (10:02):
No. It literally says it in the name of the flower, violets, I mean, I guess you wouldn't say violets are violet, but-
Joel Clermont (10:11):
Oranges are orange.
Aaron Saray (10:12):
Yeah. That's an example of something we've named after the color of it.
Joel Clermont (10:16):
Right. Wait, did we name it after the color or did the color come after the fruit?
Aaron Saray (10:20):
I don't know.
Joel Clermont (10:20):
That's a deep question.
Aaron Saray (10:27):
Do you need an audit of all the packages that are installed in your Laravel app?
Joel Clermont (10:31):
We can help. Head over to nocompromises.io and reach out to us. We can help with the code review, package audit, or anything else you need.