This article was originally published at [https://gist.github.com/joepie91/04cc8329df231ea3e262dffe3d41f848](https://gist.github.com/joepie91/04cc8329df231ea3e262dffe3d41f848).
There's quite a few libraries on npm that not only include the regular build in their package, but also a minified build. While this may seem like a helpful addition to make the package more complete, it actually poses a real problem: it becomes very difficult to audit these libraries. ### The problem[](https://gist.github.com/joepie91/04cc8329df231ea3e262dffe3d41f848#the-problem) You've probably seen incidents like the [`event-stream` incident](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident), where a library was compromised in some way by an attacker. This sort of thing, also known as a "supply-chain attack", is starting to become more and more common - and it's something that developers need to protect themselves against. One effective way to do so, is by auditing dependencies. Having at least a cursory look through every dependency in your dependency tree, to ensure that there's nothing sketchy in there. While it isn't going to be 100% perfect, it will detect most of these attacks - and not only is briefly reviewing dependencies *still* faster than reinventing your own wheels, it'll also give you more insight into how your application actually works under the hood. But, there's a problem: a lot of packages include almost-duplicate builds, sometimes even minified ones. It's becoming increasingly common to see a separate CommonJS and ESM build, but in many cases there's a *minified* build included too. And those are basically impossible to audit! Even with a code beautifier, it's very difficult to understand what's really going on. But you can't ignore them either, because if they are a part of the package, then other code can require them. So you *have* to audit them. There's a workaround for this, in the form of "reproducing" the build; taking the original (Git) repository for the package which only contains the original code and not the minified code, checking out the intended version, and then just running a build that *creates* the minified version, which you can then compare to the one on npm. If they match, then you can assume that you only need to audit the original source in the Git repo. Or well, that *would* be the case, if it weren't possible for the *build tools* to introduce malicious code as well. Argh! Now you need to audit *all of the build tools being used* as well, at the specific versions that are being used by each dependency. Basically, you're now auditing hundreds of build stacks. This is a massive waste of time for every developer who wants to make sure there's nothing sketchy in their dependencies! All the while these minified builds don't really solve a problem. Which brings me to... ### Why it's unnecessary to include minified builds[](https://gist.github.com/joepie91/04cc8329df231ea3e262dffe3d41f848#why-its-unnecessary-to-include-minified-builds) As a library author, you are going to be dealing with roughly two developer demographics: 1. Those who just want a file they can include as a `