VSCode 插件开发（三）：插件打包与本地安装

lichengxin • • 杂文

前言

来啦老铁！

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

主要参考文献：

学习路径

  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 ./speed-up-scripting-1.0.0.vsix

code --install-extension 后面带的就是步骤 3 生成的安装包文件路径；

安装插件
  • 安装完成后，我们会在 ~/.vscode/extensions 目录下看到我们安装好的插件目录，如：
插件 - 1
注：文件夹名上有个 undefined， 这是因为我们没有配置发布者的名字，如何配置呢？

a. 在 package.json 中配置 "publisher" 项即可，如：

publisher

b. 效果如下：

publisher 效果 1
publisher 效果 2

  • 安装好的插件文件夹内的结构：

    插件 - 2

6. VSCode 中查看已安装的插件；；

  • 插件安装完成后，我们就能在 VSCode 内看到我们的插件了，入口如下：
查看已安装的插件

注意：如果是更新，则需要重启 VSCode 或卸载插件并重装拆件以使用最新版本的插件；

7. 使用插件；

  • 在 VSCode 内看到我们的插件后，我们就可以用我们的快捷键或快捷菜单来执行我们的插件了；

例如我做了个简易的生成自动化脚本模板的插件（生成的自动化脚本，部分信息需要调用 API 从用例管理平台上获取，然后组装到模板中去，进而生成我们的自动化用例的初始代码）；

  • 输入用例号；
启动插件
  • 自动调用 API 并组装自动化用例的初始代码；
自动生成自动化用例模板

8. 插件功能拓展；

  • 我还做了一个功能，那就是可以将配置文件清空的功能，以后如果有推广，方便适用于不同团队（当然，不同团队如果技术栈一样那就方便，如果技术栈或框架有差异，那么用例模板和插件逻辑是要重点维护的）；
清空配置文件
  • 接着我们再触发自动生成脚本时就会多出以下几个问询：
API Endpoint - 问询
API Key - 问询
Case 前缀 - 问询

9. 安装包共享；

我们可以将打包出来的安装包发给其他人，其他人使用插件安装命令即可安装我们的安装包，进而达到共享的效果，此处不再演示；

由于该插件与公司内部平台紧密关联，不适合发布到网络上，因此我们就暂时不学习发布了。

10. 思考；

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

  1. 文本用例通常是人为编写的，要让所有人遵循一定的规则去写文本用例，这个本身就是比较困难的事情；
  2. 这样的规则通常也是难以制定的，因为产品功能迭代比较快速，文本用例描述规则可能也经常会发生变化；
  3. 当有较多的规则需要遵守时，插件需要做很多定制化的功能，有时新增规则或规则发生变化，则插件开发完成后，可能脚本都写完了或者反而效率更低；
  4. 过往有些大神们还特意为写脚本创建平台，通过平台组装出用例，实践到最后发现维护这些规则本身就需要耗费非常多的精力，得不偿失~
  5. ...
因此，我个人更倾向于根据团队、项目的实际情况，在一些底层范围上做这种插件功能以提升工作效率，这样的插件具有通用性，维护量非常小，“用机器半自动写自动化脚本” 也还是可以的~

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

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

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

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

感谢~

版权声明：
作者：lichengxin
链接：https://www.techfm.club/p/48062.html
来源：TechFM
文章版权归作者所有，未经允许请勿转载。

THE END
分享
二维码
< <上一篇
下一篇>>