前端组件库一本地开发调试自动化流程

本文转载自链接 https://zhuanlan.zhihu.com/p/142554961

日常运行前端项目的时候整个npm run dev或者类似的命令即可,对于比较大的项目,想要把项目的一些UI或者计算逻辑这种通用逻辑单独抽成包。
通常的做法是发包到npm,在需要用到的时候安装,过程如下:
假设我们维护的主应用就叫 big-platform,其中有一些通用逻辑我们给抽象到了一个 Node package 里,暂且取名 @fudao/hello 并发布到 npm 上,等其他同学开发需要用到这个组件或者逻辑时,一条 npm install @fudao/hello --save 便能搞定
如果组件有BUG,就只能上报bug,等待作者更新,但是作者何时响应就不得而知了,而且麻烦的是上报必须要将现象描述清楚,很多时候还不如自己修改来的快。
修改时,调试复杂:写代码都好说,但如何调试往往难倒了很多同学。为了验证修改没有问题再发布,我们的验证过程成了这期间最耗时的任务。

现有开发调试方案

npm link 手动搬运

每当变更过library上的代码后,在其所在目录执行

npm run build // 执行构建
cd dist/hello // 进入构建后结果目录
npm link // 将library链接到全局

然后到项目所在目录重新绑定并重启服务

npm link @zujian/hello
npm run start // 对应到具体执行脚本

上述方式的缺点也很明显,就是每次依赖更新都需重新执行library,在项目中更新依赖

将具体包名替换为本地路径

  1. 复制构建后文件夹到项目 node_modules 目录
cp -r dist/hello / /project/node_modules/@zujian/hello
  1. 在项目中安装依赖时使用文件路径安装
{  
"name": "big-platform",  
"dependencies":{ "@fudao/hello":"file:../hello/dist/hello" }
}

但一定记着,上线之前你需要把这个依赖改回去,这还是不怎么方便啊。此外,这两种方式都需要你在 library 代码变更后先执行一次包的构建命令,毕竟,要先得到最近的构建包。

源码引用

如果是 React 或者 Vue 项目,将 library 声明为一个 ES Module 并列好入口文件,那么直接更改项目中 import 方式(从包名改为路径形式)或是直接拷贝未构建代码均可达到调试的效果。如果是 Angular 项目,你可以在 tsconfig.json 中指定 library 的路径映射(直接引入),但 Angular library 在项目中的使用,用源码引入和实际构建后引入这两种方式仍然存在一些差异,所以这么来看,也还是不太方便

本地 library 开发调试的自动化流程

文件监控开源库 nodemon

nodemon 是一个用来监视 Node.js 应用程序中文件更改并自动重启服务的开源库,仅用于开发环境(推荐)。
使用上不需要对项目代码做任何操作,命令也只是简单将 node 替换为 nodemon,你可以用如下命令安装它:

npm i -g nodemon

然后配置一下自定义参数,比如观察的文件类型(是只观察.ts文件还是HTML/CSS/TypeScript 的文件变更都需要被监控)、需要观察的文件路径、需要忽略的路径(比如node_modules)以及自定义命令等。

虽然 nodemon 被设计用来监控重启 Node 应用,但是也支持监控执行自定义命令,比如通过如下命令使用 nodemon 来监控代码变更:

nodemon    
--ignore dist/ # 忽略目录  
--ignore node_modules/ 
--watch projects # 观察目录    
-C # 只在变更后执行,首次启动不执行命令    
-e ts,html,less,scss # 监控指定后缀名的文件
--debug # 调试    
-x "npm run build && cd dist/hello && yalc push" # 自定义命令

你还可以通过 nodemon -h 了解更多

本地依赖管理开源库 yalc

yalc 是一个类似于本地化 npm 的解决方案,它在本地环境中创建了一个共享的 library 存储库,使得你在需要使用本地依赖时可以快速从这个存储库拉取资源进行消费。当在指定 library 中运行 yalc publish 时,它会将本来发布到 npm 上的相关文件存储在本地这个共享的全局存储中,而在项目中通过 yalc 添加依赖时, yalc add @zujian/hello 会从全局存储拉入信息到项目根目录的 .yalc 文件夹,并将一个文件 “file:.yalc/@zujian/hello” 注入 package.json。
yalc 比较诱人的一点在于他还有一个命令叫 yalc publish --push 或者简称 yalc push,他会将你的依赖发布到本地存储库(更新状态),并将所有更改传播到现有通过 yalc安装的依赖中,这个操作实际上进行了一次 update 操作
如此一来,你可以完全按照 npm install 从远程 registry 拉取依赖的方式安装和消费一个本地依赖,Cool。

自动化方案

在这里插入图片描述
图中绿色部分皆为可自动化执行的流程,即我们只需要关注两个框内的代码更改,黄框对应 library 代码,蓝框对应项目代码,其他流程均在代码变更时自动触发并最终将变更产物刷新到浏览器中。
总结一下,我们的定义了一些 Make 脚本和 npm 脚本用于执行具体构建、推送和调试命令,我们用 nodemon 对 library 侧文件变更进行监控,并用 yalc 作为本地发布和推送更新的工具,最后 webpack 是本地调试热更新服务器的实现基础。
假设你采用yalc + nodemon 方案,那么在 library 项目中,你可以通过如下 Makefile 指定几个命令:

init: # 初始化环境
    npm install
    npm install -g yalc nodemon

push: # 手动构建与 push
    npm run build
    cd dist/hello && yalc push

watch: # 自动监听文件变化并执行构建与 push 任务
    nodemon --ignore dist/ --ignore node_modules/ --watch projects -C -e ts,html,less,scss --debug -x 
"npm run build && cd dist/hello && yalc push"

而在业务项目中,若是你不喜欢 Makefile,可以直接在 package.json 中指定几个 commands,这样你就可以直接 npm run * 一把梭了:

{
    
"name":"big-platform",  
"version": "0.0.1",    
"scripts": {        
	"ng": "ng",        
	"start": "ng serve",        
	"build": "ng build --base-href /big-platform/",       
	"test": "ng test",        
	"lint": "ng lint",        
	"e2e": "ng e2e",        
	"init": "npm install && npm install -g yalc",        
	"link-hello": "yalc add @fudao/hello",        
	"remove-hello":"yalc remove --all",        
	...   
	},
...
}

总结

抛去具体实现方案,总结来看,我们的自动化开发调试流程也可以抽象为两个通用部分:

本地开发调试阶段

在 library 侧,进入 library 所在目录启动监听器(nodemon),并附上 watch 变化后重新构建和推送新包的脚本命令(Makefile);

在项目侧,注册对本地 library 的依赖并安装(yalc add @package),并启动本地开发服务(webpack-dev-server),负责调试服务和热更新等内容;

在发布流程前

在 library 侧,关闭监听器并编译打包(npm run build),发布新版本至 npm;
在项目侧,移除对本地 library 依赖的声明(yalc remove --all),并构建打包、上线。实际干活时,一条命令自动化整个本地开发调试过程。改造下来,开发流程顺畅了不少,感觉还不错。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章