How To Pick A Third Party NPM Package For Your SaaS

You're in the middle of a React or Next.js project, and you're looking for that perfect third-party npm package. Something you can quickly drop in and iterate on to make everything easier.

Maybe you forgot your high school math and can’t figure out what an odd number is. Surely there’s a package that can help with that?

But how do you choose from the overwhelming number of different and often complex npm packages available? How can you be sure to select one that won't let you down when you need it most?

Today we're going to look at how to pick the best npm package to complement your React or Next.js app. GitHub data, licenses, security, and more underpin a solid, trustworthy npm package. 

So, first things first. Let's talk about GitHub data. Stars, opened/closed issues, pull requests, and the date of the last update can provide a valuable sneak peek into the health of a package. If you see the developer actively making commits, responding to issues, and having a solid changelog, you can be sure they are committed to maintaining the package for the long term.

Next, let's talk licenses. Now, I don't mean the kind that lets you legally drive. I'm talking about the kind that gives you official permission to use someone else's software package for commercial purposes. Not all licenses play nice with commercial use, so do your homework before you dive in headfirst. 

Moving swiftly along, let's focus our attention on that all-important factor: security. If you're creating for enterprise, this should be your number one priority. So, open up that Security tab and make sure there's no failing audits. 

As we meander down the list, we find ourselves in TypeScript territory. Look for the package to have its own types that you either install separately in developer dependencies or are included in the package itself for you to use. It'll give you a sense of predictability while coding and save you some time referring to their documentation when your autocomplete can pick up what props the component accepts, for example.

Alright, what's next? Ah, yes, demos. Ideally, the developer has a demo page with the component or library in action, so you know what to expect. If the library offers a lot of customization, showing that in the demo is always a great sell.

The quality of the documentation is crucial in picking the right package. So, ask yourself, is it comprehensive? Does it provide many examples? Good documentation will save you so much time, especially if you're a founder hacking an MVP together yourself. 

Let's not forget about performance. Is their bundle size on npm looking bloated? Any mention of good coding practices? You don't want a package that's going to slow down your demo to investors or free trial experience for customers. Experienced developers will often cite the package size in a bullet list in their package's README file as a key selling point.

Let's take a quick detour here to cover some more React-specific things to look for.

The render props pattern. If you know React, well enough, you'll know the value of render props to create headless components that are composable and let you bring in your own styling library. And if you're someone who uses Tailwind CSS, then you just have to start adding class names to turn the component into something pretty. 

On the subject of Tailwind CSS, you want the package to have compatibility with it if you're using it in your application. Maybe a prop that lets you pass in a few Tailwind classes or a configuration that you can override.

And there you have it. Consider these factors, and you should be able to pick a package and move on with developing your next feature inside your SaaS.