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