我编写 33 个 VSCode 扩展的缘由以及管理扩展的经验

简评：使用工具的同时本身创造一些工具或扩展，是一件很棒的事情。

如下“我”指原做者 Fabio

你们好，我叫 Fabio，是一位自学成才的开发人员，热衷于开源和受权。我也喜欢本身制做工具，天然而然地。我为经常使用的 VSCode 程序编写了不少扩展。

在开发和管理 VSCode 扩展以及谈论我创造的全部扩展的同时，我想与你们再分享一些个人工做流程。

在这里我将介绍我创造的许多工具和扩展，所以不管你是要开始开发扩展，仍是想要找到很酷的新扩展，或者只是须要管理不少存储库，本文保证会有你感兴趣的内容。

编写一个扩展

我喜欢生产力和自动化，因此我开始新项目的方式很是精简。

工具

我编写了一个名为 template 的开源项目，它能够基于模板快速建立新项目，很是简单：

1. 它须要一个文件夹做为输入（“模板”）。
2. 它用 handlebars 处理全部文件，要求你为模板中找到的占位符提供值（即{{name}}）。
3. 它输出一个替换了全部占位符的新文件夹。

我了解过 yeoman，但它对于个人使用状况来讲彷佛太复杂了。我用过 khaos，可是它再也不维护，而且它不会自动更新模板，总不能在每次我想用的时候都手动更新，因此我没有使用它。

模板

接下来我使用个人 template-vscode-extension 模板启动一个新的 VSCode 扩展。

如今我有一个工做的 Hello-World-ish 扩展。该模板包含许多我常用的辅助函数：它支持从.vscode文件夹加载自定义配置文件 ，能够自动注册命令，还能够根据活动文件推断当前根等。

若是我能回到过去，可能会把全部这些辅助函数放到一个独立的vscode-utils包中，而不是在全部扩展中复制它们，不幸的是一开始我不知道将进行 10 次扩展，如今去更新它们将须要至关多的时间。

若是你在考虑编写 VSCode 扩展，或许会想以个人扩展为基础，我建议你制做本身的模板。

文档

我在开发扩展时老是打开 VSCode 的文档。虽然文档很长，要找到你须要的 API 并非那么简单明了，可是只要快速阅读一下很快你就会熟悉起来。总的来讲，我对能找到的 API 至关满意。

扩展

无论你信不信，我所作的一些扩展实际上对我开发其余扩展有必定帮助，稍后会对此进行进一步的讨论。

个人扩展

正如我所说的，我喜欢生产力，因此个人大部分扩展都与生产力相关的。我尽可能不要过多地重复发明轮子，确保功能在扩展之间良好分离，彼此之间良好配合。

不管好坏，我发现扩展颇有趣，而且不乏能够自动化的东西，这就是为何在第 1 个扩展以后我又作了第 2 个，第 3 个......和第 33 个！

点击如下每一个扩展程序的超链能够进入原页面，获取到更多详细信息和屏幕截图。

用来编写扩展程序的扩展

二、Debug Launcher：无需定义任何任务或启动配置便可从终端开始调试。我不想用重复的启动配置和任务来混乱个人存储库。VSCode 真的应该直接支持从终端启动调试器，对此我提了一个 issue。

从终端启动调试器

二、StatusBar Debugger：将调试器添加到状态栏，比默认浮动调试器干扰更少。默认工具栏的使用体验很糟糕（相关 issue），若是 VSCode 能公开调试状态，那这个扩展可能会好得多。

三、Install .VSIX：直接从资源管理器安装扩展，右键单击便可。由于如今安装 .vsix 的体验也很糟糕（相关 issue）。

四、Bump：压缩项目的版本并更新更改日志。有意见但可配置。每一个可敬的扩展都须要一个更新日志，但这并不意味着你必须手动编写一个。这个扩展是个人最爱之一，我可能会制做一个CLI版本，但愿未来它也能够为我制做 GitHub 版本。

五、Optimize Images：使用你最喜欢的应用程序优化项目中的一个或全部图像。只需一个命令便可完成。

管理项目

六、Projects+：管理项目的扩展。功能丰富，可自定义，自动查找你的项目。Project Manager 是这种类型中最经常使用的扩展，但我有 100 多个存储库，包括一个无限可嵌套的组，我须要正确的工具来管理它们。

Projects+ 可定制的快速选择

Projects+ 可定制的快速选择

管理待办事项

七、Todo +：轻松管理待办事项列表。功能强大，易于使用和可定制。若是你不须要对TODO文件进行语法高亮，可能只想要内置的基本高亮显示，那么能够查看 Todo Tree。

Todo + 语法高亮和项目级统计

八、Highlight：基于正则表达式的高级文本高亮显示。适用于待机，注释等。大多数人只是使用 TODO Highlight，但个人方式更通用，更强大，也可能更快。

九、Markdown Todo：轻松管理 markdown 文件中的待办事项列表。没什么特别的，可是它可让一些 Todo + 的快捷方式基本上能够在 Markdown 文件中使用。

十、Projects + Todo +：鸟瞰你的项目，将全部的 ToDo 文件聚合为一个。若是你使用 Projects + 来管理项目，且使用 Todo + 来管理待办事项，那么如今能够将全部（或部分）项目中的全部待办事项汇总到一个文件中。

在...中打开...

在不一样的应用程序/网站之间快速切换对我来讲很重要，这就是我作了不少Open in...扩展的缘由。

十一、Open in Application：在默认的应用程序或你想要的应用程序中打开任意文件。广义Open in...扩展。

十二、Open in Browsers：添加一些命令，用于在任何你喜欢的浏览器中打开当前文件或项目，甚至能够同时在全部浏览器中打开。

1三、Open in Code：轻松地在代码和代码内部之间切换。

1四、Open in Finder：添加一些命令用以在 Finder 中打开当前文件或项目。

1五、Open in GitHub：在 github.com 中打开当前项目或文件。还有不少其余的扩展能够实现这个功能，可是当我试用时，发现它们很是臃肿，有不少我不须要或不起做用的东西。

1六、Open in GitTower：添加一个在 GitTower 中打开当前项目的命令。

1七、 Open in Marketplace：添加用于在 Marketplace 中打开当前项目的命令。

1八、Open in node_modules：在 node_modules 中打开当前选择或任意字符串。当你想深刻了解你正在使用的模块时颇有用。

1九、Open in NPM：在 npmjs.com 中打开当前选择、项目或任意字符串。有助于快速查看自述文件。

20、Open in Ship：添加用于在 Ship 中打开当前项目的命令。不幸的是，Ship 已被弃用，它再也不起做用了。我如今在 Noty 中有一个专门的标签来管理即将发生的问题。

2一、Open in Terminal：添加一些命令以在终端中打开当前项目。

2二、Open in Transmit：添加一些命令用以在 transmit 中打开当前文件或项目。

其余

2三、Browser Refresh：从代码中使用 ⌘R 刷新浏览器。无需将焦点切换到它。当你没法使用热重载，而且不但愿浏览器在不须要时同步刷新页面，它会很是有用。

2四、Commands：从状态栏触发任意命令。支持传递参数！

经过命令定义的自定义命令

2五、Diff：Diff 2 能够轻松打开文件。由于运行code — diff path1 path2太慢了。

2六、Git File History:：查看或区分当前文件的历史版本。其余相似的扩展很差用。

2七、GitHub Notifications：一个安全，可自定义的状态栏图标，提醒你有关 GitHub 上的通知。

2八、Monokai Night Theme：完整，黑暗和简约的 Monokai 风格主题。我试用过的主题没有一个好用，因此我不得不作出本身的主题。

Monokai Night Theme

2九、No [Unsupported]：从标题栏中删除 “[Unsupported]” 的扩展名。如今不推荐使用，我建议使用 Fix VSCode Checksums。相关讨论见 issue 1 和issue 2。

30、Open Multiple Files：同时打开文件夹中的全部文件，可选择用 glob 过滤。

3一、Search — Open All Results：用一个命令同时打开全部搜索结果。

3二、Terminals Manager：一次性设置多个终端或仅运行某些命令的扩展。这其实是我作的第一个扩展。

3三、Transmit：添加一些命令用以与 Transmit 进行交互。

介绍这些花了很多时间，讲一个有趣的小事：我想个人帐户上发布的扩展最多，紧随微软以后，至少我尚未发现有人发布了比我更多的扩展（写完本文后发现 Greg 比我多作了 2 次扩展，我得加油了）

管理扩展

管理多个存储库多是一个挑战，如下是个人工做方式。

重复提交

早晚你会想要更改全部存储库中的某些内容，这意味着须要在多个存储库中进行基本相同的提交，无聊而浪费时间。

为了实现这类任务的自动化，我制做了 autogit，它是一个跨多个存储库执行命令的工具。

经过 autogit 执行 shell 命令的示例

我一直在寻找它的用途，最近我用它对我全部扩展的存储库进行了如下更改：

• 捆绑webpack：我发现启动时间提升了约 80％。
• 忽略package-lock.json：这只是我提交历史中的垃圾信息，阅读本 issue参考 Sindre Sorhus 关于忽略 package-lock.json 的看法。
• 更新tsconfig.json以输出最新的代码：我使用了至关多的异步函数，但当目标版本为<=es5时，异步函数被转换为慢速代码，而且因为 VSCode 与 Node.js 的现代版本一块儿发布，因此不须要这样作。
• 删除了 TSLint：我关注到我基本上忽略了它的输出，因此我删除了对 linting 的支持。
• 在 readme 中使用高分辨率 logo：在 readme 中使用高分辨率 logo 而不是以前使用的128x128 的 logo，遗憾的是我没有特别好的 logo，这是另外一个故事了 :）

能够看到 autogit 如何在 33 个存储库中快速地执行这 5 项更改。

使用 GitHub 同步描述和关键字

这是一个没必要作的事情，可是若是有一个工具能为你作这件事，那就太好了。幸运的是，autogit 和 autogit-command-github-sync 命令也能作到这一点：

经过 autogit 同步

我还制做了autogit-command-github-publish，用于自动建立 GitHub 存储库。

报告

在作了最初几回扩展后不久，我开始对了解他们得到了多少新下载感兴趣。你能够在一个页面中查看全部扩展程序，例如，您能够在此处找到个人扩展程序，但若是你不记得上次检查时扩展程序的下载次数，则没法知道新增了多少。这是我制做 rssa 的缘由，这个工具能够告诉你何时会发生变化。你能够用它来监控几乎全部可用 URL 访问的内容。

自定义 rssa 输出

若是有图表那就更棒了，虽然我尚未发布这个工具，可是利用 rssa 的历史咱们能够生成图表，下面是 Todo+ 的下载次数的图表：

Todo +下载

须要注意的是，有时候下载量会急剧增长，当发布新的更新时，就会出现这种状况，由于更新被视为下载😅，任何人均可以经过推送许屡次更新来拥有具备一百万次下载的扩展，这是应用市场的一个问题。

谢谢

很开心你看到了最后！谢谢你的阅读，但愿你在这里找到了有用的内容。

在评论聊一聊你是如何开发 VSCode 扩展的，以及你使用了什么扩展吧！