npm和 yarn不一样吗？

yarn的安装

下载node.js，使用npm安装

npm install -g yarn 

查看版本：

yarn --version

安装node.js,下载yarn的安装程序:
提供一个.msi文件，在运行时将引导您在Windows上安装Yarn
Yarn 淘宝源安装，分别复制粘贴以下代码行到黑窗口运行即可

yarn config set registry https://registry.npm.taobao.org -g 
yarn config set sass_binary_site http://cdn.npm.taobao.org/dist/node-sass -g

yarn的常用命令：

安装yarn 
npm install -g yarn
安装成功后，查看版本号： 
yarn --version
创建文件夹 yarn 
md yarn
进入yarn文件夹 
cd yarn
初始化项目 
yarn init // 同npm init，执行输入信息后，会生成package.json文件
yarn的配置项： 
yarn config list // 显示所有配置项
yarn config get <key> //显示某配置项
yarn config delete <key> //删除某配置项
yarn config set <key> <value> [-g|--global] //设置配置项
安装包： 
yarn install //安装package.json里所有包，并将包及它的所有依赖项保存进yarn.lock
yarn install --flat //安装一个包的单一版本
yarn install --force //强制重新下载所有包
yarn install --production //只安装dependencies里的包
yarn install --no-lockfile //不读取或生成yarn.lock
yarn install --pure-lockfile //不生成yarn.lock
添加包（会更新package.json和yarn.lock）：

yarn add [package] // 在当前的项目中添加一个依赖包，会自动更新到package.json和yarn.lock文件中
yarn add [package]@[version] // 安装指定版本，这里指的是主要版本，如果需要精确到小版本，使用-E参数
yarn add [package]@[tag] // 安装某个tag（比如beta,next或者latest）
//不指定依赖类型默认安装到dependencies里，你也可以指定依赖类型：

yarn add --dev/-D // 加到 devDependencies
yarn add --peer/-P // 加到 peerDependencies
yarn add --optional/-O // 加到 optionalDependencies
//默认安装包的主要版本里的最新版本，下面两个命令可以指定版本：

yarn add --exact/-E // 安装包的精确版本。例如yarn add foo@1.2.3会接受1.9.1版，但是yarn add foo@1.2.3 --exact只会接受1.2.3版
yarn add --tilde/-T // 安装包的次要版本里的最新版。例如yarn add foo@1.2.3 --tilde会接受1.2.9，但不接受1.3.0
发布包

yarn publish
移除一个包 
yarn remove <packageName>：移除一个包，会自动更新package.json和yarn.lock
更新一个依赖 
yarn upgrade 用于更新包到基于规范范围的最新版本
运行脚本 
yarn run 用来执行在 package.json 中 scripts 属性下定义的脚本
显示某个包的信息 
yarn info <packageName> 可以用来查看某个模块的最新版本信息
缓存 
yarn cache 
yarn cache list # 列出已缓存的每个包 
yarn cache dir # 返回 全局缓存位置 
yarn cache clean # 清除缓存

早期的npm

其实在最早期的npm版本(npm v2)，npm的设计可以说是非常的简单,在安装依赖的时候会将依赖放到 node_modules文件中; 同时,如果某个直接依赖A依赖于其他的依赖包B,那么依赖B会作为间接依赖,安装到依赖A的文件夹node_modules中,然后可能多个包之间也会有出现同样的依赖递归的,如果项目一旦过大,那么必然会形成一棵巨大的依赖树，依赖包会出现重复,形成嵌套地狱。

那么我们如何去理解"嵌套地狱"呢？

• 首先,项目的依赖树的层级过于深，如果有问题不利于排查和调试
• 在依赖的分支中,可能会出现同样版本的相互依赖的问题

那么这样的重复问题会带来什么后果呢？

• 首先,会使得安装的结果占据了大量的空间资源,造成了资源的浪费
• 同时,因为安装的依赖重复,会造成在安装依赖时,安装时间过长
• 甚至是,因为目录层级过深,导致文件路径过长,会在windows系统下删除node_modules文件,出现删除不掉的情况

npm or yarn 开发中的一点疑惑

你在实际的开发会不会出现这样的一些情况

1. 当你项目依赖出现问题的时候, 我们会不会是直接删除 node_modules 和 lockfiles依赖, 再重新
   npm install,删除大法是否真的好用?这样的使用方案会不会带来什么问题？
2. 把所有的依赖包都安装到dependencies中,对devDependencies 不区分会不会有问题?
3. 一个项目中, 你使用 yarn, 我使用npm，会不会有问题呢？
4. 还有一个问题, lockfiles 文件 我们提交代码的时候需不需要提交到仓库中呢？

其实,我对于上面提出的问题也是出于一种一知半解的状态。

所以,世界这么大, 我想去看看这两个兄弟之间到底是有什么关系呢？

npm的安装机制和核心原理

我们可以先来看看 npm 的核心目标

Bring the best of open source to you, your team and your company.

意思是 给你和你的团队、你的公司带来最好的开源库和依赖。 通过这句话,我们可以了解到 npm 最重要的一点就是安装和维护依赖。那么，让我们先来看一看npm的安装机制是怎样的呢？

npm的安装机制

下面我们会通过一个流程图来具体学习npm install的安装机制

npm install执行之后, 首先会检查和获取 npm的配置,这里的优先级为:

项目级的.npmrc文件 > 用户级的 .npmrc文件 > 全局级的 .npmrc > npm内置的 .npmrc 文件

然后检查项目中是否有 package-lock.json文件

1. 如果有, 检查 package-lock.json和 package.json声明的依赖是否一致：

• 1.1 一致, 直接使用package-lock.json中的信息,从网络或者缓存中加载依赖
• 1.2 不一致, 根据上述流程中的不同版本进行处理

2. 如果没有, 那么会根据package.json递归构建依赖树,然后就会根据构建好的依赖去下载完整的依赖资源,在下载的时候,会检查有没有相关的资源缓存:

• 2.1 存在, 直接解压到node_modules文件中
• 2.2 不存在, 从npm远端仓库下载包,校验包的完整性,同时添加到缓存中,解压到 node_modules中

最后, 生成 package-lock.json 文件

其实, 在我们实际的项目开发中，使用npm作为团队的最佳实践: 同一个项目团队,应该保持npm 版本的一致性。

yarn的出现

yarn 是一个由Facebook、Google、Exponent和Tilde构建的新的JavaScript包管理器。它的出现是为了解决历史上npm的某些不足(比如npm对于依赖的完整性和一致性的保证,以及npm安装过程中速度很慢的问题)

当npm还处于v3时期的时候,一个叫yarn的包管理工具横空出世.在2016年, npm还没有package-lock.json文件,安装的时候速度很慢,稳定性很差,yarn的出现很好的解决了一下的一些问题:

• 确定性:
  通过yarn.lock等机制,即使是不同的安装顺序,相同的依赖关系在任何的环境和容器中,都可以以相同的方式安装。(那么,此时的npm
  v5之前,并没有package-lock.json机制,只有默认并不会使用 npm-shrinkwrap.json)
• 采用模块扁平化的安装模式:
  将不同版本的依赖包,按照一定的策略，归结为单个版本;以避免创建多个版本造成工程的冗余(目前版本的npm也有相同的优化)
• 网络性能更好: yarn采用了请求排队的理念,类似于并发池连接,能够更好的利用网络资源;同时也引入了一种安装失败的重试机制
• 采用缓存机制,实现了离线模式 (目前的npm也有类似的实现)

我们可以来看一下 yarn.lock的结构:

"@babel/cli@^7.1.6", "@babel/cli@^7.5.5":
  version "7.8.4"
  resolved "http://npm.in.zhihu.com/@babel%2fcli/-/cli-7.8.4.tgz#505fb053721a98777b2b175323ea4f090b7d3c1c"
  integrity sha1-UF+wU3IamHd7KxdTI+pPCQt9PBw=
  dependencies:
    commander "^4.0.1"
    convert-source-map "^1.1.0"
    fs-readdir-recursive "^1.1.0"
    glob "^7.0.0"
    lodash "^4.17.13"
    make-dir "^2.1.0"
    slash "^2.0.0"
    source-map "^0.5.0"
  optionalDependencies:
    chokidar "^2.1.8"

熟悉npm的package-lock.json文件的朋友,可能一眼就看到了一些不同; package-lock.json采用的是JSON的结构,而yarn并没有采用这种结构,而是一种自定义的标记方式;我们可以看出新的自定义的方式,也同样保持了高度的可读性。

相比于npm,Yarn另一个显著的区别就是yarn.lock的子依赖的版本不是固定的版本。这其实就说明了一个问题: 一个单独的yarn.lock的问题并不能确定✅node-modules的文件结构,还需要package.json的配合。

其实到了这里,我会有一个问题,如何实现 npm 到 yarn 的切换呢？

这里 我了解到有一个专门的工具synp,它可以将yarn.lock转换为package-lock.json，反之亦然。

这里可以顺带提一嘴,yarn默认采用的是perfer-online模式,即优先使用网络资源。如果网络资源请求失败,再去请求缓存数据。

yarn的安装机制

简单来说, Yarn的安装大致分为5个步骤:

检测(checking) —> 解析包(Resolving Packages) —> 获取包(Fetching) —> 链接包(Linking Packages) —> 构建包(Building Packages)

🎈那么接下来我们要开始具体分析这些过程中都做了哪些事情:

检测包

这一步，最主要的目的就是检测我们的项目中是否存在npm相关的文件,比如package-lock.json等;如果有,就会有相关的提示用户注意：这些文件可能会存在冲突。在这一步骤中 也会检测系统OS, CPU等信息。

解析包

获取包

链接包

构建包

如果依赖包中存在二进制包需要进行编译，那么会在这一步进行。