My thoughts on the node_modules folder size debate

In the world of JavaScript application development, the size of the node_modules folder has always been a topic of discussion. How can a simple application be 100, 200MB in size without even adding a single line of code? Take, for example, running npx create-react-app todolist, which downloads a whopping 218.7MB of “stuff”! (Yes, that’s the actual number).

However, before we criticize the size of the node_modules folder, let’s think about the countless hours that programmers all over the world have put into creating and maintaining open-source software. This vast collection of software, which we can inspect and learn from, has been generously contributed by individuals and companies. It was made accessible to us through the tool we know as npm, originally a tool and now a company.

By agreeing to publish our code on their servers, we have allowed others to build upon it, resulting in an extensive ecosystem with numerous tools and libraries. As a result, we now have quick starters like create-react-app or the Vue CLI, which provide immense power and are available to us free of charge.

So, is 200MB really too much to ask for in a world where we have terabytes of fast storage? It’s important to note that the majority of this size is comprised of tests, documentation, and other non-essential components. Moreover, most of the remaining code is specifically designed for the development environment and not meant to be served to the client.

Let’s take create-react-app as an example. What exactly is in those 200MB?

  • A compiler (Babel)
  • A bundler (Webpack)
  • A code minifier
  • A linter (ESLint)
  • A styling pipeline tool (SCSS)
  • A development server with live reloading
  • A test runner (Jest)

To put things in perspective, consider writing a Mac or iPhone application. To do so, you would need to install Xcode, Apple’s IDE, which weighs in at a whopping 14GB. That’s approximately 70 times the size of the node_modules folder. While it’s true that we are comparing different things here, it’s worth noting that node_modules encompasses everything you need to start working on your code. Moreover, using popular code editors like VS Code (200MB) or Sublime Text (30MB) is entirely optional, leaving the choice to developers.

If your concern is the disk space taken up by multiple apps each having their own local version of modules, you can explore optimally centralized solutions like pnpm. This allows all your apps to use a single shared modules location instead of duplicating them across projects. Notably, this approach is used by online coding tools like Glitch.

Some may wonder how they can ensure the security and reliability of their codebase when relying heavily on third-party modules. It’s important to remember that using modules is ultimately a choice. If you prefer not to rely on them, you can create your own version of the tooling required. But keep in mind that this would require maintaining the code, testing it, managing updates, and a considerable amount of additional work.

Having worked with other languages and ecosystems, I can attest to the vibrancy and opportunities presented by npm. In other scenarios, I had to build my own libraries for everything since the ones provided by third-party developers were either non-existent or abandoned, lacking updates and compatibility with the rest of the language.

Perhaps an option to download only production code rather than all the documentation and tests could be beneficial. However, this is merely an idea at this stage, and its practicality remains uncertain.

In summary, let’s celebrate the node_modules folder rather than dismissing it. It symbolizes a global effort, showcasing the collaborative nature of the open-source community. While its size may raise eyebrows, it ultimately provides us with a wealth of tools and libraries that save us time and effort in our development journey.