好家伙,学习新工具 

1.为什么我们需要包管理器?

关于npm我们已经知道了,这是我们项目的包管理器,

我们现在用的无比顺手的工具,都是在无数的竞争中杀出来的,他们淘汰了无数的产品

首先,倘若我们不使用npm,那么我们应该如何去新建一个前端项目?

纯手工,把我们项目需要的项目一个个下载到我们的项目里面

手动创建项目意味着您需要手动管理项目的依赖和文件结构，包括下载和引入任何所需的库或框架。

想想都可怕,再加上各种bug

我们新建一个项目可能需要?半个小时左右

于是我们的好帮手出现了,包管理器npm

我们把我们的配置清单给npm,随后,npm帮我们下载我们项目依赖的包

于是我们从30分钟优化到1分钟

npm真是太伟大了

2.NPM出现问题

但随后,NPM又出现了一些问题

2.1.安装太慢

新项目拿到手,安装依赖太慢

npm install

npm 2会安装每一个包所依赖的所有依赖项。如果我们有这么一个项目，它依赖项目A，项目A依赖项目B，项目B依赖项目C，那么依赖树将如下所示：

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

这个结构可能会很长。这对于Windows来说却是个破坏性的东西，因为有很多程序无法处理超过260个字符的文件路径名。

npm 3采用了扁平依赖关系树来解决这个问题，所以我们的3个项目结构现在看起来如下所示：

node_modules
- package-A
- package-B
- package-C
-- some-file-name-in-package-c.js

这样，一个原来很长的文件路径名就从./node_modules/package-A/node_modules/package-B/node-modules/some-file-name-in-package-c.js
变成了/node_modules/some-file-name-in-package-c.js。

2.2.无法保持一致性

想像一下去和小黄一起开发一个项目登陆页面,然后,你们在不同的时间安装了依赖包,

而碰巧,其中一个包更新了,14.2.1变成了14.2.2,或许是其中的一个组件框的样式改变了,

于是你会发现,你两的项目跑起来会有微妙的差别,当然了,也有可能是其他的各种各样严重的bug

总之,依赖包的版本不统一,是一个非常大的问题,可能会导致严重的问题

3.Yarn出现

于是针对这两个问题,

Yarn出现了,他很好地解决的npm存在的一些问题

yarn更快(为什么?)

1.并行安装：Yarn 采用并行安装的方式，可以同时下载多个依赖包，而 npm 是串行安装，只能一个一个地下载。这意味着当你使用 Yarn 时，依赖包的安装过程更加高效。

2.本地缓存：Yarn 有一个本地缓存目录，用于存储已经下载过的依赖包。当你需要安装同一个依赖包的不同版本时，Yarn 可以直接从本地缓存中获取，而无需重新下载。这可以节省大量的下载时间。

3.精确的依赖管理：Yarn 会生成一个锁文件 (yarn.lock)，用于确保每个开发者在不同环境下都使用相同版本的依赖包。这意味着在安装依赖包时，Yarn 可以更加准确地确定需要使用的版本，减少了版本冲突和不一致性问题。

在后来,

有了yarn的压力之后,npm做了一些类似的改进(对手起来了,再不与时俱进要就要被淘汰了)

1. 默认新增了类似yarn.lock的 package-lock.json,同样用于处理依赖包版本一致性的问题
2. git 依赖支持优化：这个特性在需要安装大量内部项目（，或需要使用某些依赖的未发布版本时很有用。

3.npm是有本地缓存的，它保存了已经下载的每个版本的压缩包。本地缓存的内容可以通过-npm cache ls命令进行查看。

本地缓存的设计有助于减少安装时间。