yarn查看任务状态（查看当前yarn运行任务列表采用什么命令）



• 参考学习：blog.csdn.net/ling_…

• npm install 执行之后，首先，检查并获取 npm 配置
  这里的优先级为：项目级的文件 用户级的 文件 全局级的 文件 内置的 文件
  
  
  
• 检查项目中是否有 package-lock.json 文件
  • 若有：检查 和 中声明的依赖是否一致：一致就直接使用 中的信息，从缓存或网络资源中加载依赖；不一致，则依据的版本进行处理
  • 若无：则根据 递归构建依赖树，按照构建好的依赖树下载完整的依赖资源，在下载时就会检查是否存在相关资源缓存：存在缓存，就会将缓存内容解压到 中；不存在缓存，就从npm远程仓库下载包，并会检验包的完整性，随后添加到缓存，解压到 中生成。
• 最后生成 package-lock.json
  • npmV5.0.x是根据package-lock.json下载
  • npmV5.1.0-5.4.2:当package.json声明的依赖版本规范有符合的更新版本时，会按照package.json安装，并更新package-lock.json
  • npmV5.4.2以上，当package.json声明的依赖版本规范和package-lock.json安装版本兼容，则按照package-lock.json安装，如果不兼容，按照package.json安装，并更新package-lock.json

这里值得注意的是：npm不同版本在检查 package-lock.json 和 package.json 中声明的依赖是否一致的时候处理是不一样的。

npm 安装依赖大致的过程，其中这样几个步骤需要关注：

1. 检查配置。  包括项目级、用户级、全局级、内置的  .npmrc 文件。
2. 确定依赖版本，构建依赖树。  确定项目依赖版本有两个来源，一是 package.json 文件，一是 lockfile 文件,两个确认版本、构建依赖树的来源，互不可少、相辅相成。如果 package-lock.json 文件存在且符合 package.json 声明的的情况下，直接读取；否则重新确认依赖的版本。
3. 下载包资源。  下载前先确认本地是否存在匹配的缓存版本，如果有就直接使用缓存文件，如果没有就下载并添加到缓存，然后将包按依赖树解压到 node_modules 目录。
4. 生成 lockfile 文件。

可以确认这样几个逻辑：

1. 构建依赖树的过程中，版本确认需要结合 package.json 和 package-lock.json 两个文件。先确认 package-lock.json 安装版本，符合规则就以此为准，否则由 package.json 声明的版本范围重新确认。特别地，若是在开发中手动更改包信息，会导致 lockfile 版本信息异常，也可能由 package.json 确认。确认好的依赖树会存到 package-lock.json 文件中，这里跟 yarn.lock 存在差异。
2. 同一个依赖，更高版本的包会安装到顶层目录，即 node_modules 目录；否则会分散在某些依赖的 node_modules 目录，如：node_modules/expect-jsx/node_modules/react 目录。
3. 如果依赖升级，造成版本不兼容，需要多版本共存，那么仍然是将高版本安装到顶层，低版本分散到各级目录。
4. lockfile 的存在，保证了项目依赖结构的确定性，保障了项目在多环境运行的稳定性。

上面说到了 的时候会检查项目中是否有 文件，文件的出现是为了解决 的不确定性问题 ，在 版本新增了 文件。

它的作用是锁定依赖结构，只要你目录下有 文件，那么你每次执行 后生成的 目录结构一定是完全相同的。

文件说明：

• ： 包版本,这个包当前安装在 中的版本
• ： 包具体的安装来源
• ：包 `` 值，基于 来验证已安装的软件包是否被改动过、是否已失效源
• ： 对应子依赖的依赖，与子依赖的 中 的依赖项相同
• ： 结构和外层的 dependencies 结构相同，存储安装在子依赖 node_modules 中的依赖包。

这里注意，并不是所有的子依赖都有 属性，只有子依赖的依赖和当前已安装在根目录的 中的依赖冲突之后，才会有这个属性。

嵌套结构

在早期，之前，是嵌套结构，就是我们开篇问的我们的应用依赖了公共库 A 和公共库 B，同时公共库 A 也依赖了公共库 B，之前公共库 B 会被多次安装。结构如图：

这样的方式优点很明显， 的结构和 结构一一对应，层级结构明显，并且保证了每次安装目录结构都是相同的。

但是，试想一下，如果你依赖的模块非常之多，你的 将非常庞大，嵌套层级非常之深:

• 在不同层级的依赖中，可能引用了同一个模块，导致大量冗余。
• 在 系统中，文件路径最大长度为个字符，嵌套层级过深可能导致不可预知的问题

扁平结构

为了解决以上问题， 在 版本做了一次较大更新。其将早期的嵌套结构改为扁平结构: 安装模块时，不管其是直接依赖还是子依赖的依赖，优先将其安装在 根目录。还是上面的依赖结构，我们在执行 后将得到下面的目录结构。

对应的，如果我们在项目代码中引用了一个模块，模块查找流程如下:

1. 在当前模块路径下搜索
2. 在当前模块 路径下搜素
3. 在上级模块的 路径下搜索
4. 直到搜索到全局路径中的

但是有一种情况是，你的应用中，没有直接依赖公共库D，比如公共库C和公共库B依赖了不同版本的公共库D

所以 npm 3.x 版本并未完全解决老版本的模块冗余问题，甚至还会带来新的问题,因为在执行 npm install 的时候，按照 package.json 里依赖的顺序依次解析，公共库B和公共库C在 package.json的放置顺序则决定了 node_modules 的依赖结构。

在执行 npm install 或 npm update命令下载依赖后，除了将依赖包安装在 目录下外，还会在本地的缓存目录缓存一份。

通过命令可以查询到： 目录

• index-v5 文件中，存储tar包的 hash

npm 在执行安装时，可以根据 中存储的 、、 生成一个唯一的 对应到 目录下的缓存记录，从而找到 包的 ，然后根据 再去找缓存的 包，通过pacote对应的二进制文件解压到对应项目的 node_modules 下面，省去了网络下载资源的开销。

注意：以上的缓存策略是从 npm v5 版本开始的，在 npm v5 版本之前，每个缓存的模块在 ~/.npm 文件夹中以模块名的形式直接存储，储存结构是{cache}/{name}/{version}

npm 提供了几个命令来管理缓存数据：

• ： 官方解释说这个命令主要是 内部使用，但是也可以用来手动给一个指定的 添加缓存。
• ： 删除缓存目录下的所有数据，为了保证缓存数据的完整性，需要加上 参数
• ： 验证缓存数据的有效性和完整性，清理垃圾数据

由 版本引入，解决了 的一些使用快速开发、调试，以及项目内使用全局模块的痛点。

执行模块时会优先安装依赖，但是在安装执行后便删除此依赖，这就避免了全局安装模块带来的问题。

使用代码检测工具 ESLint比较方便

• npx eslint --init
• npx eslint yourfile.js

按照字母排序

npm 中的源（registry），其实就是一个查询服务。以 为例，它的查询服务网址是 registry.npmjs.org/ 这个网址后面跟上模块名，就会得到一个 JSON 对象，里面是该模块所有版本的信息。

在日常开发中，我们也常常会 发现直接用 npm 安装库有时候非常慢，容易安装失败，因为npm安装插件是从国外服务器下载，受网络的影响比较大，可能会出现异常。最好的解决方案是使用淘宝镜像 cnpm替代npm，正如它官网所描述。

这是一个完整  镜像，你可以用此代替官方版本(只读)，同步频率目前为 10分钟 一次以保证尽量与官方服务同步。

我们可以直接全局使用命令行工具代替默认的

当然你可能不喜欢用cnpm命令，为了方便开发，我们可以把npm的源设置为淘宝镜像

查看npm镜像源

nrm(npm registry manager )是npm的镜像源管理工具。它可以快速在让你在本地源之间切换。

• nrm安装

• 查看当前可使用的镜像源

• 切换镜像源 使用 taobao 镜像源

当我们业务规模达到一定程度的时候，可能会有一些自己公司私有的的UI的封装或者模块封装，不想通过npm发布，但是又想在一些项目和其他团队共享使用，而且我们不想将公共模块是复制到各个项目中来使用。这时候搭建NPM私有库就显得很有必要。

• 私有库只针对公司内部局域网开放，作为内部前端资产，不对外公开，也算是公司前端团队的一个技术亮点
• 速度比在直接在下载更快，甚至是比淘宝源更快，私有库能够将包资源进行缓存，响应的话会加快下载速度
• 对于发布和下载包配置权限管理

搭建npm私有库的方式很多，笔者推荐一款简单的轻量级私有 NPM 仓库（verdaccio.org）

它的原理就是我们平时使用进行发布时，上传的仓库默认地址是，通过工具在本地新建一个仓库地址，再把本地的默认上传仓库地址切换到本地仓库地址即可。当时没有找到本地的仓库，则默认配置中会从中央仓库下载。当然它还可以设置钉钉机器人推送发布消息呢！

具体安装部署细节可以移步到Verdaccio官网

npm 私服：nexus、verdaccio 以及 cnpm。

• nexus：blog.csdn.net/lh87522/art…
• NPM 私有仓库搭建完全指南：mp.weixin..com/s/Cfi3-AtR7…
• 搭一个私有Npm仓库：mp.weixin..com/s/xRME75knX…
• npm 私服工具verdaccio 搭建(一) ：blog.csdn.net/yyzzhc999/a…
• npm 私服工具verdaccio 搭建(二) yangxiaohui.blog.csdn.net/article/det…

（1）推荐使用 npm v5.4.2 以上的 npm 版本，享受npm 的最基本先进性和稳定性。

（2）项目的第一次搭建使用 npm install 安装依赖包，并提交 package.json、package-lock.json，当然要排除 node_modules 目录。

（3）其他项目成员首次 checkout/clone 项目代码后，执行一次 npm install 安装依赖包。

（4）对于升级依赖包的需求：

依靠 npm update 命令升级到新的小版本；

依靠 npm install @ （指定版本）升级大版本；

也可以手动修改 package.json 中版本号，并执行 npm install 来升级版本；

本地验证升级后新版本无问题（比如element各个版本有些不兼容的情况）

（5）对于降级依赖包的需求：执行 npm install @ （指定版本）命令，指定版本

（6）删除项目中某些依赖：执行 npm uninstall 命令， 或者手动操作 package.json删除依赖。

（7）任何团队成员提交 package.json、package-lock.json 更新后，其他成员应该拉取代码后，执行 npm install 更新依赖。

（8）如果 package-lock.json 出现冲突或问题，建议将本地的 package-lock.json 文件删除，引入远程的 package-lock.json 文件和 package.json，再执行 npm install 命令。

（1） node_modules 删除无权限

解决办法： 通过npm命令来删除node_modules文件夹

• 1.首先通过npm安装删除工具

• 2.安装淘宝镜像后可以使用

• 3.使用删除命令

（2） Error: Cannot find module ‘node-sass’

sass-loader@8.0.0以上版本的时候不需要再安装node-sass, 有时候也会报没有python，也是因为node-sass 需要这个环境导致

解决办法：

当然大多数时候是你电脑本机的node版本和项目里的 node-sass包之间的版本存在兼容问题，可以通过node-sass查看版本支持情况。

npm install (简写:npm i)来安装package.json文件中的依赖包到dependencies或devDependencies。

• dependencies：是运行时的依赖
• devDependencies：是开发时的依赖

查看当前项目的所有 npm 脚本命令（其实也可以在package.json的看scripts对象里有什么属性）

安装包命令

获取包安装信息

升级依赖包

卸载依赖包

npm uninstall的别名：npm remove、npm remove、npm rm、 npm r、npm un、 npm unlink

表示任意文件名，表示任意一层子目录

将通配符传入原始命令，防止被 Shell 转义，要将星号转义

向 npm 脚本传入参数，要使用标明

• zhuanlan.zhihu.com/p/

作为区别于 的依赖管理工具，诞生之初就是为了解决历史上 的某些不足，比如 缺乏对于依赖的完整性和一致性保障，以及 安装速度过慢的问题等，尽管 发展至今，已经在很多方面向 看齐，但 的安装理念仍然需要我们关注。 提出的安装理念很好的解决了当时 的依赖管理问题：

1. 确定性。通过 yarn.lock 等机制，保证了确定性，这里的确定性包括但不限于明确的依赖版本、明确的依赖安装结构等。即在任何机器和环境下，都可以以相同的方式被安装。
2. 模块扁平化安装。将依赖包的不同版本，按照一定策略，归结为单个版本，以避免创建多个副本造成冗余。（npm 也有相同的优化)
3. 更好的网络性能。Yarn 采用了请求排队的理念，类似并发连接池，能够更好地利用网络资源；同时引入了更好的安装失败时的重试机制。（npm 较早的版本是顺序下载，当第一个包完全下载完成后，才会将下载控制权交给下一个包)
4. 引入缓存机制，实现离线策略。（npm 也有类似的优化)

从上面依赖版本描述的信息中，可以确定以下几点：

1. 所有依赖，不管是项目声明的依赖，还是依赖的依赖，都是扁平化管理。
2. 依赖的版本是由所有依赖的版本声明范围确定的，具备相同版本声明范围的依赖归结为一类，确定一个该范围下的依赖版本。如果同一个依赖多个版本共存，那么会并列归类。
3. 每个依赖确定的版本中，是由以下几项构成：
4. 多个依赖的声明版本，且符合 semver 规范；
5. 确定的版本号 version 字段；
6. 版本的完整性验证字段
7. 依赖列表
8. 相比 npm，Yarn 一个显著区别是 yarn.lock 中子依赖的版本号不是固定版本。  也就是说单独一个 yarn.lock 确定不了 node_modules 目录结构，还需要和 package.json 文件进行配合。

以下是在 yarn 安装依赖时的步骤：

1、检查（checking）  主要是检查项目中是否存在一些 npm 相关的配置文件，如 package-lock.json 等。如果存在，可能会警告提示，因为它们可能会存在冲突。在这一阶段，也会检查系统 OS、CPU 等信息。

2、解析包（resolving packages）  这一步主要是解析依赖树，确定版本信息等。 首先获取项目 package.json 中声明的首层依赖，包括 dependencies, devDependencies, optionalDependencies 声明的依赖。 接着采用遍历首层依赖的方式获取依赖包的版本信息，以及递归查找每个依赖下嵌套依赖的版本信息，并将解析过和正在解析的包用一个 Set 数据结构来存储，这样就能保证同一个版本范围内的包不会被重复解析。

• 对于没有解析过的包，首次尝试从 yarn.lock 中获取到版本信息，并标记为已解析；
• 如果在 yarn.lock 中没有找到包，则向 Registry 发起请求获取满足版本范围的已知最高版本的包信息，获取后将当前包标记为已解析。 总之，在经过复杂的解析算法后，我们就确定了所有依赖的具体版本信息以及下载地址。

3、获取包（fetching packages）  这一步主要是利用系统缓存，到缓存中找到具体的包资源。首先会尝试在缓存中查找依赖包，如果没有命中缓存，则将依赖包下载到缓存中。 对于没有命中缓存的包，Yarn 会维护一个 fetch 队列，按照规则进行网络请求。这里也是 yarn 诞生之初解决 npm v3 安装缓慢问题的优化点，支持并行下载。

4、链接包（linking dependencies）  这一步主要是将缓存中的依赖，复制到项目目录下，同时遵循扁平化原则。前面说到，npm 优先将依赖安装到项目目录，因此需要将全局缓存中的依赖复制到项目。 在复制依赖前，Yarn 会先解析 peerDependencies，如果找不到符合 peerDependencies 声明的依赖版本，则进行 warning 提示（这并不会影响命令执行），并最终拷贝依赖到项目中。

5、构建包（building fresh package）  如果依赖包中存在二进制包需要进行编译，会在这一步进行。

这里简单对比 npm v6 和 yarn v1. 这是我们生产开发常用的版本。 npm 和 yarn 作为两款相似的包管理工具，在一些功能实现上它们互相获取灵感。

相同点：

1. package.json 作为项目依赖描述文件
2. node_modules 作为依赖存储目录，yarn v2 不再是这样
3. lockfile 锁定版本依赖，在 yarn 中叫 yarn.lock，在 npm 中叫 package-lock.json，在 npm v7 也支持了 yarn.lock。它确保在不同机器或不同环境中，能够得到稳定的 node_modules 目录结构。

差异：

1. 依赖管理策略。
2. lockfile。package-lock.json 自带版本锁定+依赖结构，你想改动一些依赖，可能影响的范围要比表面看起开的复杂的多；而 yarn.lock 自带版本锁定，并没有确定的依赖结构，使用 yarn 管理项目依赖，需要 package.json + yarn.lock 共同确定依赖的结构。。
3. 性能。（对比 npm v6 和 yarn v1）目前 npm v7 优化了缓存和下载网络策略，性能的差异在缩小

yarn add 依赖名@版本号

版本号尽可能高一些，必须比现有的所有版本都要高(这步是关键)

选择合适的版本

版本说明：

• alpha版：内部测试版。
• beta版：公开测试版。
• rc版：候选版本（可用于学习，不是特别重要的项目可使用此版本）
• stable版：稳定版（开发使用）

• pnpm中文网
• juejin.cn/post/…
• 使用pnpm管理node版本

快速的，节省磁盘空间的包管理工具。作用是跟和一样的呢。那既然功能是一样的为什么又要出现一个呢？通过官方的文档我们可以看出来它的优势在于：

• 包安装速度极快
• 磁盘空间利用效率高

（1）包安装速度极快

比传统方案安装包的速度快了两倍，以下是官方给出的benchmarks(对比了npm, pnpm, Yarn Classic, and Yarn PnP)，在多种常见情况下，执行install的速度比较。

为什么pnpm要比其他的包处理器要快呢？

主要得益于它的包管理机制，实现了节约磁盘空间并提升安装速度（也就是第二个优势）

（2）磁盘空间利用效率高

pnpm 的  布局使用符号链接来创建依赖项的嵌套结构。 中每个包的每个文件都是来自内容可寻址存储的硬链接。

那么为什么说pnpm这种的方式对磁盘空间利用效率比较高呢

• 不会重复安装同一个包。使用 的时候，如果100个包依赖 ，那么就可能安装了100次 ，磁盘中就有100个地方写入了这部分代码。但是会只在一个地方写入这部分代码，后面使用会直接使用硬链接。
• 即使一个包的不同版本，pnpm 也会极大程度地复用之前版本的代码。举个例子，比如  和的两个版本升级对比，只是重新下载了19个新的更新的包。

与和的不同点主要是从包的依赖管理方面来说明。

npm2生成的依赖管理比较的简单直接，会按照安装包的依赖树形结构直接填充在本地的目录结构下：

比如和他们会同时依赖，那么在之后生成的就会是如下结构：

npm2的这种方式的优点就是，但是呢缺点也是显而易见的就是:

1. 层级依赖过深
2. 相同包的相同版本会多次被下载，利用率低，占用磁盘空间大

针对npm2的两个缺点呢，npm3做了个改变，不再使用嵌套的结构了，而是讲依赖进行打平，这样就能解决层级依赖深和包的利用率的问题，那么上面的依赖关系就会变成下面这个样子：

我们可以看出，和引用了的版本是一样的，这样才会被平铺在下，那如果引用的包的版本不一样又是什么样的情况呢？就像, 、等这几个包

• 引入的是:、、
• 引入的是:、、

此时，在结构是下面这个样子：

至于为什么说的依赖包会在根目录的下呢，这是npm自己的一个规则，具体可以看一下与你项目相关的npm知识总结

npm3的这种平铺方式确实是解决了层级依赖深和包的利用率的问题，但是也引入了其他的问题：

1. 对没有手动引入的包，例如依赖的，项目中手动引入，但是依然可以使用，这样就造成了如果哪天express改变了策略不在使用cookie，而我们的项目中又使用了cookie，这样就会导致项目无法启动
2. 虽然npm是共享了相同版本的依赖，但是如果版本不同，npm还是会完整的下载两个不同的版本，这样也会有依赖的冗余

pnpm为了解决npm3带来的一些问题呢，采用了另外一种方式来管理依赖：pnpm 的  布局使用符号链接来创建依赖项的嵌套结构管。

 中下每个包的每个文件都是来自内容可寻址存储的硬链接。

这是  中的唯一的“真实”文件。 一旦所有包都硬链接到 ，就会创建符号链接来构建嵌套的依赖关系图结构。

我们用pnpm安装一下和，生成的目录如下所示：

在中的依赖只有在中手动引入的依赖和，细心的你会发现这两个文件后面有一个箭头，而这个箭头就是pnpm使用的软连接的方式指向了文件真正的文件：

这些文件会在内存中统一存储，如果有依赖不同版本的时候，pnpm也只会下载不同版本中不同的内容。

官方对比

（1）使用独立脚本安装

（2）使用npm安装

（3）使用homebrew安装

以下是列出常用的命令，具体可以参考官网管理依赖

（1）安装依赖包

（2）下载所有依赖

or

（3）指定的范围更新软件包的最新版本

or

（4）删除依赖

或 或 或

（5）运行脚本

• 运行一个在 的 manifest 文件中定义的脚本:
• 运行在 的 对象中 属性指定的任意的命令:
• 从  或  启动套件创建项目:,例如
• 运行在 的 对象中 属性指定的任意的命令: or

到此这篇yarn查看任务状态（查看当前yarn运行任务列表采用什么命令）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/33071.html