前端基础建设与架构03CI环境上的npm优化及更多工程化问题解析

前两讲&＃xff0c;我们围绕着 npm 和 Yarn 的核心原理展开了讲解&＃xff0c;实际上 npm 和 Yarn 涉及项目的方方面面&＃xff0c;加之本身设计复杂度较高&＃xff0c;这一讲我将继续讲解 CI 环境上的 npm 优化以及更多工程化相关问题。希望通过这一讲的学习你能够学习到 CI 环境上使用包管理工具的方方面面&＃xff0c;并能够解决非本地环境下&＃xff08;一般是在容器上&＃xff09;使用包管理工具解决相关问题。

CI 环境上的 npm 优化

CI 环境下的 npm 配置和开发者本地 npm 操作有些许不同&＃xff0c;接下来我们一起看看 CI 环境上的 npm 相关优化。

合理使用 npm ci 和 npm install

顾名思义&＃xff0c;npm ci 就是专门为 CI 环境准备的安装命令&＃xff0c;相比 npm install 它的不同之处在于&＃xff1a;

• npm ci 要求项目中必须存在 package-lock.json 或 npm-shrinkwrap.json&＃xff1b;

• npm ci 完全根据 package-lock.json 安装依赖&＃xff0c;这可以保证整个开发团队都使用版本完全一致的依赖&＃xff1b;

• 正因为 npm ci 完全根据 package-lock.json 安装依赖&＃xff0c;在安装过程中&＃xff0c;它不需要计算求解依赖满足问题、构造依赖树&＃xff0c;因此安装过程会更加迅速&＃xff1b;

• npm ci 在执行安装时&＃xff0c;会先删除项目中现有的 node_modules&＃xff0c;然后全新安装&＃xff1b;

• npm ci 只能一次安装整个项目所有依赖包&＃xff0c;无法安装单个依赖包&＃xff1b;

• 如果 package-lock.json 和 package.json 冲突&＃xff0c;那么 npm ci 会直接报错&＃xff0c;并非更新 lockfiles&＃xff1b;

• npm ci 永远不会改变 package.json 和 package-lock.json。

基于以上特性&＃xff0c;我们在 CI 环境使用 npm ci 代替 npm install&＃xff0c;一般会获得更加稳定、一致和迅速的安装体验。

更多 npm ci 的内容你也可以在官网查看。

使用 package-lock.json 优化依赖安装时间

上面提到过&＃xff0c;对于应用项目&＃xff0c;建议上传 package-lock.json 到仓库中&＃xff0c;以保证依赖安装的一致性。事实上&＃xff0c;如果项目中使用了 package-lock.json 一般还可以显著加速依赖安装时间。这是因为package-lock.json 中已经缓存了每个包的具体版本和下载链接&＃xff0c;你不需要再去远程仓库进行查询&＃xff0c;即可直接进入文件完整性校验环节&＃xff0c;减少了大量网络请求。

除了上面所述内容&＃xff0c;CI 环境上&＃xff0c;缓存 node_modules 文件也是企业级使用包管理工具常用的优化做法。

更多工程化相关问题解析

下面这部分&＃xff0c;我将通过剖析几个问题&＃xff0c;来加深你对这几讲学习概念的理解&＃xff0c;以及对工程化中可能遇到的问题进行预演。

为什么要 lockfiles&＃xff0c;要不要提交 lockfiles 到仓库&＃xff1f;

从 npm v5 版本开始&＃xff0c;增加了 package-lock.json 文件。我们知道package-lock.json 文件的作用是锁定依赖安装结构&＃xff0c;目的是保证在任意机器上执行 npm install 都会得到完全相同的 node_modules 安装结果。

你需要明确&＃xff0c;为什么单一的 package.json 不能确定唯一的依赖树&＃xff1a;

• 不同版本的 npm 的安装依赖策略和算法不同&＃xff1b;

• npm install 将根据 package.json 中的 semver-range version 更新依赖&＃xff0c;某些依赖项自上次安装以来&＃xff0c;可能已发布了新版本。

因此&＃xff0c;保证能够完整准确地还原项目依赖&＃xff0c;就是 lockfiles 出现的原因。

首先我们了解一下 package-lock.json 的作用机制。上一讲中我们已经解析了 yarn.lock 文件结构&＃xff0c;这里我们看下 package-lock.json 的内容举例&＃xff1a;

"&＃64;babel/core": {"version": "7.2.0","resolved": "http://www.npm.com/&＃64;babel%2fcore/-/core-7.2.0.tgz","integrity": "sha1-pN04FJAZmOkzQPAIbphn/voWOto&＃61;","dev": true,"requires": {"&＃64;babel/code-frame": "^7.0.0",// ...},"dependencies": {"&＃64;babel/generator": {"version": "7.2.0","resolved": "http://www.npm.com/&＃64;babel%2fgenerator/-/generator-7.2.0.tgz","integrity": "sha1-6vOCH6AwHZ1K74jmPUvMGbc7oWw&＃61;","dev": true,"requires": {"&＃64;babel/types": "^7.2.0","jsesc": "^2.5.1","lodash": "^4.17.10","source-map": "^0.5.0","trim-right": "^1.0.1"}},// ...}},// ...
}


通过上述代码示例&＃xff0c;我们看到&＃xff1a;一个 package-lock.json 的 dependency 主要由以下部分构成。

• Version&＃xff1a;依赖包的版本号

• Resolved&＃xff1a;依赖包安装源&＃xff08;可简单理解为下载地址&＃xff09;

• Integrity&＃xff1a;表明包完整性的 Hash 值

• Dev&＃xff1a;表示该模块是否为顶级模块的开发依赖或者是一个的传递依赖关系

• requires&＃xff1a;依赖包所需要的所有依赖项&＃xff0c;对应依赖包 package.json 里 dependencies 中的依赖项

• dependencies&＃xff1a;依赖包 node_modules 中依赖的包&＃xff08;特殊情况下才存在&＃xff09;

事实上&＃xff0c;并不是所有的子依赖都有 dependencies 属性&＃xff0c;只有子依赖的依赖和当前已安装在根目录的 node_modules 中的依赖冲突之后&＃xff0c;才会有这个属性。这就涉及嵌套情况的依赖管理&＃xff0c;我已经在前文做了说明。

至于要不要提交 lockfiles 到仓库&＃xff1f;这就需要看项目定位决定了。

• 如果开发一个应用&＃xff0c;我建议把 package-lock.json 文件提交到代码版本仓库。这样可以保证项目组成员、运维部署成员或者 CI 系统&＃xff0c;在执行 npm install 后&＃xff0c;能得到完全一致的依赖安装内容。

• 如果你的目标是开发一个给外部使用的库&＃xff0c;那就要谨慎考虑了&＃xff0c;因为库项目一般是被其他项目依赖的&＃xff0c;在不使用 package-lock.json 的情况下&＃xff0c;就可以复用主项目已经加载过的包&＃xff0c;减少依赖重复和体积。

• 如果我们开发的库依赖了一个精确版本号的模块&＃xff0c;那么提交 lockfiles 到仓库可能会造成同一个依赖不同版本都被下载的情况。如果作为库开发者&＃xff0c;真的有使用某个特定版本依赖的需要&＃xff0c;一个更好的方式是定义 peerDependencies。

因此&＃xff0c;一个推荐的做法是&＃xff1a;把 package-lock.json 一起提交到代码库中&＃xff0c;不需要 ignore。但是执行 npm publish 命令&＃xff0c;发布一个库的时候&＃xff0c;它应该被忽略而不是直接发布出去。

理解上述概念并不够&＃xff0c;对于 lockfiles 的处理&＃xff0c;你需要更加精细。这里我列出几条建议供你参考。

1. 早期 npm 锁定版本的方式是使用 npm-shrinkwrap.json&＃xff0c;它与 package-lock.json 不同点在于&＃xff1a;npm 包发布的时候默认将 npm-shrinkwrap.json 发布&＃xff0c;因此类库或者组件需要慎重。

2. 使用 package-lock.json 是 npm v5.x 版本新增特性&＃xff0c;而 npm v5.6 以上才逐步稳定&＃xff0c;在 5.0 - 5.6 中间&＃xff0c;对 package-lock.json 的处理逻辑进行过几次更新。

3. 在 npm v5.0.x 版本中&＃xff0c;npm install 时都会根据 package-lock.json 文件下载&＃xff0c;不管 package.json 内容究竟是什么。

4. npm v5.1.0 版本到 npm v5.4.2&＃xff0c;npm install 会无视 package-lock.json 文件&＃xff0c;会去下载最新的 npm 包并且更新 package-lock.json。

5. npm 5.4.2 版本后&＃xff1a;

• 如果项目中只有 package.json 文件&＃xff0c;npm install 之后&＃xff0c;会根据它生成一个 package-lock.json 文件&＃xff1b;

• 如果项目中存在 package.json 和 package-lock.json 文件&＃xff0c;同时 package.json 的 semver-range 版本 和 package-lock.json 中版本兼容&＃xff0c;即使此时有新的适用版本&＃xff0c;npm install 还是会根据 package-lock.json 下载&＃xff1b;

• 如果项目中存在 package.json 和 package-lock.json 文件&＃xff0c;同时 package.json 的 semver-range 版本和 package-lock.json 中版本不兼容&＃xff0c;npm install 时 package-lock.json 将会更新到兼容 package.json 的版本&＃xff1b;

• 如果 package-lock.json 和 npm-shrinkwrap.json 同时存在于项目根目录&＃xff0c;package-lock.json 将会被忽略。

以上内容你可以结合 01 讲中 npm 安装流程进一步理解。

为什么有 xxxDependencies&＃xff1f;

npm 设计了以下几种依赖类型声明&＃xff1a;

• dependencies 项目依赖

• devDependencies 开发依赖

• peerDependencies 同版本依赖

• bundledDependencies 捆绑依赖

• optionalDependencies 可选依赖

它们起到的作用和声明意义各不相同。dependencies 表示项目依赖&＃xff0c;这些依赖都会成为线上生产环境中的代码组成部分。当它关联的 npm 包被下载时&＃xff0c;dependencies 下的模块也会作为依赖&＃xff0c;一起被下载。

devDependencies 表示开发依赖&＃xff0c;不会被自动下载&＃xff0c;因为 devDependencies 一般只在开发阶段起作用或只是在开发环境中需要用到。比如 Webpack&＃xff0c;预处理器 babel-loader、scss-loader&＃xff0c;测试工具 E2E、Chai 等&＃xff0c;这些都是辅助开发的工具包&＃xff0c;无须在生产环境使用。

这里需要特别说明的是&＃xff1a;并不是只有在 dependencies 中的模块才会被一起打包&＃xff0c;而在 devDependencies 中的依赖一定不会被打包。实际上&＃xff0c;依赖是否被打包&＃xff0c;完全取决于项目里是否被引入了该模块。dependencies 和 devDependencies 在业务中更多的只是一个规范作用&＃xff0c;我们自己的应用项目中&＃xff0c;使用 npm install 命令安装依赖时&＃xff0c;dependencies 和 devDependencies 内容都会被下载。

peerDependencies 表示同版本依赖&＃xff0c;简单来说就是&＃xff1a;如果你安装我&＃xff0c;那么你最好也安装我对应的依赖。举个例子&＃xff0c;假设 react-ui&＃64;1.2.2 只提供一套基于 React 的 UI 组件库&＃xff0c;它需要宿主环境提供指定的 React 版本来搭配使用&＃xff0c;因此我们需要在 React-ui 的 package.json 中配置&＃xff1a;

"peerDependencies": {"React": "^17.0.0"
}


举一个场景实例&＃xff0c;对于插件类 (Plugin) 项目&＃xff0c;比如我开发一个 Koa 中间件&＃xff0c;很明显这类插件或组件脱离&＃xff08;Koa&＃xff09;本体是不能单独运行且毫无意义的&＃xff0c;但是这类插件又无须声明对本体&＃xff08;Koa&＃xff09;的依赖声明&＃xff0c;更好的方式是使用宿主项目中的本体&＃xff08;Koa&＃xff09;依赖。这就是peerDependencies 主要的使用场景。这类场景有以下特点&＃xff1a;

• 插件不能单独运行

• 插件正确运行的前提是核心依赖库必须先下载安装

• 我们不希望核心依赖库被重复下载

• 插件 API 的设计必须要符合核心依赖库的插件编写规范

• 在项目中&＃xff0c;同一插件体系下&＃xff0c;核心依赖库版本最好相同

bundledDependencies 和 npm pack 打包命令有关。假设 package.json 中有如下配置&＃xff1a;

{"name": "test","version": "1.0.0","dependencies": {"dep": "^0.0.2",...},"devDependencies": {..."devD1": "^1.0.0"},"bundledDependencies": ["bundleD1","bundleD2"]
}


在执行 npm pack 时&＃xff0c;就会产出一个 test-1.0.0.tgz 压缩包&＃xff0c;且该压缩包中包含了 bundle D1 和 bundle D2 两个安装包。业务方使用 npm install test-1.0.0.tgz 命令时&＃xff0c;也会安装 bundle D1 和 bundle D2。

这里你需要注意的是&＃xff1a;在 bundledDependencies 中指定的依赖包&＃xff0c;必须先在 dependencies 和 devDependencies 声明过&＃xff0c;否则在 npm pack 阶段会进行报错。

optionalDependencies 表示可选依赖&＃xff0c;就是说即使对应依赖项安装失败了&＃xff0c;也不会影响整个安装过程。一般我们很少使用到它&＃xff0c;这里我也不建议大家使用&＃xff0c;因为它大概率会增加项目的不确定性和复杂性。

学习了以上内容&＃xff0c;现在你已经知道 npm 规范中的相关依赖声明含义了&＃xff0c;接下来我们再谈谈版本规范&＃xff0c;帮助你进一步解析依赖库锁版本行为。

再谈版本规范——依赖库锁版本行为解析

npm 遵循 SemVer 版本规范&＃xff0c;具体内容你可以参考语义化版本 2.0.0&＃xff0c;这里不再展开。这部分内容我希望聚焦到工程建设的一个细节点上——依赖库锁版本行为。

Vue 官方有这样的内容&＃xff1a;

每个 vue 包的新版本发布时&＃xff0c;一个相应版本的 vue-template-compiler 也会随之发布。编译器的版本必须和基本的 vue 包保持同步&＃xff0c;这样 vue-loader 就会生成兼容运行时的代码。这意味着你每次升级项目中的 vue 包时&＃xff0c;也应该匹配升级 vue-template-compiler。

据此&＃xff0c;我们需要考虑的是&＃xff1a;作为库开发者&＃xff0c;如何保证依赖包之间的强制最低版本要求&＃xff1f;

我们先看看 create-react-app 的做法&＃xff0c;在 create-react-app 的核心 react-script 当中&＃xff0c;它利用 verify PackageTree 方法&＃xff0c;对业务项目中的依赖进行比对和限制。源码如下&＃xff1a;

function verifyPackageTree() {const depsToCheck &＃61; [&＃39;babel-eslint&＃39;,&＃39;babel-jest&＃39;,&＃39;babel-loader&＃39;,&＃39;eslint&＃39;,&＃39;jest&＃39;,&＃39;webpack&＃39;,&＃39;webpack-dev-server&＃39;,];const getSemverRegex &＃61; () &＃61;>/\bv?(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)\.(?:0|[1-9]\d*)(?:-[\da-z-]&＃43;(?:\.[\da-z-]&＃43;)*)?(?:\&＃43;[\da-z-]&＃43;(?:\.[\da-z-]&＃43;)*)?\b/gi;const ownPackageJson &＃61; require(&＃39;../../package.json&＃39;);const expectedVersionsByDep &＃61; {};depsToCheck.forEach(dep &＃61;> {const expectedVersion &＃61; ownPackageJson.dependencies[dep];if (!expectedVersion) {throw new Error(&＃39;This dependency list is outdated, fix it.&＃39;);}if (!getSemverRegex().test(expectedVersion)) {throw new Error(&＃96;The ${dep} package should be pinned, instead got version ${expectedVersion}.&＃96;);}expectedVersionsByDep[dep] &＃61; expectedVersion;});


let currentDir &＃61; __dirname;

while (true) {
const previousDir &＃61; currentDir;
currentDir &＃61; path.resolve(currentDir, ‘…’);
if (currentDir &＃61;&＃61;&＃61; previousDir) {
// We’ve reached the root.
break;
}
const maybeNodeModules &＃61; path.resolve(currentDir, ‘node_modules’);
if (!fs.existsSync(maybeNodeModules)) {
continue;
}
depsToCheck.forEach(dep &＃61;> {
const maybeDep &＃61; path.resolve(maybeNodeModules, dep);
if (!fs.existsSync(maybeDep)) {
return;
}
const maybeDepPackageJson &＃61; path.resolve(maybeDep, ‘package.json’);
if (!fs.existsSync(maybeDepPackageJson)) {
return;
}
const depPackageJson &＃61; JSON.parse(
fs.readFileSync(maybeDepPackageJson, ‘utf8’)
);
const expectedVersion &＃61; expectedVersionsByDep[dep];
if (!semver.satisfies(depPackageJson.version, expectedVersion)) {
console.error(//…);
process.exit(1);
}
});
}
}

根据上述代码&＃xff0c;我们不难发现&＃xff0c;create-react-app 会对项目中的 babel-eslint、babel-jest、babel-loader、ESLint、Jest、webpack、webpack-dev-server 这些核心依赖进行检索——是否符合 create-react-app 对这些核心依赖的版本要求。如果不符合依赖版本要求&＃xff0c;那么 create-react-app 的构建过程会直接报错并退出。

create-react-app 这么做的理由是&＃xff1a;需要上述依赖项的某些确定版本&＃xff0c;以保障 create-react-app 源码的相关功能稳定。

我认为这样做看似强硬且无理由&＃xff0c;实则是对前端社区、npm 版本混乱现象的一种妥协。这种妥协确实能保证 create-react-app 的正常构建工作。因此现阶段来看&＃xff0c;也不失为一种值得推荐的做法。而作为 create-react-app 的使用者&＃xff0c;我们依然可以通过 SKIP_PREFLIGHT_CHECK 这个环境变量&＃xff0c;跳过核心依赖版本检查&＃xff0c;对应源码&＃xff1a;

const verifyPackageTree &＃61; require(&＃39;./utils/verifyPackageTree&＃39;);
if (process.env.SKIP_PREFLIGHT_CHECK !&＃61;&＃61; &＃39;true&＃39;) {verifyPackageTree();
}


create-react-app 的锁版本行为无疑彰显了目前前端社区中工程依赖问题的方方面面&＃xff0c;从这个细节管中窥豹&＃xff0c;希望能引起你更深入的思考。

最佳实操建议

前面我们讲了很多 npm 的原理和设计理念&＃xff0c;理解了这些内容&＃xff0c;你应该能总结出一个适用于团队的最佳实操建议。对于实操我有以下想法&＃xff0c;供你参考。

1. 优先使用 npm v5.4.2 以上的 npm 版本&＃xff0c;以保证 npm 的最基本先进性和稳定性。

2. 项目的第一次搭建使用 npm install 安装依赖包&＃xff0c;并提交 package.json、package-lock.json&＃xff0c;而不提交 node_modules 目录。

3. 其他项目成员首次 checkout/clone 项目代码后&＃xff0c;执行一次 npm install 安装依赖包。

4. 对于升级依赖包的需求&＃xff1a;

• 依靠 npm update 命令升级到新的小版本&＃xff1b;

• 依靠 npm install &＃64; 升级大版本&＃xff1b;

• 也可以手动修改 package.json 中版本号&＃xff0c;并执行 npm install 来升级版本&＃xff1b;

• 本地验证升级后新版本无问题&＃xff0c;提交新的 package.json、package-lock.json 文件。

5. 对于降级依赖包的需求&＃xff1a;执行 npm install &＃64; 命令&＃xff0c;验证没问题后&＃xff0c;提交新的 package.json、package-lock.json 文件。

6. 删除某些依赖&＃xff1a;

• 执行 npm uninstall 命令&＃xff0c;验证没问题后&＃xff0c;提交新的 package.json、package-lock.json 文件&＃xff1b;

• 或者手动操作 package.json&＃xff0c;删除依赖&＃xff0c;执行 npm install 命令&＃xff0c;验证没问题后&＃xff0c;提交新的 package.json、package-lock.json 文件。

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

8. 任何时候都不要修改 package-lock.json。

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

如果以上建议你都能理解&＃xff0c;并能够解释其中缘由&＃xff0c;那么这三讲内容&＃xff0c;你已经大致掌握了。

总结

通过本讲学习&＃xff0c;相信你已经掌握了在 CI 环境中优化包管理器的方法以及更多、更全面的 npm 设计规范。希望不管是在本地开发&＃xff0c;还是 CI 环境中&＃xff0c;你在面对包管理方面的问题时能够游刃有余&＃xff0c;轻松面对。

随着前端的发展&＃xff0c;npm/Yarn 也在互相借鉴&＃xff0c;不断改进&＃xff0c;比如 npm v7 会带来一流的 Monorepo 支持。历史总是螺旋式前进&＃xff0c;其间可能出现困局和曲折&＃xff0c;但是对前端从业人员来说&＃xff0c;时刻保持对工程化理念的学习&＃xff0c;抽丝剥茧、理清概念&＃xff0c;必能从中受益。

npm/Yarn 相关的话题不是一个独立的点&＃xff0c;它是成体系的一个面&＃xff0c;甚至可以算得上是一个完整的生态。这部分知识我们虽没有面面俱到&＃xff0c;但是聚焦在依赖管理、安装机制、CI 提效等话题上。更多 npm 的内容&＃xff0c;比如 npm scripts、公共库相关设计、npm 发包、npm 安全、package.json 等话题我会在后面章节中也会继续讲解&＃xff0c;希望你能坚持学习。

不管是本地开发环境还是 CI 环境&＃xff0c;不管是使用 npm 还是 Yarn&＃xff0c;都离不开构建工具。下一讲我会带你对比主流构建工具&＃xff0c;继续深入工程化和基建的深水区。我们下一讲再见。

精选评论

*仔&＃xff1a;

老师&＃xff0c;看了你的文章有一个问题想咨询一下&＃xff0c;项目仓库里面有 package-lock.json&＃xff1b;本地开发环境&＃xff08;node10&＃43;,npm6&＃43;&＃xff09;npm install 不会没有报错;但是在 Jenkins 打包环境&＃xff08;node8&＃43;,npm5&＃43;&＃xff09; npm install 偶尔会出现下面这种类型的错误; npm ERR! code EINTEGRITYnpm ERR! sha512-MKiLiV&＃43;I1AA596t9w1sQJ8jkiSr5&＃43;ZKi0WKrYGUn6d1Fx&＃43;Ij4tIj&＃43;m2WMQSGczs5jZVxV339chE8iwk6F64wjA&＃61;&＃61; integrity checksum failed when using sha512: wanted sha512-MKiLiV&＃43;I1AA596t9w1sQJ8jkiSr5&＃43;ZKi0WKrYGUn6d1Fx&＃43;Ij4tIj&＃43;m2WMQSGczs5jZVxV339chE8iwk6F64wjA&＃61;&＃61; but got sha512-WXI95kpJrxw4Nnx8vVI90PuUhrQjnNgghBl5tn54rUNKZYbxv&＃43;4ACxUzPVpJEtWxKmeDwnQrzjc0C2bYmRJVKg&＃61;&＃61;. (65117 bytes) npm ERR! A complete log of this run can be found in:npm ERR! /home/ubuntu/.npm/_logs/2017-11-29T05_33_52_182Z-debug.log想问一下老师&＃xff0c;这种情况一般从哪些方向思考&＃xff1a;1.网络不稳定导致下载的依赖不完整&＃xff1f;2.npm 版本不同导致&＃xff1f;3.本地开发是 window10&＃xff0c;打包服务器是 ubuntu&＃xff0c;系统不同 npm 根据 package-lock.json ji计算依赖包的 hash 不同导致&＃xff1f;

    讲师回复&＃xff1a;

    首先对齐一下 CI 机器上和本地的各环境版本&＃xff0c;包括 node npm 等

**茏&＃xff1a;

可以讲讲pnpm吗&＃xff0c;感觉挺好用的&＃xff0c;下载也比较可观&＃xff0c;但还是不太敢在项目开发中使用

    讲师回复&＃xff1a;

    pnpm 非常不错&＃xff0c;npm7 和 pnpm 其实是我认为设计上目前最好的了&＃xff0c;纯设计上。可以大胆在项目中尝试下。

**宇&＃xff1a;

如果我们开发的库依赖了一个精确版本号的模块&＃xff0c;那么提交 lockfiles 到仓库可能会造成同一个依赖不同版本都被下载的情况。如果作为库开发者&＃xff0c;真的有使用某个特定版本依赖的需要&＃xff0c;一个更好的方式是定义 peerDependencies。这样做的话如果遇到了不符合规则的 peerDenpendencies&＃xff0c;npm 也会正常安装使用&＃xff0c;那怎么确保版本号精确

    讲师回复&＃xff1a;

    会有 warning&＃xff0c;业务方处理

*滨&＃xff1a;

摘录&＃xff1a;历史总是螺旋式前进&＃xff0c;其间可能出现困局和曲折&＃xff0c;但是对前端从业人员来说&＃xff0c;时刻保持对工程化理念的学习&＃xff0c;抽丝剥茧、理清概念&＃xff0c;必能从中受益。赞

*鑫&＃xff1a;

怎么看待yarn v2的巨大变化&＃x1f600;

    讲师回复&＃xff1a;

    正向进化

**的小叶酱&＃xff1a;

现在项目里&＃xff0c;yarn和npm都在使用&＃xff0c;请问更推荐使用哪个呢

    讲师回复&＃xff1a;

    目前看区别不大&＃xff0c;我个人喜欢 yarn

L&＃xff1a;

bundledDependencies 的意义是什么&＃xff1f;如果只是需要这个依赖得话&＃xff0c;那为什么不直接使用 dependencies 呢&＃xff1f;

    讲师回复&＃xff1a;

    恰好这里有个人跟你疑问一样&＃xff1a;https://stackoverflow.com/questions/11207638/advantages-of-bundleddependencies-over-normal-dependencies-in-npm 简单来说 使用 bundledDependencies&＃xff0c;直接把我的依赖打包进来&＃xff0c;这是最安全的——不管 npm 机制怎么变&＃xff0c;我都是最安全的&＃xff0c;直接打包我的依赖

**3335&＃xff1a;

我们的CI/CD环境&＃xff0c;能缓存上次构建的node_modules目录。那如果换成npm ci 安装&＃xff0c;先删除 node_modules。会不会反而减慢了下载依赖的速度&＃xff1f;

    讲师回复&＃xff1a;

    是存在这种可能的&＃xff0c;一般缓存肯定会更快&＃xff0c;如果单纯从头安装的话&＃xff0c;CI 依赖确定的依赖树&＃xff0c;会有速度优势