Are you deploying applications to production with packages directly sourced from npmjs.org? This is a common practice for many organizations, with npmjs.org being a popular repository among developers and all. However, with this comes a bunch of stuff you’ll need to watch out for.

With npm Packages, your mileage may vary in terms of quality, licensing, and security. They aren’t subject to rigorous vetting, so it’s on you to sift through the sea of options to figure out what’s suitable for your project. This can be a bit overwhelming given the sheer volume of packages available. 

We’ll take a look at reasons why relying on raw npm packages is not an advisable approach and how implementing either a package approval workflow or package filtering can mitigate these concerns. 

4 Big Risks of Using Packages Direct for npmjs.org 

Given that just about anyone can publish a package to npmjs.org, and there’s no real way that they are vetted or endorsed, this can lead to all kinds of issues. 

⚠ Security Risks and Vulnerabilities: npm packages are prone to security vulnerabilities. Many packages like lodash have been known to harbor vulnerabilities that malicious actors can exploit. Some may even contain malicious code. Without proper checks, your applications and data could end up exposed to these risks. 

⚠ Unwanted Licenses: Almost every npm package has its own legal agreement, and when you use a package in your project, you might get legally tied up. Some licenses, like GPL-3, might not be a good fit for most apps and could set you up for legal grief, like the Artifex v. Hancom case. Understanding these legal terms and making sure they match your project’s goals is a high priority.

⚠ Low-Quality Packages: While npmjs.org offers an impressive array of packages, not all are created equal. Some may not be the best for production environments, posing the risk of introducing bugs or other unforeseen issues in to your app. Some of us may remember the chaos left-pad caused.. These packages could result in wasting valuable development time and effort spent on troubleshooting.

⚠ High Package & Dependency Volume 

One major issue you’ll face is the sheer number of npm packages and their dependencies that you have to deal with like Webpack, a module bundler known for it’s substantial number of dependencies. To review these packages, you’ll need to look at the package-lock.json to see the whole list of them with all their dependencies. Downloading all packages and dependencies manually takes forever, so finding a way to bulk download is pretty essential. What’s more, downloading individually can easily lead to dependency confusion. This is not only a logistical nightmare but also presents security risks, e.g. through Typosquatting

Use Only Approved npm Packages 

The solution to these issues is to introduce a process in your development that ensures you’re only using packages that are approved for use. “Approving” means checking that each package has: 

✔ Low/no Vulnerabilities or Security Risks 

✔ Acceptable License Agreements 

✔ Suitable Quality for Production 

✔ All Dependencies Accounted For 

Finding the right process is important. If it’s too complex, you’ll risk developers bypassing the process. If it’s not thorough enough, unwanted packages will make their way in your application. In this article we’re going to offer two processes are cover all these bases:

• Using a package approval workflow that approves packages from one repository to another to ensure only packages approved for production use are used by developers.
• Filtering npm Packages by their scope so that all packages are initially blocked by default, and only those approved are set to “allowed”.

The best way to approach either option is to use a private package repository. To look at how we can do these we’ll use ProGet, although other private repositories are conceptually similar.

Option 1: Use A Package Approval Workflow 

Think of this as “code review” but for npm packages. Like code review, you’ll essentially be vetting packages, in this case from npmjs.org before they are used in the application. A package approval workflow is typically built with two feeds. One of the feeds is used to store unapproved packages from npmjs.org. After the packages are vetted, they are “promoted” to the other feed for production use. 

What are the Benefits of a Package Approval Workflow? 

A package approval workflow ensures that developers can only use packages that have been vetted. 

✔ It’s a simple and effective way to reduce the day-to-day decisions that developers need to make. 

✔ They won’t need to constantly consider what packages they should or shouldn’t be using. 

Implementing A Package Approval Workflow 

Creating a package approval flow is pretty straightforward and can be done with two npm feeds in ProGet.

First, create the two feeds, one for unapproved packages and one for approved packages that developers can download packages from. 

You’ll want to “connect” the unapproved feed to npmjs.org. This will populate the feed with remote npm packages from npmjs.org. They can be downloaded through ProGet and are available for promotion once vetted. 

After vetting a package for quality, acceptable licenses, and vulnerabilities, you can promote it to the approved feed. Now, the package will be in the approved feed, ready for developers to download and use. 

Bulk Promoting Your Packages  

A necessary step in this workflow due to the thousands of packages you could be working with is bulk promotion. This allows you to promote npm packages in bulk as opposed to individually, which would literally take forever. Bulk promotion will save you significant time. 

Note that bulk promotion only works with packages that are local or cached in ProGet. This means the person reviewing packages would connect his local npm to the unapproved feed, then install these packages locally, then verify them. Once verified, the developer would go back to ProGet and bulk promote the cache packages.

To do this go to “Packages” and select Bulk Edit. From here filter the feed or package name where necessary. 

Select the Packages you want to promote, and then select “Promote Selected”. 

You may also want to configure permissions so developers can only view or download packages from the approved feed. 

For those familiar with using APIs, ProGet’s Package Upload API makes it even easier to upload your packages via a script.

Option 2: Filter your npm Packages: 

Due to the sheer number of packages and dependencies you’ll be working with, filtering npm packages by their scope will make it much easier to handle them. Doing this is also very straightforward in ProGet. 

Simply navigate to “Feeds” and select “Connectors”. From here select a connector such as “registry.npmjs.org” and select “Add Filter”.

Now you will have options you can use to filter the current connector. We recommend first blocking all with a “*” filter, and then allowing specific packages one by one. 

npm Package Approval in a Nutshell

Relying on npm packages from npmjs.org introduces critical issues, including security vulnerabilities, unwanted licenses, low-quality packages, and challenges associated with a high volume of packages and dependencies. 

To mitigate these concerns, taking one of two approaches is essential:

• Using package approval workflow
• Filtering your package

Either approach can streamline your development, allowing developers to focus on building robust applications, reducing day-to-day decision-making, and enhancing overall project success and security. 

These are just a few of the ways you can boost npm package use in your development. Why not sign up for our free npm in the Enterprise eBook today and find out many more!