以前自学node做后台的时候,也过用npm安装依赖,node_modules中的文件夹基本上是和package.json中一一对应的,这次在新公司接手一个用grunt管理的前端项目,install完在node_modules中生成了600多个文件夹……感觉有点不对劲,虽然使用上没问题……而且看之前的人留的文档,基本上也是一一对应的,为什么我就装出这么多文件夹
以前自学node做后台的时候,也过用npm安装依赖,node_modules中的文件夹基本上是和package.json中一一对应的,这次在新公司接手一个用grunt管理的前端项目,install完在node_modules中生成了600多个文件夹……感觉有点不对劲,虽然使用上没问题……而且看之前的人留的文档,基本上也是一一对应的,为什么我就装出这么多文件夹
这是 npm3
中作出的改变,也是最大的改变之一,5.0 用的是 npm3。npm -v
可以查看 npm 版本。
个人认为,这一改变还是有很多好处的。
首先,npm 2.0 时代各个模块中的公共模块没有做到复用,都有自己的一份依赖,这些模块造成了很大的冗余。这种方式的一大弊端就是导致 node_modules
的目录层级非常的深,以至在 windows 下会出现 node_modules
路径过长,无法删除。
其次,2.0 的管理方式不太适合做前端的包管理,比如我用 npm 安装了一个插件依赖了 jQuery 1.10
,而另一个插件依赖了 jQuery 1.11.3
,npm 会把这两个版本的 jQuery 分别下载到对应插件的 node_modules
中。最后打包压缩的时候就会出现压缩了两个 jQuery 的情况,这在 node 应用中没有问题,但是在前端项目中就不行了,这显然不是我们所需要的。npm3 中把依赖扁平化处理就很好的解决了这个问题,它只会在 node_modules 中保留一个较新的 jQuery。
对于你评论中说的 hbuilder 的问题,有可能和这种目录结构有关,如果有关,那也是 hbuilder 的一个 bug,你可以换用 npm2 来安装测试一下。
2 回答953 阅读✓ 已解决
1 回答906 阅读✓ 已解决
2 回答595 阅读✓ 已解决
1 回答1k 阅读
在5.0以前是递归依赖,现在改为平行依赖。
另外,5.0以前在windows下递归依赖会产生很长的文件名,无法删除。算是解决了一个麻烦。