网站开发设计怎么找客户,做vi设计的国外网站,美的集团网站建设,crm免费版本文需要读者懂一点点前端的构建知识#xff1a; 1. package.json文件的作用之一是管理外部依赖#xff1b;2. .npmrc是npm命令默认配置#xff0c;放在工程根目录。 Web前端构建一直都是一个不难#xff0c;但是非常烦人的问题#xff0c;在DevOps、CI/CD领域。 烦人的是… 本文需要读者懂一点点前端的构建知识 1. package.json文件的作用之一是管理外部依赖2. .npmrc是npm命令默认配置放在工程根目录。 Web前端构建一直都是一个不难但是非常烦人的问题在DevOps、CI/CD领域。 烦人的是偶尔发生这样的事情 1. 开发在本地构建通过但是流水构建失败。这时前端开发人员会经常报怨Pipeline不稳定2. 流水线构建通过但是在生产环境上启动不了或者出现运行错误3. 不使用Docker可以启动但是打包成Docker镜像后启动就失败。 这类问题不是今天解决了明天就不会发生。而是你根本不知道它什么时候又发生。 据我观察绝大多数时候都是依赖版本管理没有做好导致的。 Web前端的依赖版本管理包括以下几个维度 1. node的版本2. 外部依赖的版本 我们需要在开发环境构建环境运行环境保证它们的版本是一致的。这样在本地开发环境测试通过那么在其它环境就理论上也应该能通过。 接下来是具体的最佳实践。 保证Node版本一致 要保证Node版本一致就要保证所有的环境使用同一个版本的node。而且是要具体到某一个精确的版本如v20.11.1而不是20这样一个粗略版本。 以下是我们以v20.11.1为例。 设置开发环境 设置开发环境的node的版本需要在package.json中加入 {engines: {node: v20.11.1,npm: 10.2.4},
} 这时如果存在开发环境与配置的版本不匹配的情况执行npm install会出现以下警告但是命令还是会继续执行 npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package: gpt0.0.1,
npm WARN EBADENGINE required: { node: v20.10.1, npm: 10.2.4 },
npm WARN EBADENGINE current: { node: v20.11.1, npm: 10.2.4 }
npm WARN EBADENGINE } 希望强制要求版本一致就在根目录的.npmrc文件加入 engine-stricttrue 发生版本不一致的情况报错日志如下且命令会停止执行 npm ERR! code EBADENGINE
npm ERR! engine Unsupported engine
npm ERR! engine Not compatible with your version of node/npm: gpt0.0.1
npm ERR! notsup Not compatible with your version of node/npm: gpt0.0.1
npm ERR! notsup Required: {node:v20.10.1,npm:10.2.4}
npm ERR! notsup Actual: {npm:10.2.4,node:v16.0.1} 设置构建环境 我们以Github Actions为例。在设置node环境时应设置为 - name: Setup Nodeuses: actions/setup-nodev3with:node-version: 20.11.1 设置运行环境 运行环境分两种虚拟机环境、容器运行时。 在虚拟机环境下要避免apt install node-20尽量使用能指定精确node版本的方式安装NodeJS比如从官网上下载20.11.1的包安装。 容器运行时环境选择的镜像的Tag要与构建环境的版本完全一致而不是随便选一个20版本的。 保证外部依赖版本的一致 由于Node的依赖管理默认配置下非常的宽松默认情况下使用的就是自动升级策略。 当开发在本地执行: npm i babel/corenpm会在package.json文件中加入babel/core: ^7.11.6,。^代表将来再次执行npm i时npm有权自动升级它的小版本。 这一行为导致项目一开始构建是成功的但是过一段时间又构建失败的偶尔事件。 这种偶发性不仅给构建工程带来不必要的浪费还让软件变得不可靠。想想建设在沙子上的大厦会是怎样。 所以我们推崇以下管理方法。 限制依赖下载源 限制的方法是在.npmrc中加入配置 registryhttps://registry.npmjs.org 从源头就控制软件供应链的一致性。 默认使用准确版本 正如前文所述在执行 npm install package 安装依赖时默认情况下会在package.json文件中使用^符号来指定版本范围。不过我们可以通过添加 --save-exact 参数来避免这种情况即运行 npm install package --save-exact这样package.json文件中就不会出现^符号而是会锁定安装的精确版本号。 我们不可能让开发人员100%做到每次执行命令都加--save-exact参数。 所以我们需要更改npm默认的行为在.npmrc文件中增加配置 save-exacttrue 将package-lock.json加入到版本库中 package-lock.json文件是npm专门用于固定依赖版本的。如果你使用的是pnpm相对应的文件就是pnpm-lock.yaml。 node工程中除了使用package-lock.json锁定版本还可以使用npm-shrinkwrap.json。 它们具有相同格式都放在项目的根目录目的都是为了锁定依赖版本。区别是npm-shrinkwrap.json会被发布到制品库而package-lock.json不会。且引用它的package会忽略这个文件。 而且当同一个工程根目录下同时存在它们时package-lock.json会被忽略。 使用PNPM代替npm 这篇文章[1]对PNPMnpm和Yarn三个依赖管理工具进行对比读者自行判断选择相应的工具。但是可以确定的是不要使用cnpm。 不论使用哪种工具以上的实践都是类似的。 后记 作者作为一个Web前端的外行写下本文有不足的或者错误的还请补充和指正多谢。 引用链接 [1] 文章: https://hackernoon.com/choosing-the-right-package-manager-npm-yarn-or-pnpm 往期好文 在你的心目中优秀的DevOps工程师应该是什么样的谈 DevOps 平台落地前端项目构建又失败了谈DevOps平台落地前端构建怎么这么变态
