难道只有我一个人想吐槽npm这种包管理方式么

时间:2021-01-29 05:01:53

实在忍不住吐槽

说实话有强迫症的我忍了很久了,实在是忍不住写篇文章来吐槽一下。

标题可能说的有点大了,我要吐槽的是:我可能只需要某一个小小的功能模块A,结果模块A依赖B-F这5个模块,然后B又依赖这10个模块,C又依赖那20个模块...一环套一环下来最后需要下载数不清的模块,虽然下载神马的都是全自动的,但是这样真的好么?

下面从几个方面来吐槽,有不爽的尽管来骂。

文件(夹)的个数

就以下载gulp为例,一个npm install gulp命令下来,一共下载了1221个文件,651个文件夹,占用空间4.12MB。

难道只有我一个人想吐槽npm这种包管理方式么

直接用到的模块就多达137个.

复制不方便

稍微多引用几个module,然后node_modules文件夹大的吓死人,文件个数多的吓死人,众所周知,很多时候文件个数多的文件夹甚至可能比文件体积大的文件夹复制更慢,且不说复制慢,就连删除都慢。

有的人可能会说,有了强大的 npm install 还需要复制干嘛,我想说的是,我自己一个小项目为什么要那么依赖于网络?哪天断网了呢?假如没有淘宝等国内npm镜像呢?每次换个地方都要从老外的服务器下载那么多文件,说得不好听点,哪天 npmjs.com 挂了呢?

文件路径太深导致的问题

还是以gulp安装为例,我复制吧,结果复制不了:

难道只有我一个人想吐槽npm这种包管理方式么

我打开某一个很深的文件吧,结果打不开:

难道只有我一个人想吐槽npm这种包管理方式么

你打不开是吧,那我把你剪切到其它文件夹,结果剪切也剪不了:

难道只有我一个人想吐槽npm这种包管理方式么

复制剪切打开都没用,那我直接把你删除了吧,结果删除都删除不了:

难道只有我一个人想吐槽npm这种包管理方式么

真是醉了,我说我把路径复制出来看一下到底有多么深,结果复制出来这个样子:

F:\WORKSP~1\OTT-EP~1\WEBCON~1\RESOUR~1\js_dev\NODE_M~1\NPMINS~1\gulp\39E757~1.1\gulp\NODE_M~1\GULP-U~1\NODE_M~1\DATEFO~1\NODE_M~1\meow\NODE_M~1\READ-P~1\NODE_M~1\read-pkg\NODE_M~1\NORMAL~1\NODE_M~1\VALIDA~1\NODE_M~1\SPDX-C~1\node_modules\spdx-license-ids

以上还只是一个gulp的例子,估计其它比这个深得深的module不计其数。

过于依赖第三方module

阿猫阿狗的小功能都去引用一个第三方模块,很多时候一个模块就几行代码,结果我引用你,你引用他,他又引用他,一旦人家这个模块出了问题你就惨了。

举个例子:

一个叫isArray的软件包一天的下载量有88万,2016年2月有1800万次下载量,它本身就一行代码。NPM生态系统中的许多开发者看起来宁愿复用其他人写好的代码而不是自己写。这种做法存在严重的安全隐患,因为一个被广泛使用的软件包存在bug,你的代码也会受到影响,而你却无法自己去修正

代码质量参差不齐

谁敢说发到npm上面去的module都是代码质量很高的?不信你随便到node_modules文件夹下去打开几个js看看,好多代码连最基本的代码风格都恶心的要屎。

最想吐槽的npm install

看似很方便,各大网站上总是喜欢在最显眼的地方写上一行看似方便到爆的命令npm install xxx,好像在标榜:看,我们的东西多么方便啊,一行命令就搞定一切了!其实呢,简单的背后暗藏了一大堆的坑,稍微复杂一点的框架(或者叫功能)总有那么多需要你去定制化的东西,然后接下来还是需要你去了解他们大量的配置参数。

难道只有我一个人想吐槽npm这种包管理方式么

结语

npm这种代码复用的思想是很好的,但是发展到今天我觉得已经变质了,它的本质是为了极大的促进代码复用,减少重复开发,但是它带来的问题比这个方便更严重,反正,我是已经无力吐槽了。