这是一个创建于 2378 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前向大家求助寻找最小化 node_modules 的工具（ https://www.v2ex.com/t/456847 ），得到了很多有价值的回复。但是由于 node_modules 结构差异很大，通用规则能优化的程度非常有限。
我尝试了两个工具，一个是 nm-prune （ https://github.com/pingyhq/nm-prune ），一个是 node-prune （ https://github.com/tj/node-prune ），两者都可以把我们的 vscode 扩展从~9MB 压缩到~7MB。效果不是很理想。
所以我想，体力活恐怕是绕不开了。
昨天把我们的扩展所依赖的 400+个 module 挨个筛了一遍，把通用规则无法包含的文件单独列了出来，最后的结果是压到了~5MB。
除了很多 module 单独为浏览器提供了额外的版本（比如 dist 或者 minify ），很多 module 也包含了 test.js 和 example.js 这样的文件，还有的 module 为 test.js 和 example.js 也提供 minify 版本。
不过 node_modules 庞大不单单是因为 module owner 对自己的库不细心，很大原因还因为对依赖引用不细心。举例子，lodash 这个库完整版本是非常大的，但是它为每个功能都提供单独的 module，如果只是用到了 lodash 的几个功能，不应该把整个 lodash 都包进去。还有 moment 这个包，因为支持 l10n，所以它也是非常非常庞大的，如果只是用到了 moment 的一个非常小的功能，很有可能会有其它更合适的包。最后最不能忍的，声明了依赖但是不用，这个依赖依然会被包进去。
我写的那个工具在 https://github.com/Sneezry/npmautoclean
因为是一天写出来的，代码比较粗糙，而且是根据我们的项目需求做的，目前还没啥通用性，里面的 ignore 列表会根据我们的项目慢慢增加，希望这一点小工作能让 node 变好一点点。
也发到 npm 了，npm i -g npmautoclean
npmautoclean 会改每个 module 的 package.json，只保留我认为有用的字段，因为没有完整测试过，这里可能有坑，之后慢慢完善。
我尝试了两个工具，一个是 nm-prune （ https://github.com/pingyhq/nm-prune ），一个是 node-prune （ https://github.com/tj/node-prune ），两者都可以把我们的 vscode 扩展从~9MB 压缩到~7MB。效果不是很理想。
所以我想，体力活恐怕是绕不开了。
昨天把我们的扩展所依赖的 400+个 module 挨个筛了一遍，把通用规则无法包含的文件单独列了出来，最后的结果是压到了~5MB。
除了很多 module 单独为浏览器提供了额外的版本（比如 dist 或者 minify ），很多 module 也包含了 test.js 和 example.js 这样的文件，还有的 module 为 test.js 和 example.js 也提供 minify 版本。
不过 node_modules 庞大不单单是因为 module owner 对自己的库不细心，很大原因还因为对依赖引用不细心。举例子，lodash 这个库完整版本是非常大的，但是它为每个功能都提供单独的 module，如果只是用到了 lodash 的几个功能，不应该把整个 lodash 都包进去。还有 moment 这个包，因为支持 l10n，所以它也是非常非常庞大的，如果只是用到了 moment 的一个非常小的功能，很有可能会有其它更合适的包。最后最不能忍的，声明了依赖但是不用，这个依赖依然会被包进去。
我写的那个工具在 https://github.com/Sneezry/npmautoclean
因为是一天写出来的，代码比较粗糙，而且是根据我们的项目需求做的，目前还没啥通用性，里面的 ignore 列表会根据我们的项目慢慢增加，希望这一点小工作能让 node 变好一点点。
也发到 npm 了，npm i -g npmautoclean
npmautoclean 会改每个 module 的 package.json，只保留我认为有用的字段，因为没有完整测试过，这里可能有坑，之后慢慢完善。
 |
1
coolicer 2018-05-24 14:30:31 +08:00
很不错啊。这个事为什么 npm 不在一开始就规定好，比如有一个文件夹名，以后如果要生产环境，就只用那一个文件就 ok
|
 |
2
sneezry OP @coolicer #1 其实 npm 有完善的机制做这件事，lodash 就是个非常好的例子，真的是非常干净。大部分其他的库真就是乱七八糟了
|
 |
3
shunia 2018-05-24 14:34:03 +08:00
工具应该有用.支持一个.
但是原始需求难道不应该是在提供的 extension 包里直接使用打包好的文件吗? |
|
4
sneezry OP @shunia #3 直接使用打包好的文件是指什么呢？意思是把 node modules 里每个 dist 拿出来用吗？
|
|
5
shunia 2018-05-24 15:37:06 +08:00
@sneezry 目前 web 端的 js 开发一般都会使用打包工具,把源文件和引用的包分析之后整合成一个文件,并且做保留语意的文本压缩.这样上生产环境的时候就不需要把 node_module 啥的发上去了.
工具比如: https://webpack.js.org/ vsc 的 extension 是不允许使用打包并且压缩(pack & minify)后的文件吗? |
|
6
sneezry OP @shunia #5 应该是允许的。webpack 我接触的不多，用起来不是很顺手。webpack 会自动识别每个 node_module 有用的文件吗，还是需要挨个手动配置呢？
|
 |
7
bigfei 2018-05-24 16:00:03 +08:00  1
webpack 有 tree shaking 功能，可以满足楼主的要求。。
恭喜又发明了轮子。 |
 |
9
airyland 2018-05-24 17:22:49 +08:00
@bigfei 这个本质上和 lz 的还是不一样的，lz 的需求是省空间，删除不必要文件。而 tree shaking 是将已经引入的 js 进行处理，减少无用代码。在引入时尽量最小化引入，比如上面举例的 lodash，不引入整个只引入需要的函数。
|
 |
10
xi_lin 2018-05-24 17:29:28 +08:00
@bigfei webpack3 里的 tree shaking 经常会失效，我记得有个 issue 说 4 会彻底解决，还没有尝试
|
 |
11
marcushbs 2018-05-24 21:13:12 +08:00
ssd 便宜了，换吧
|
 |
13
CrownLeo 2018-05-24 22:40:30 +08:00
|
|
15
sneezry OP @CrownLeo 不知道为啥，我用 yarn install 一直出错，就放弃 yarn autoclean 了。从 npmautoclean 的名字就能看出来我肯定是研究过 yarn autoclean 的，哈哈
|
|
16
shunia 2018-05-25 10:19:47 +08:00 1
那就推荐楼主用 parcel 吧,也是打包工具,免配置.可以代替 webpack. https://github.com/parcel-bundler/parcel
如果目的是减少本机的存储空间个人感觉意义不大.也没有特别好的建议. |
Select Language