How to Pick a JS Package

Welcome to Syntax. In this Monday Sanity Treat, we're gonna be picking packages. We're gonna be talking about how you can pick a JS package and how you should, look, what you should look for in a package, and what types of things you might, be wanting to pay attention to before you go ahead and npm install that thing and have the dump truck come up and just dump a whole lot of who knows what in your application. My name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey. Not too much. I do wanna talk about the Open Source pledge real quick, though. This is a initiative that Sentry is heading up. But what it is is

if you are a company that use open source software, it's time for you to pay your share. Right? And there's a opensource pledge.com, and all these really cool companies are pledging per dev how much money they are are going to give. So for example, Sentry give $500,000, which is $37100 per dev, and there's a huge list of different companies on here. Vault, Git Butler, Val Town.

Laravel is on here. Stackblitz.

It's really cool to see. And along with this, they Century has put up some billboards, which with the CEO, the CFO, and the CTO. We'll try to put some some images up on the screen of it.

But they what do they call this? CEO was the chief excuse officer. Yes. The CFO Wes the chief freeloading officer, and the CTO JS the chief tightwad, officer. And these graphics are amazing. I kinda want a shirt with them on. I'm kinda hoping that they they make some of those, but check it out. Opensourcepledge.com.

Tell your boss to take the pledge. Okay. So let's talk about the scenario here. What's the scenario? The scenario is you need a library utility. You need to do something in your JavaScript. What you need to act you need to tell if a number JS even or odd. Right? How are you gonna do that? That's just a joke, folks. But, you need you need something in your application. How do you determine what is good enough to grace your code base with? What can you add to your code base and not have it potentially be 1 out of date, 2 bad practices, 3, something unnecessary, etcetera? How do you pick a library or a package? Where do you even start for that type of thing? What's your strategy Wes? If you need something, what do you what do you reach for first? As I I go through this all the time, which is like, okay. I need a library.

For example, the other day, I needed a library that did a regex to get all emojis out of it. Right? Mhmm. Or you need a library that has a list of all of the countries and their country codes, and then you need a couple methods for finding those countries based on their country code or or getting the emoji flag for that country code. Right? These little utilities, I find myself needing all of the time.

And when that happens, I usually I go to NPM and I search for what I want, and I'm just like, I don't know. There's 20,000 of them on here. I don't know which ones are good.

I don't know if they're secure. I don't know if they actually have the features that I want. So I thought, like, let's talk about our approach to both finding them and as well as evaluating it. Yeah. Because finding them is is half the problem. Right? So Finding it. First of all. Yeah. Yeah. Yeah. So what I'll do generally is I'll go to Npm and then realize, oh, yeah. The NPM search sucks. Yes. And I'll go to socket dot dev. So npm, when you go to search for a package on npm like, let's do my country one. I'll just search country code on on npm. The first one is intl tell pnpm, and then it gives you these little bars, which is PQM.

And I don't know what PQM JS, and I don't know if those bars are good. What I do want to know is everything we're gonna talk about today to evaluate it. But, like, I wanna know, like, when was it? I guess they did you show you when it was last updated, but I wanna know, like, how many people? What's the most popular ones? You know, you can sort by popularity, I guess. But, like, show me, Yarn these getting a 100 downloads a month or 300,000 downloads a month? And on top of that, the the search is just not very good. So I have switched to using, socket dot dev, which is Faras' company. He does a lot of dependency security things. They'll analyze every single NPM dependency.

And if you go and use their search, I find that their search is is quite a bit better JS well as it gives you the information about supply chain security.

They have a quality metric that they calculate based on a few things. Has it been maintained? What does the license look like? And I just find it to be a little bit better. I still wish that it showed you

how many downloads per month because that's that's a huge stat for me, but I kinda I may have Wes ESLint. I'll message him. Yeah. P m. I personally I I would use socket dot dev as my 2nd step. I would use socket dot dev to to evaluate to help me evaluate because it does show you a lot of really good information from maintenance, quality, vulnerabilities, license, supply chain Sanity. Like, it gives you all that stuff. But, like, for instance, I just typed in React Scott into this. And on the 1st page, Zeus stand, then React Stately utils, MobX, and then 5 React Stately packages, and then Jotai, and then 8 more React Stately packages. Actually, 10 more React Stately packages.

So, before we get to, like, something like x Scott React and then ten more React Stately packages. React Stately, why you got so many packages? What's going on there? I've never I I don't know anything about React Stately, but now I see that there's 10,000,000,000 React Stately packages. That's wild to me. Either way, it it kinda makes it a little hard to get to some things.

So here, let me let me give you a an option that you might not consider or have considered before that I found to be very good for me. Well, at least I'll give you 2 options. One of which that's not as good. I'll go to Reddit, and I'll search for stuff on Reddit. People have opinions. People post about it. You see something modern. People will give their direct experiences about it. It's it's always hit or miss. But here's one that you may not have considered, Perplexity.

Perplexity Scott a I, we've talked about it before, but it's a it's like a AI search engine. They they do their best to surface links, but also give you kind of a LLM.

You know? And the reason I like Perplexity is tends to be very up to date, and it's good at, interpreting language in that sort of way. So for instance, I just said, I need a modern JavaScript library to parse and query a CSV.

And then it says, here's Pnpm parse. Papa parses, actively maintained. It has browser and node support. It's fast. It's feature rich. And then, of course, I then went to I went to socket dot dev, and I do the same thing. Parse.

Man, I keep I wanna say c v s, c s v.

And pnpm parse is the second one there. So then I can take a second look at it. There's another one, c v s parse. There's fast c v parse, whatever.

But either way, I found that the Perplexity AI does a good job of finding the things that people are using because it is it's kind of like an AI search ESLint. But it does a largely a good job of of being able to understand what people are talking about and using. Yeah. That's that's a good point because I had kinda stopped asking, like, chat g p t for these things because it's Same. It's still Wes? 202,021?

So a lot of the suggestions are are kind of out of date.

And I thought, like, no. Like, I wanna know what's happened in the last Yarn or 2. What are people using in the last couple years? So that's a a good because perplexity also takes search engines into account. Right? And it's constantly updating itself. They'll give you, even It is a search engine. It is a search engine. They'll give you links,

to back this stuff up. So it's not just like an LLM spitting out. It's giving you I like that. Like, here's a blog post. Yeah. JavaScript CSV parser comparison. And so then you can click on that if you wanna read more or something like that. Yeah. So you you can get where the LLM is getting its information from. Yeah. You know what? I'll also do Wes I want to find, like, maybe oh, maybe there's a better a newer alternative to something. Yes. I'll also just go into Google and just type, like, for example, moment JS. Right?

You I'll just type moment JS Vercel, and then immediately, you can say Vercel date functions, day JS, Lexan, and date. Right? So, oh, immediately, I have 4 other things to do a quick little research into. And then, also, you can just search that, and you can often find, like, a Reddit thread or something where somebody is giving their 2¢ on the the differences between x and y.

Yeah. So I just actually I went just to to also follow-up on that, I I went to perplexity, and I said, what are Moment JS alternatives? And it says Day JS, DataFNS, Luxon,

the temporal API. That's a good deal. Good. Yeah. I like that. Oh, I'll also often look for, like, an awesome list. So there's if you're not aware of this, on GitHub, there's often just a GitHub repo full of awesome dash whatever. So awesome React state management, awesome Node JS queuing alternatives, and they'll list up all everything in in the world. And it's great to just kinda peruse really quickly, kinda see what the landscape looks like. So big fan of that JS well as I'm a big fan of just asking people. Right? Go on Twitter. Go on Discord. Wherever JS that people hang out,

people love to give their 2¢ on on what is is good and what's not good. And, also, people ping Scott and I all the time about, like, hey. What should I use for local first? People ask Scott this all the time because he's had, like, 8 episodes on it. What should I use for local first data management? And then Scott goes, well Yeah. Well because he's tried them all. Right? And he's he loves to give his opinion on that. I do. And it's actually so funny. I was just doing my my conference talk at Svelte Summit, which was on that very thing. And, Swyx was in the chat, and he was just like, I'm here to find out what the libraries are that I should be paying attention. And because I'm going on and on about, you know, the, you know, the basics and intros. And then, like, as he types that, they're I go, well, now let's talk about the libraries.

It's like perfect timing. I do love to talk about this stuff. You're totally right.

Look in established projects package .json Yep. Or go to the, like, dependencies tab on GitHub, and you'll be able to see what dependencies they are using or often the opposite, which is if you are checking out a package and you say, is anybody using this? You can do the opposite, which is who is using this package, and you can you can do a quick look at, oh, wow. Some very big projects are using this, or I actually wanna see how they're using it. And you can dive into the code and and see how that works. Alright. Let's talk quality now. How do we evaluate the quality of any sort of package? We're we're oftentimes I I know that people can recommend things or things get used for a long time. But,

how do how do we know that, 1, that it's being maintained or that people care about it or that the community has vetted it or used it? I know that there's at this very moment, there's, like, drama going on because some, starter kit developer has been selling a ton of his starter kit and has, like, really bad security on it. So how do you know that you're not just, like, you're pulling in stuff with really bad either security or it's out of date or other people aren't using it's been abandoned? A a good place and and, honestly, one one thing that I always do with any any package before I install it into my application, no matter what, is I go to the GitHub issues. It can save you so much time.

For instance, you might see a package that looks really good. You install it, and then you hit a bug right away. Then you go to the GitHub issues and sure enough, that's like the number 1 GitHub issue. There's 400 people saying same same plus one, you know. And and you could have avoided that had you looked at that and said, okay. Well, there's clearly something going on here. And the creator JS not responding to any of these. They're not involved. It hasn't been updated in 6 months, and there's clearly an issue.

There might just be a problem with this. You know?

I will almost always go to the GitHub issues, and there'll be, like, is this thing dead or, like, what's the status of the project? And if there's a 1000000 issues and and this is no shade to the authors of these packages because they owe you nothing. But when you're making your choice, it's it's kind of important. So sometimes you'll find somebody who makes a post and says, hey. This thing hasn't been updated in 3 years. So so, for example, I use a package called HTML to campus.

And what that allows you to do is to lay things out with HTML and then essentially take a screenshot and convert it to, like, a JPEG.

And I use that for my video overlays. I have a couple tools I've built on it and my background patterns for my videos, and I was hitting, like, an issue with it. So I went to the went to the issues, and then somebody somebody had a issue that says, what are you using instead of this package? And then there was a couple of really good suggestions, including 1 guy who forked it and was now fixing bugs and and adding features to it. So I was able to find a really good one. Whereas, like, I would never have found that thing if it wasn't for the GitHub issues because, like, that's not gonna come up in in search. There's not gonna be a dev.t0

article on the top HTML to Canvas libraries. You know? Yeah. Here's another Node. And this one always gets me a little bit annoyed, at least now. I I'm become that guy if a package doesn't have types installed, and I have to do that.

Install them from directly typed or whatever. Man, that definitely kind of a Node. Definitely directly. Yeah. I mean, that that to me is, like, something that is annoying. But as long as there's types that do exist for it, I will use it. Definitely type shows that people care about the package if it's not, like, from the the creators directly.

But if your package doesn't have types created for it, and then what do I gotta do? I gotta cast everything as any, or I have to, you know, make the whole package as any. That makes working with it a little frustrating.

Not having types is a major flag to me because it means and and not that the author has to use TypeScript, but it means that nobody in the community has also needed types for it and and stepped in and created a definitely typed repo for it.

So, every now and then, there's, like, kind of a if it's so small that, like, nobody has done it, almost always, you could just go to the GitHub, copy paste the actual utility yourself, and put it in your own, put it in a file yourself. You don't need to install it, create a dependency.

Yeah. Sometimes I'll do that directly if it's a single especially if it's a single function or anything. So Scott dot dev

gives you metrics on if it thinks it's a good package or not, and that will give you supply chain security. So its dependencies, what what do those look like? Right? And it'll give you a quality score. It gives you a maintenance score, which is not always amazing because some packages literally don't need to be maintained.

They are so simple that they are that's it. They're they're done. You know? But others, yeah, they need to be updated and and whatnot. So they'll take I'm sure they take GitHub issues and whatnot into into account as well. And they'll also look into the license, which is kinda interesting because if you have lawyers at your company and you use a package and then, oh, Scott. There is no license for this type of thing. I've had I've had stuff in the past where I open sourced it, and someone is like, hey, Wes. Like, you need to put a license on this thing. Otherwise, I can't use it at my company. Oh, I forgot about that. So pop it in there. Yeah. Totally.

Next one here is bundle phobia. If you haven't seen this site, it tells you a lot about, packages size. So, like, for instance, I I have a link to the ZoosDAN's version 5. And you can see that the current version of ZoosDAN is, 1.2 kilobytes, and then it's 588 bytes minified in g zipped. And I love that they give you the minified in g zipped value of that because that's really what you'll end up shipping at the end of the day or at least you should. And then it tells you directly how long it'll the download will take on 3 g. So this package, if you add this to your application, it is adding 1 millisecond of 4 g, download to to your bundle. I also love that it shows how it's changed over time. Yeah. That's cool. You can see some packages that really bloat over time. But from version 4 to version 5, Zuzdand

was, like, a 3rd. It JS, like, out in a 3rd. So it's, like, now a 3rd of the size it once was. So you can tell that they're actively trying to make this thing better, and I I do love that. Another one is check if it does what you want before you get into it. I can't tell you how many times I've integrated a package into something, and I realized, oh, shoot. It doesn't cover this use case. And then you you have that code throughout your code base. It's in your package JSON. You gotta uninstall it, and it's that's a pain in the butt. So what I've ended up doing is read through the docs, make sure it actually covers your use cases that you can think of, and then also just run, like, a quick little a quick, like, isolated example in just an HTML file. You know? Link the thing in via e s m dot s h. Try run a little example before you go ahead and spend the time to integrate it into your application because you could save yourself quite a bit of of time. And even another tip I have is simply go to GitHub .comforward/search.

Search for that package's name and find examples that are already running Mhmm. That that use that and see if you can get get it up and running really quickly because you can see where people are actually using it. Do you know an easy way to do that, Wes? How?

So let's say you have a package like ZoosDend. Right? I'm using ZoosDend just because we were talking about it, moments ago.

And if you go to insights, there's a tab in GitHub insights.

Yes. And from insights, you can see so you click on dependency graph, and then you can click on dependence.

And you can see all of the repos that are using this package on GitHub. So sometimes if I'm having a package that has really bad docs or I'm hitting an issue with it, I will go to the insights dependency graph dependence and then I will check to see somebody else's code just to get through that bit. Mhmm.

Yeah. Yeah. I, I have used that. That's how I kinda suss out our our people using it. Right? 504,000 repositories on GitHub are using Zoosdend. Right? Passes it checks out. You know? Yeah. But if you wanna see how are people using this, you know, like, what does the code look like, I'll often use GitHub search just to I wanna actually see the part of the code where they are using this. Yeah. What I would do is I would just click through the repo from the network dependence and then search from there so that I like, I know that But then you're doing it repo by repo. Get up search. I can I can search from HTML to Canvas, and immediately, I can see 20 different code on 1 page of people actually using it, and you can immediately see how are people actually using it? I there's, yeah, there's 2 different ways to to do it, but it really depends on what you're looking. Yeah. No. I think I think you're right. Think you're right. 1 by 1 searching for it or my way, typing it in once and seeing 20 examples on 1 page.

Yeah. Both pages. Better because I did it. Yeah. That's why.

No. But, also, MyWay is just like a fuzzy search. You know? Yours is actual like, using the dependency tree

to to look that up. Yeah. Here's here's Node more thing I would do. I would look at the packages package dot JSON file because you I mean, you can see the size on bundle phobia, and that might give you an idea about how big something is. But you Scott know what the thing you're bringing into your code Bos is bringing into your code base. And sometimes that thing has a dependency, and that thing has a dependency, whatever.

I think you can suss a lot of this out just by looking at the bundle phobia and seeing how big it is. But there is something to be said about packages that rely on things that rely on less less dependencies or whatever. I mean, granted, there there is an argument against that as well. But if if something is relying on something else, then there's more likely something to break down the ESLint, something's version gets updated, and then the dependency doesn't get updated. And then Yeah. Or some some there's no option to pass,

like, a option to the underlying package. Right. Sometimes you just look at it and go, oh, I should just be using that dependency directly. And I can code this a 100 lines myself. And that way, I have full control over it, and it's it's one last dependency in your package JSON.

Word.

So that's I think we've done a show on that before. You know? Like, when to buy versus when to build it yourself or, like, when to install versus build it yourself.

That's a that's a whole decision you need to make as well as is this worth bringing pnpm extra dependency? But that's not what we're talking about today. We're talking about you do need a package, and how do you how do you assess that out? Work.

I think that's it. I think that's good info. Please tweet us at Syndax FM with your thoughts as to how how do you suss out if a package is good or not. We'd love to hear your thoughts. Yes. Absolutely.