前言

来啦老铁！

在上前两篇文章：VSCode 插件开发（一）：Hello World
和 VSCode 插件开发（二）：插件开发实践 中，我们一起学习了 VSCode 插件项目是如何创建、VSCode 插件的基础知识，以及尝试开发了一个稍微复杂点的插件，而今天我们在之前文章的基础之上，学习如何打包插件与本地安装插件~

主要参考文献：

• VSCode 插件安装-扩展文档
• publishing-extension

学习路径

1. 安装打包工具；
2. 修改 README.md；
3. 静态文件与 node_modues 文件夹处理；
4. 打包插件；
5. 安装插件；
6. 重启 VSCode；
7. 使用插件；
8. 插件功能拓展；
9. 安装包共享；
10. 思考；

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. 思考；

解决自动编写自动化脚本的问题，实际上从源头侧出发效果会更好，即规范化文本用例，如用例的前置条件描述、前置信息描述、用例步骤等，则“用机器自动写自动化脚本”才能发挥更多作用，但这个存在很多困难，如：

1. 文本用例通常是人为编写的，要让所有人遵循一定的规则去写文本用例，这个本身就是比较困难的事情；
2. 这样的规则通常也是难以制定的，因为产品功能迭代比较快速，文本用例描述规则可能也经常会发生变化；
3. 当有较多的规则需要遵守时，插件需要做很多定制化的功能，有时新增规则或规则发生变化，则插件开发完成后，可能脚本都写完了或者反而效率更低；
4. 过往有些大神们还特意为写脚本创建平台，通过平台组装出用例，实践到最后发现维护这些规则本身就需要耗费非常多的精力，得不偿失~
5. ...

因此，我个人更倾向于根据团队、项目的实际情况，在一些底层范围上做这种插件功能以提升工作效率，这样的插件具有通用性，维护量非常小，“用机器半自动写自动化脚本” 也还是可以的~

后续我就可以在这个插件上多下一些功夫，多增加一些通用功能，如文本用例版本对比等功能，以期在编写自动化脚本的各个环节提升工作效率~

这只是我的初次尝试，很多功能还有待研究，后续继续加油~

能力有限，欢迎指正、互相交流，感谢~

如果本文对您有帮助，麻烦点赞、关注！

感谢~