Nodejs最恶劣的设计，就是node_modules了

Node.js 最恶劣的设计，就是 node_modules 了

引言

Node.js 的 node_modules 文件夹是一个用于存放项目依赖库的地方。尽管它为开发者带来了极大的便利，但不可否认的是，它也带来了一些问题。本文将探讨 node_modules 的一些缺点，并通过具体的例子来说明这些问题。

问题描述

一个典型的 Node.js 项目可能会包含多个依赖库，这些依赖库又可能有各自的依赖库。结果就是，node_modules 文件夹中可能会出现大量的重复模块副本。例如：

my-project/
├── node_modules/
│   ├── express/
│   │   └── (express 模块文件)
│   ├── @types/
│   │   └── express/
│   │       └── (类型定义文件)
│   ├── typescript/
│   │   └── (typescript 模块文件)
│   ├── lodash/
│   │   └── (lodash 模块文件)
│   └── @types/
│       └── lodash/
│           └── (类型定义文件)
└── package.json

在这个例子中，@types/express 和 @types/lodash 是 TypeScript 类型定义文件，它们分别依赖于 express 和 lodash。因此，这些依赖库及其子依赖库会被下载到 node_modules 文件夹中，导致大量重复的文件副本。

空间浪费

这种冗余的依赖库副本会导致显著的空间浪费。对于大型项目，node_modules 文件夹可能会占用几十甚至几百兆的空间。这不仅增加了项目的体积，还可能导致开发环境的磁盘空间不足。

du -sh my-project/node_modules
# 输出: 523M my-project/node_modules

性能影响

除了空间浪费之外，大量的依赖库还会增加项目的构建时间和启动时间。每次安装或更新依赖库时，都需要解析和下载所有相关的子依赖库，这无疑会拖慢整个过程。

// 安装依赖库的时间
const installTime = require('time-it'); // 假设有一个这样的库可以测量时间
installTime(() => {
    require('npm').load({}, () => {
        require('npm').install();
    });
});

结论

虽然 node_modules 为 Node.js 项目带来了极大的便利性，但其带来的空间浪费和性能影响也不可忽视。为了优化这些问题，可以考虑使用诸如 yarn 或 pnpm 这样的包管理工具，它们提供了更高效的依赖管理方式，如依赖扁平化和依赖缓存机制，从而减少冗余的依赖库副本。

参考资料

• Yarn 官方文档
• pnpm 官方文档

这个设计是有必要的， 不同的模块依赖的版本可能不相同。

之前bower拉取bootstrap好像，想删除不让我删除，提示我超出文件长度啥的，嵌套好深，一层又一层…我win7系统…

这个时候跑过来挖坟是几个意思