前言
来啦老铁!
在上前两篇文章:VSCode 插件开发(一):Hello World
和 VSCode 插件开发(二):插件开发实践 中,我们一起学习了 VSCode 插件项目是如何创建、VSCode 插件的基础知识,以及尝试开发了一个稍微复杂点的插件,而今天我们在之前文章的基础之上,学习如何打包插件与本地安装插件~
主要参考文献:
学习路径
- 安装打包工具;
- 修改 README.md;
- 静态文件与 node_modues 文件夹处理;
- 打包插件;
- 安装插件;
- VSCode 中查看已安装的插件;
- 使用插件;
- 插件功能拓展;
- 安装包共享;
- 思考;
1. 安装打包工具;
- 使用以下命令安装 VSCode 插件的专用安装工具:
npm install -g vsce
2. 修改 README.md;
- 需要修改项目根目录下的 README.md 文件内容,删除 “This is the README for your extension” 这句话,如:
- 然后才能正常打包,否者会出现以下错误:
(我们暂且先不修改 README.md 文件的其他内容)。
3. 静态文件与 node_modues 文件夹处理;
- 一些如 .txt、.json 文件等的静态文件可以在开发的时候放在根目录,如:
放在根目录,这样我们就不用额外去复制这些静态文件了,vsce package 命令会帮我们完成;
- node_modues 文件夹在运行插件时有时候是必须的,特别是当有外部依赖的时候,则此时需要修改 package.json 文件内的内容,将 devDependencies 字眼改为 dependencies 即可,这一点非常重要,如:
4. 打包插件;
- 接下来我们开始打包我们的插件,使用命令:
vsce package
-
看到 Done 字眼即可:
我们能看到插件安装包路径为:/Users/dylan.z.zhang/Desktop/case2script/case2script-0.0.1.vsix
-
也能在项目根目录下看到该安装包:
5. 安装插件;
- 使用如下命令安装我们打包好的插件,如:
code --install-extension /Users/dylan.z.zhang/Desktop/case2script/case2script-0.0.1.vsix
- 或者类似:
code --install-extension ./speed-up-scripting-1.0.0.vsix
code --install-extension 后面带的就是步骤 3 生成的安装包文件路径;
- 安装完成后,我们会在 ~/.vscode/extensions 目录下看到我们安装好的插件目录,如:
注:文件夹名上有个 undefined, 这是因为我们没有配置发布者的名字,如何配置呢?
a. 在 package.json 中配置 "publisher" 项即可,如:
b. 效果如下:
-
安装好的插件文件夹内的结构:
6. VSCode 中查看已安装的插件;;
- 插件安装完成后,我们就能在 VSCode 内看到我们的插件了,入口如下:
注意:如果是更新,则需要重启 VSCode 或卸载插件并重装拆件以使用最新版本的插件;
7. 使用插件;
- 在 VSCode 内看到我们的插件后,我们就可以用我们的快捷键或快捷菜单来执行我们的插件了;
例如我做了个简易的生成自动化脚本模板的插件(生成的自动化脚本,部分信息需要调用 API 从用例管理平台上获取,然后组装到模板中去,进而生成我们的自动化用例的初始代码);
- 输入用例号;
- 自动调用 API 并组装自动化用例的初始代码;
8. 插件功能拓展;
- 我还做了一个功能,那就是可以将配置文件清空的功能,以后如果有推广,方便适用于不同团队(当然,不同团队如果技术栈一样那就方便,如果技术栈或框架有差异,那么用例模板和插件逻辑是要重点维护的);
- 接着我们再触发自动生成脚本时就会多出以下几个问询:
9. 安装包共享;
我们可以将打包出来的安装包发给其他人,其他人使用插件安装命令即可安装我们的安装包,进而达到共享的效果,此处不再演示;
由于该插件与公司内部平台紧密关联,不适合发布到网络上,因此我们就暂时不学习发布了。
- 发布可参考文献:publishing-extensions
10. 思考;
解决自动编写自动化脚本的问题,实际上从源头侧出发效果会更好,即规范化文本用例,如用例的前置条件描述、前置信息描述、用例步骤等,则“用机器自动写自动化脚本”才能发挥更多作用,但这个存在很多困难,如:
- 文本用例通常是人为编写的,要让所有人遵循一定的规则去写文本用例,这个本身就是比较困难的事情;
- 这样的规则通常也是难以制定的,因为产品功能迭代比较快速,文本用例描述规则可能也经常会发生变化;
- 当有较多的规则需要遵守时,插件需要做很多定制化的功能,有时新增规则或规则发生变化,则插件开发完成后,可能脚本都写完了或者反而效率更低;
- 过往有些大神们还特意为写脚本创建平台,通过平台组装出用例,实践到最后发现维护这些规则本身就需要耗费非常多的精力,得不偿失~
- ...
因此,我个人更倾向于根据团队、项目的实际情况,在一些底层范围上做这种插件功能以提升工作效率,这样的插件具有通用性,维护量非常小,“用机器半自动写自动化脚本” 也还是可以的~
后续我就可以在这个插件上多下一些功夫,多增加一些通用功能,如文本用例版本对比等功能,以期在编写自动化脚本的各个环节提升工作效率~
这只是我的初次尝试,很多功能还有待研究,后续继续加油~
能力有限,欢迎指正、互相交流,感谢~
如果本文对您有帮助,麻烦点赞、关注!
感谢~