当前位置: 首页 > news >正文

形容网站做的好东莞网站推广企业

形容网站做的好,东莞网站推广企业,贵阳网站建设1685,电商网站设计岗位主要是本文需要读者懂一点点前端的构建知识: 1. package.json文件的作用之一是管理外部依赖;2. .npmrc是npm命令默认配置,放在工程根目录。 Web前端构建一直都是一个不难,但是非常烦人的问题,在DevOps、CI/CD领域。 烦人的是…

b6fa871ef5244b51a187e242deeffebb.jpeg

本文需要读者懂一点点前端的构建知识:

  1. 1. package.json文件的作用之一是管理外部依赖;

  2. 2. .npmrc是npm命令默认配置,放在工程根目录。

Web前端构建一直都是一个不难,但是非常烦人的问题,在DevOps、CI/CD领域。

烦人的是偶尔发生这样的事情:

  1. 1. 开发在本地构建通过,但是流水构建失败。这时前端开发人员会经常报怨Pipeline不稳定;

  2. 2. 流水线构建通过,但是在生产环境上启动不了,或者出现运行错误;

  3. 3. 不使用Docker可以启动,但是打包成Docker镜像后启动就失败。

这类问题,不是今天解决了,明天就不会发生。而是你根本不知道它什么时候又发生。

据我观察,绝大多数时候都是依赖版本管理没有做好导致的。

Web前端的依赖版本管理包括以下几个维度:

  1. 1. node的版本

  2. 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: 'gpt@0.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-strict=true

发生版本不一致的情况,报错日志如下,且命令会停止执行:

npm ERR! code EBADENGINE
npm ERR! engine Unsupported engine
npm ERR! engine Not compatible with your version of node/npm: gpt@0.0.1
npm ERR! notsup Not compatible with your version of node/npm: gpt@0.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-node@v3with:node-version: '20.11.1'

设置运行环境

运行环境分两种:虚拟机环境、容器运行时。

在虚拟机环境下,要避免apt install node-20,尽量使用能指定精确node版本的方式安装NodeJS(比如从官网上下载20.11.1的包安装)。

容器运行时环境,选择的镜像的Tag要与构建环境的版本完全一致,而不是随便选一个20版本的。

保证外部依赖版本的一致

由于Node的依赖管理默认配置下非常的宽松,默认情况下使用的就是自动升级策略。

当开发在本地执行: npm i @babel/core,npm会在package.json文件中加入"@babel/core": "^7.11.6",^代表将来再次执行npm i时,npm有权自动升级它的小版本。

这一行为,导致项目一开始构建是成功的,但是过一段时间又构建失败的偶尔事件。

这种偶发性,不仅给构建工程带来不必要的浪费,还让软件变得不可靠。想想建设在沙子上的大厦会是怎样。

所以,我们推崇以下管理方法。

限制依赖下载源

限制的方法是在.npmrc中加入配置:

registry=https://registry.npmjs.org

从源头就控制软件供应链的一致性。

默认使用准确版本

正如前文所述,在执行 npm install <package> 安装依赖时,默认情况下会在package.json文件中使用^符号来指定版本范围。不过,我们可以通过添加 --save-exact 参数来避免这种情况,即运行 npm install <package> --save-exact,这样package.json文件中就不会出现^符号,而是会锁定安装的精确版本号。

我们不可能让开发人员100%做到每次执行命令都加--save-exact参数。

所以,我们需要更改npm默认的行为,在.npmrc文件中增加配置:

save-exact=true

将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]对PNPM,npm和Yarn三个依赖管理工具进行对比,读者自行判断选择相应的工具。但是,可以确定的是不要使用cnpm。

不论使用哪种工具,以上的实践都是类似的。

后记

作者作为一个Web前端的外行写下本文,有不足的或者错误的,还请补充和指正,多谢。

引用链接

[1] 文章: https://hackernoon.com/choosing-the-right-package-manager-npm-yarn-or-pnpm

往期好文:

  • 在你的心目中,优秀的DevOps工程师应该是什么样的?

  • 谈 DevOps 平台落地:前端项目构建又失败了

  • 谈DevOps平台落地:前端构建怎么这么变态

http://www.mnyf.cn/news/43499.html

相关文章:

  • pc做网站百度直接打开
  • 萍乡网站制作公司百度登录页
  • 网络系统脆弱性的不安全因素湖南seo优化
  • 广州营销网站建设公司广东互联网网络营销推广
  • 永久建站平台网站seo综合查询
  • 设计关于北京的网页企业怎么做好网站优化
  • flash手机网站制作发帖子最好的几个网站
  • wordpress本地怎么搬家山西seo排名厂家
  • 二手旧书网站开发设计报告友链
  • 做网站去哪里找模板新公司如何做推广
  • 网站建设前的前景百度网址提交入口
  • 做网站设计需要哪些知识设计外包网站
  • 武汉做网站的公司哪家好渠道推广策略
  • 南昌网站建设维护优化的含义是什么
  • wordpress 文章分享代码狼雨seo网站
  • 网站站内结构优化杭州10大软件开发公司
  • 做网站在厦门排前5名windows优化大师的功能
  • 哪个网站做课件能赚钱无锡seo网站管理
  • 怎么做直播网站刷弹幕北京网络营销推广公司
  • 勒流有做网站的吗网站推广平台有哪些
  • php响应式网站模板东莞网站制作十年乐云seo
  • 四平网站建设国外推广都是怎么推广
  • crm网站推荐百度指数怎么算
  • 网站导航栏设计代码朋友圈推广一天30元
  • 胶南网站建设公司外贸营销网站
  • 网上有做任务赚钱的网站有哪些重庆森林影评
  • 怎样提高网站首页权重网络营销方式方法
  • 成都建网站全球新冠疫情最新消息
  • 二级域名做网站好不好百度2022第三季度财报
  • 安岳网站建设网站百度推广