Visual Studio Code

2021年4月（版本1.56）

更新 1.56.1: 此次更新解决了这些安全问题。

更新 1.56.2: 本次更新解决了这些问题。

下载：Windows: x64 Arm64 | Mac: Universal Intel silicon | Linux: deb rpm tarball Arm snap

欢迎来到2021年4月发布的Visual Studio Code。VS Code团队这个月一直在忙于几个较长时间更新的工作，所以请查看预览功能部分，了解即将推出的内容。以下是此版本中包含的一些亮点：

如果您想在线阅读这些发布说明，请访问更新在code.visualstudio.com上。

加入我们的直播，在VS Code团队的直播中，于5月11日星期二太平洋时间上午8点（伦敦时间下午4点）观看本次发布的新功能演示，并实时向我们提问。

内部人员：想要尽快尝试新功能吗？您可以下载每晚的内部人员版本，并在更新可用时立即尝试最新更新。

工作台

改进的操作悬停反馈

我们已经更改了工作台中所有操作的鼠标悬停反馈，以提供更好的可点击操作的用户体验。

操作悬停反馈通过背景颜色得到改进。

未命名编辑器提示

我们注意到许多新用户不知道必须设置语言才能获得完整的VS Code语言支持。为了解决这个问题，我们为未命名的编辑器引入了一个提示，以帮助用户设置正确的语言模式。这个未命名的提示可能对高级用户没有帮助，因此一旦您开始输入，它就会立即消失，或者您可以选择不再显示以永远不再显示该提示。

未命名的编辑器显示一个未命名的提示

默认自定义编辑器和笔记本解析

如果您有两个编辑器都声明它们应该是某个资源的默认编辑器（例如，一个图像查看器和一个图像编辑器），您将收到一个提示来解决冲突。

在下面的短视频中，用户打开了一个PNG文件，该文件与两个编辑器相关联。通知让用户继续使用Luna Paint图像编辑器或配置一个新的默认编辑器，用户选择了后者并开始使用二进制Hex编辑器。

一个图像编辑器被打开，用户收到一个通知，提示他们配置默认编辑器或保持当前编辑器

更新的自定义对话框

我们已经更新了自定义对话框样式，您可以通过"window.dialogStyle": "custom"启用。VS Code现在会调暗背景，以便更好地聚焦于对话框，并且在有多个操作时使用次要按钮样式。

一个带有暗淡背景和次要按钮的自定义对话框示例

产品图标主题：Fluent Icons

您可以使用以下颜色标记来主题化次要按钮样式：

  • button.secondaryBackground
  • button.secondaryForeground
  • button.secondaryHoverBackground

仅自动更新已启用的扩展

您现在可以配置VS Code仅自动更新当前启用的扩展。

仅启用自动更新的扩展

主题: GitHub Light Theme

终端

个人资料改进

上次迭代中，我们介绍了终端配置文件。现在终端支持通过terminal.integrated.defaultProfile.设置来配置默认配置文件。

环境和图标支持也被添加到了配置文件中：

"terminal.integrated.profiles.windows": {
  "PowerShell": {
    "source": "PowerShell",
    "overrideName": true,
    "icon": "terminal-powershell",
    "env": {
      "TEST_VAR": "value"
    }
  }
},
"terminal.integrated.defaultProfile.windows": "PowerShell",

未来，这些设置是替换默认终端配置的推荐方式，而terminal.integrated.shell和terminal.integrated.shellArgs设置已被弃用。

新终端选择器

配置文件和设置快捷方式已从下拉菜单中移出，并移入一个新的+按钮，该按钮带有下拉菜单。

当选择时，下拉按钮显示一个菜单

这也支持基于非默认配置文件创建新的拆分终端。

新快捷键

终端在这个版本中有几个新的默认键绑定：

  • 移动到上一个终端 - Ctrl+PageUp (macOS Cmd+Shift+])
  • 移动到下一个终端 - Ctrl+PageDown (macOS Cmd+shift+[)
  • 聚焦终端标签视图 - Ctrl+Shift+\ (macOS Cmd+Shift+\) - 终端标签预览

一如既往，这些默认的键绑定可以通过键绑定系统移除或添加自定义键绑定。

Linux 选择粘贴命令

新命令 workbench.action.terminal.pasteSelection 在 Linux 上可用，用于从选择剪贴板粘贴到终端。

终端工作区 shell 权限已更改

为了支持与配置文件相关的即将到来的更改，如果终端设置存在于.vscode/settings.json中，将显示的提示已被移除，转而支持选择使用工作区设置的选项。请注意，这在不受信任的工作区中可能是危险的。

"terminal.integrated.allowWorkspaceConfiguration": true

当默认启用工作区信任时，我们将删除此内容并使用该系统。

任务

升级时移除任务 0.1.0

Tasks 2.0.0 已经可用并且运行良好超过三年，而 tasks 0.1.0 在这段时间内已被弃用。鉴于我们的 无 Node.js 渲染器 目标，tasks 0.1.0 已被删除，而不是被带入无 Node.js 的世界。当你打开包含 0.1.0 任务的文件夹时，它们将自动为你升级到 2.0.0 版本。

任务升级通知

终端标签中没有“任务”前缀

使用新的终端标签功能时，"任务"前缀将不再添加到终端名称中。相反，任务通过"工具"图标来指示，以更好地利用可用空间。

任务作为终端标签

与eslint-stylish更好的匹配

$eslint-stylish 问题匹配器更准确地匹配多行问题。

调试

断点视图改进

数据断点的访问类型已显示

对于数据断点，VS Code 现在在断点视图中显示访问类型（“读取”、“写入”或“访问”）在其名称旁边。

断点视图显示了在断点名称旁边呈现的访问类型“读取”、“写入”和“访问”

异常断点的更好状态/错误报告

对于异常断点，VS Code 现在在断点视图中显示它们的单独验证状态和详细原因。如果无法验证异常断点（例如因为其条件包含语法错误），它将被灰显，并且在悬停时显示相应的错误消息。

断点视图显示了禁用的异常断点，悬停时显示错误信息

其他用户界面改进

停止和断开命令的替代行为

调试会话通常通过调试：停止和调试：断开连接命令来停止。如果调试会话的类型是launch，停止命令不仅会停止会话，还会终止被调试程序。对于attach类型的调试会话，有一个断开连接命令，它会停止调试并恢复被调试程序的执行。

通过此版本，现在可以通过在从调试工具栏触发命令时按下Alt修饰键来翻转此行为。改变行为使得可以在launch类型的调试会话中保持调试对象运行，并在attach类型的调试会话中终止调试对象。除了使用Alt与默认命令外，还可以从命令面板访问调试：停止和调试：断开连接命令，适用于launch和attach调试会话。

替代行为仅适用于已选择加入此功能的调试扩展。

改进了安装缺失调试扩展的流程

我们改进了流程，如果用户想要开始调试但尚未安装提供调试支持的必要语言扩展（如Python或Java）。当这种情况发生时，VS Code现在会提示用户安装适当的扩展。

如果缺少Python扩展，VS Code会提示安装

调用堆栈列停止指示器

VS Code 现在每次调试程序在某一行停止时都会渲染调用堆栈列指示器。这应该有助于识别程序当前停止在行的哪个位置。

代码执行停止并在行中间显示列指示器

某些语言的默认内联值

VS Code 的调试器界面支持内联值，在逐步执行源代码时，可以在编辑器中内联显示变量值。此功能基于 VS Code 核心中的通用实现，因此可能并不完全适合所有语言，有时甚至会显示不正确的值，因为通用方法无法理解底层源代码语言。出于这些原因，该功能默认未启用。

通过新的调试器扩展API，语言扩展现在可以提供正确的内联值支持，我们默认启用了改进的内联值功能。

要启用此功能，debug.inlineValues 设置有一个新的（默认）值 auto。当设置为 auto 时，内联值会自动为那些支持“改进的内联值”的语言启用。

Debugger for Java 扩展是最早采用该API的调试器扩展之一。在下面的截图中，Java变量的准确值显示在其使用位置的旁边。

调试时在编辑器中显示内联值的Java扩展

您可以在调试PowerShell脚本时使用PowerShell的内联值支持扩展来获取内联值。

断点时显示的调试视图

debug.openDebug 设置的默认值现在是 openOnDebugBreak，这样每次命中断点时，VS Code 都会打开调试视图。调试视图也会在第一次会话启动时显示。

JavaScript 调试

像往常一样，完整的更改列表可以在vscode-js-debug changelog中找到。

改进的断点诊断工具可发现性

基于启发式方法，如果VS Code检测到用户可能在绑定断点时遇到问题，它将显示一个通知，建议打开断点诊断工具。

通知内容为“看起来您可能在断点方面遇到问题，您想打开我们的诊断工具吗？”

此提示最初将仅对一部分用户可见，因为我们正在测试其有效性和自信度。

私有类字段支持

Private class fields 现在可见并且可以在调试器中检查。

笔记本

切换行号

您现在可以从单元格工具栏中临时切换当前会话中单元格的行号，或通过notebook.lineNumbers设置更改所有笔记本的行号可见性。

切换单元格的行号

每种文件类型的单元格工具栏位置

现在可以通过notebook.cellToolbarLocation设置根据文件类型自定义单元格工具栏的位置。例如，您可以将GitHub Issue笔记本的单元格工具栏放在右侧，而将Jupyter笔记本的单元格工具栏放在左侧。

Markdown 单元格中的数学支持

您现在可以在笔记本的Markdown单元格中使用数学公式：

在Jupyter笔记本中渲染的数学公式

VS Code 使用 KaTeX 来渲染公式。有两种方法可以将数学公式嵌入到 Markdown 单元格中：

  • 使用单美元符号：$...$。这将创建一个内联数学公式。
  • 使用双美元符号：$$...$$。这将创建一个居中的块级数学公式。

我们使用了一个实验性的笔记本标记渲染API来实现数学支持，该API仍在开发中。我们最终的目标是通过这个API也允许扩展来扩展笔记本中Markdown的渲染。

语言

Markdown 预览排版支持

新的markdown.preview.typographer设置允许你在内置的Markdown预览中启用智能引号和简单的排版替换。

在下面的示例中，Markdown 文本如 (c) 会在预览中自动替换为版权符号 ©：

Markdown预览中的智能引号和文本替换

markdown.preview.typographer 设置默认是禁用的。

更多文件被识别为shell脚本

带有.xsession和.xprofile文件扩展名的文件将被自动识别为shell脚本。

预览功能

终端标签

终端中的标签页作为预览功能可用，并可以通过以下设置启用：

"terminal.integrated.tabs.enabled": true

标签视图是位于两个分割终端右侧的分割窗格。它包含每个终端实例的图标和标签。

启用后，新标签页视图默认仅在至少有两个终端时显示。对于单个终端，标签会“内联”到面板标题中，如下所示：

终端标签内嵌到单个终端的面板标题中

每个选项卡都支持通过上下文菜单执行多个操作。

右键点击标签显示菜单

悬停时可使用拆分和终止终端。

悬停标签项显示内联操作图标

我们尝试将新标签页的行为与资源管理器的工作方式对齐。以下是一些其他行为：

  • 双击空白处将创建一个新的终端。
  • 双击窗格将在显示所有标题而不截断的“理想”大小和仅显示图标的窄视图之间切换选项卡视图宽度。
  • 可以使用terminal.integrated.tabs.location设置将选项卡移动到左侧。
  • 在terminal.integrated.tabs下还有其他各种配置设置可用。

终端状态

除了标签页，我们还为终端引入了状态的概念。一个终端可以有许多状态，每个状态代表终端可以暂时处于的一种状态，其中最高严重性的状态会显示在标签页旁边。状态图标会出现在标签页视图中终端标题的右侧。当鼠标悬停时，会显示状态的详细信息以及任何相关的操作。

在与需要重新启动的终端相关联的标签上，终端标题右侧有一个带有感叹号的黄色三角形

目前，支持以下状态：

  • 需要重新启动：如果扩展想要更改终端的环境，则使用警告图标状态。
  • 断开连接：当终端与其进程失去连接时，使用插头图标状态。
  • Bell: 当通过terminal.integrated.enableBell设置启用铃声并且终端铃声触发时，会出现一个铃铛图标。

我们计划很快支持任务状态，这样即使不激活标签页，也能一目了然地查看任务运行状态。

欢迎页面演练

我们已经扩展了walkthroughs贡献，以便在入门页面上放置内容，允许在步骤描述和步骤主要内容中使用Markdown。对入门页面的扩展贡献是一个实验性功能，可以通过"workbench.welcomePage.experimental.extensionContributions": true,启用。

下面的短视频展示了一个示例教程，教用户了解Luna Paint扩展。

逐步了解Luna Paint扩展的入门贡献

活动栏和面板中的自定义悬停支持

在这个里程碑中，我们为活动栏和面板中的自定义悬停添加了实验性支持。您可以使用设置 workbench.experimental.useCustomHover 来启用自定义悬停。

活动栏和面板中的自定义悬停

主题: GitHub Light Theme 产品图标主题: Fluent Icons

远程仓库 (RemoteHub)

作为本次发布的一部分，我们正在预览一个新的内置扩展，远程仓库（RemoteHub），它允许您直接从VS Code内即时浏览、搜索、编辑和提交到任何GitHub仓库，而无需克隆或在本地拥有该仓库。目前它仅在VS Code的Insiders版本中可用。

入门指南

要开始使用，请从命令面板运行Open Remote Repository...命令。然后，您可以粘贴任何GitHub URL，或选择搜索特定的仓库或拉取请求。

打开远程仓库选择器

主题: Amethyst Dark Theme

一旦您输入URL或选择一个仓库或拉取请求，VS Code将为该仓库打开一个新的工作区。状态栏左侧的远程状态指示器显示连接的远程提供者名称，例如GitHub，用于远程仓库。

远程仓库演示展示各种源代码控制操作

主题: Amethyst Dark Theme

功能

  • 无需克隆或本地拥有仓库，即可立即打开任何GitHub仓库。
  • 轻松编辑并贡献到任何GitHub仓库 - 直接提交您的更改到GitHub，或打开一个拉取请求。
  • 在另一个环境中继续 - 通过继续在...命令（可从命令面板或远程指示器快速选择菜单访问）。
    • 在本地克隆仓库
    • 将仓库克隆到容器中 - 需要Dev Containers扩展
  • 提供了一个类似于在本地仓库工作的熟悉用户界面（*请参阅下面的“限制”）。
    • 资源管理器 - 打开、复制、移动、重命名和删除文件和文件夹
    • 搜索 - 快速全文搜索*
    • 源代码控制 - 暂存和提交您的更改，以及许多其他源代码控制操作
    • 时间线视图 - 查看带有差异支持的文件历史记录
    • 快速打开 - 快速找到要打开的文件
    • 远程指示器 - 显示远程仓库连接到的提供者（例如，GitHub）
  • 同时在不同的分支上工作 - 每个远程分支都被视为一个独立的工作树（用Git术语来说），这意味着你所做的任何更改都仅限于该分支。你不需要为了切换到一个新分支来检出PR或开始一个新工作项而暂存你的更改。当你回到之前的分支时，你的更改仍然会在那里。
  • 安装GitHub Pull Requests and Issues扩展，快速查看、探索和检出拉取请求，查看并开始处理问题。

限制

  • 有限的语言智能 - 许多语言服务器尚未理解这种虚拟化环境。TypeScript 支持远程仓库的单文件智能。
  • 有限的扩展支持 - 与语言服务器一样，许多扩展不适用于远程仓库。扩展可以选择退出，并且不会在虚拟工作区中激活。有关更多详细信息，请参阅下面的扩展编写部分。
  • 搜索 - 全文搜索需要预先构建的索引以进行精确文本匹配，否则将回退到GitHub的模糊默认分支原生搜索。
  • 终端 - 不支持。任何打开的终端将在您的本地文件系统上。
  • 调试 - 不支持。
  • 任务 - 不支持。

告诉我们您的想法

我们非常兴奋地期待您体验远程仓库（RemoteHub），并迫不及待地想要听到您的想法和反馈。我们才刚刚开始这段旅程，因此随着我们继续开发，预计功能集将会增加，限制将会减少。我们还将扩展支持的服务提供商。GitHub只是我们支持的第一个提供商，Azure Repos即将推出。

TypeScript 4.3

此版本继续改进我们对即将发布的 TypeScript 4.3 的支持。您可以在 TypeScript 博客 上阅读更多关于 TypeScript 4.3 的新语言功能和改进。以下是它带来的一些编辑器改进：

  • 支持 override。还有用于添加 override 关键字的快速修复。
  • 导入语句补全。这类似于自动导入，只不过你是在输入导入语句本身。
  • JSDoc @link 标签支持。

要开始使用 TypeScript 4.3 的夜间构建版本，只需安装 TypeScript Nightly 扩展。请分享您的反馈，并告诉我们您在使用 TypeScript 4.3 时是否遇到任何错误。

工作区信任

在上一个里程碑的发布说明中，我们分享了针对扩展作者的工作空间信任（Workspace Trust）工作。在这个里程碑中，我们在扩展API和用户体验方面取得了很大进展。尽管如此，工作空间信任在此版本中仍将保持禁用状态，但我们非常希望您能尝试并提供反馈。

您可以通过以下设置启用该功能 security.workspace.trust.enabled。启用后，在 VS Code 中打开文件夹时，您将看到以下对话框。

工作区信任启动对话框

此对话框对于允许用户尽早做出决策并理解其决策的影响非常重要。一旦您了解了该功能，您可能希望使用security.workspace.trust.startupPrompt设置来自定义何时显示对话框。

您可以关注Workspace Trust的开发并在issue #106488中提供反馈。

对扩展的贡献

远程开发

工作仍在继续在远程开发扩展上，这些扩展允许您使用容器、远程机器或Windows Subsystem for Linux (WSL) 作为全功能的开发环境。

1.56版本的功能亮点包括：

  • 当您在容器卷中克隆仓库时，新增的卷视图。
  • 连接到远程时本地终端警告。
  • 在使用 Dev Containers 扩展启动时提示安装 Docker Desktop。

您可以在远程开发发布说明中了解新的扩展功能和错误修复。

GitHub 拉取请求和问题

工作仍在继续在GitHub Pull Requests and Issues扩展上，该扩展允许您处理、创建和管理拉取请求和问题。

要了解所有新功能和更新，您可以查看扩展的完整0.26.0版本的变更日志。

扩展开发

定义您的扩展是否支持虚拟工作区

新的远程仓库扩展允许您直接从GitHub打开包含内容的文件夹。它通过提供一个虚拟文件系统并在其上打开工作区来实现这一点。其他扩展也执行相同的操作。它们从ftp服务器、云存储或数据库中提供内容，并无缝地将这些内容作为文件提供给VS Code中的用户。

虚拟文件系统功能已经存在了一段时间，然而我们观察到并非所有扩展都能支持在虚拟工作区中运行，即工作区文件并未实际存在于磁盘上。因此，我们增加了对扩展的支持，以表明其是否支持在虚拟工作区中运行。当某个扩展选择不支持时，VS Code 将不会在虚拟工作区中激活该扩展，用户也不会看到来自该扩展的错误。

扩展在package.json中选择退出虚拟工作区设置，如下所示：

{
  "capabilities": {
    "virtualWorkspaces": false
  }
}

目标是尽可能多的扩展支持在虚拟工作空间中运行。然而，这并不总是可能的，特别是当扩展使用的组件假设文件实际存在时。虚拟工作空间指南记录了扩展如何支持虚拟工作空间。

行动号召：请检查您的扩展是否能够处理虚拟工作区，并在您的package.json中相应地设置virtualWorkspaces功能。

在扩展采用新的virtualWorkspaces属性之前，将有一个过渡期。在此之前，我们维护了一个内部列表，列出了我们认为应该将virtualWorkspaces能力设置为false的扩展。这是基于分析扩展是否使用Node.js的fs模块并因此直接访问文件系统来完成的。然而，扩展作者更有能力评估扩展是否支持virtualWorkspaces能力。为了跟踪采用情况，我们创建了以下跟踪问题 #122836。如果您的扩展在列表中并且您已经采用了virtualWorkspaces能力，请在上述问题中添加评论。

远程指示器菜单

扩展现在可以为远程指示器菜单做出贡献：

状态栏左侧的远程指示器

statusBar/remoteIndicator 菜单贡献点向远程指示器菜单添加了一个命令。

"contributes": {
    "menus": {
        "statusBar/remoteIndicator": [
        {
          "command": "remote-wsl.newWindow",
          "when": "!remoteName && isWindows",
          "group": "remote_10_wsl_0_local@1"
        }
    ]},
    "commands": [
      {
        "command": "remote-wsl.newWindow",
        "title": "New WSL Window",
        "category": "Remote-WSL"
      }
    ]
}

为了使菜单能够根据提供者排序条目，group需要遵循特定的语法：

对于来自远程的命令：remote_${orderOfGroups}_${remoteName)_${internalGrouping}@${orderInGroup}

对于来自虚拟文件系统的命令：virtualfs_${orderOfGroups}_${fileScheme)_${internalGrouping}@${orderInGroup}

  • orderOfGroups 是一个用于对组进行排序的2位数字
  • remoteName 是 remoteAuthority 的第一部分（wsl, ssh,...）
  • fileScheme 是虚拟文件系统的URI模式
  • internalGrouping 可以自由用于每个贡献
  • orderInGroup 用于在您的组内对条目进行排序

示例：remote_10_wsl_1-open@1

iframes 现在用于大多数 webviews

自从webview API首次引入以来，我们一直使用Electron的webview标签来实现webview。然而，在网页上，由于不可用，VS Code的webviews是使用标准的元素来实现的。

我们一直在探索将VS Code的桌面版本迁移到使用支持的webviews，因为这一变化将为扩展提供一个在桌面和网页之间更一致的webview环境。从迁移也将有助于我们的Electron沙盒化工作。

在这个迭代中，我们已经将大部分webview切换为使用iframe。标签现在仅用于启用查找小部件的webview，我们计划在完成一些额外的工程工作后也将它们迁移到使用iframe。

此更改不应引起问题，但在某些边缘情况下， 和 元素的行为会有所不同。请确保对您的扩展进行快速测试，以验证一切是否按预期工作。

更轻松地检查Web视图

使用支持的webview的一个明显好处是，它们现在更容易检查。

如果您之前使用过webviews，您可能记得您必须使用开发者：打开Webview开发者工具命令来检查您的webview内容。这将为您打开一个新的开发者工具面板，专门用于您的webview。

在开发者工具窗口中检查webview

使用支持的webviews，你可以使用VS Code的标准开发者工具（开发者：切换开发者工具）来检查webviews。

在主开发者工具窗口中检查webview

这使得检查多个网页视图变得容易。当您的网页视图消失时，开发者工具也不再关闭。

此外，发生在webviews内部的异常和控制台消息现在会打印在顶层的开发者工具控制台中。

在主开发者工具中打印的webview异常

你也可以使用开发者工具来评估webview上下文中的表达式。通过开发者：切换开发者工具打开VS Code的开发者工具后，打开控制台，并从上下文选择器中选择你的webview的active-frame。

选择调试控制台的当前范围

总的来说，能够使用VS Code的标准开发者工具应该能为webviews提供更好的开发体验。

代码操作触发类型

新的triggerKind属性在CodeActionContext上跟踪为什么从CodeActionProvider请求代码操作。此属性的可能值为：

  • Invoke - 代码操作被明确请求，无论是通过键盘快捷键还是命令。
  • Automatic - 代码操作是在没有明确用户操作的情况下请求的。这包括在文档内容更改时请求代码操作。

提供者可以使用triggerKind根据代码操作请求的方式返回不同的结果集。例如，自动触发的重构代码操作提供者可能仅返回当前精确选择的重构，以限制代码操作灯泡显示的频率。然而，当明确请求代码操作时，相同的提供者可能会自动扩展当前选择，以尝试显示用户在当前位置可能感兴趣的所有重构。

更新后的codicons

我们已将以下新图标添加到我们的codicon库中：

  • arrow-swap
  • copy
  • debug-line-by-line
  • filter-filled
  • person-add
  • terminal-bash
  • terminal-cmd
  • terminal-debian
  • terminal-linux
  • terminal-powershell
  • terminal-tmux
  • terminal-ubuntu
  • wand

显示更新后的codicons及其名称的列表

快捷键标签颜色

当命令有关联的快捷键时，会显示快捷键标签。快捷键标签的用途包括（但不限于）：

  • 命令面板
  • 键盘快捷键编辑器
  • 键盘快捷键记录器模态框
  • 扩展市场页面中的“功能贡献”部分

以下自定义选项可用：

  • keybindingLabel.background: 快捷键标签背景颜色。快捷键标签用于表示键盘快捷键。
  • keybindingLabel.foreground: 快捷键标签前景色。快捷键标签用于表示键盘快捷键。
  • keybindingLabel.border: 快捷键标签边框颜色。快捷键标签用于表示键盘快捷键。
  • keybindingLabel.bottomBorder: 键绑定标签底部边框颜色。键绑定标签用于表示键盘快捷键。

工作区信任扩展API

上一个里程碑，我们提到了我们一直在进行的一个名为Workspace Trust的功能。我们要求扩展作者关注问题 #120251以获取更新，并且我们继续这样做。以下信息和更新也可以在该问题中找到。

在这个里程碑中，我们将Workspace Trust扩展API从提议状态转移到了稳定状态。这使得我们能够发布第一版指南，帮助您将扩展集成到Workspace Trust中。这个API很小，所以这里快速浏览一下。

您可以在package.json中使用untrustedWorkspaces功能来声明您的扩展在不信任的工作区中提供完全、部分或不支持。

以下示例声明扩展在不受信任的工作空间中完全受支持。在这种情况下，扩展在不受信任的工作空间中启用。

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

下一个示例声明该扩展在不受信任的工作区中不受支持。在这种情况下，扩展在不受信任的工作区中被禁用。

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

第三个选项是声明limited支持。当你选择limited选项时，有三个工具提供给你。

首先，如果你有一个可以在工作区中配置的设置，但需要工作区被信任才能应用工作区值，那么你可以在untrustedWorkspaces对象中使用restrictedConfigurations数组属性来包含该设置。这样做后，当你的扩展使用VS Code的Workspace Configuration API读取这些设置值时，VS Code将忽略这些受限设置的工作区值。

以下示例声明了在不受信任的工作区中受限的设置。

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

接下来，您还可以通过编程方式使用以下API来检查和监听当前工作区是否受信任：

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

最后，您可以在when子句中使用isWorkspaceTrusted上下文键来声明性地隐藏命令或视图。

行动号召：请查看问题 #120251中的“工作区信任扩展指南”，并根据您的扩展适当设置untrustedWorkspaces.supported值。

提议的扩展API

每个里程碑都伴随着新的提议API，扩展作者可以尝试使用它们。一如既往，我们希望得到您的反馈。以下是您尝试提议API需要做的事情：

  • 你必须使用Insiders，因为提议的API经常变化。
  • 您必须在扩展的package.json文件中包含这一行："enableProposedApi": true。
  • 将最新版本的vscode.proposed.d.ts文件复制到项目的源代码位置。

你不能发布使用提议API的扩展。在下一个版本中可能会有破坏性的更改，我们从不希望破坏现有的扩展。

原生笔记本

我们正在准备将大部分原生笔记本API进行最终化。我们已经进行了许多小的调整和一些重大的更改。

笔记本序列化器

我们添加了NotebookSerializer API。它提供了一种简化的方式将“字节”转换为NotebookData，反之亦然。当你实现这个API时，你的笔记本将免费获得备份、恢复、脏状态等功能。我们建议扩展作者采用这个新的API，而不是使用之前基于内容提供者的API。

笔记本控制器

笔记本控制器API取代了内核提供者API。笔记本控制器提供了笔记本的执行引擎，它创建了笔记本的输出。笔记本可以提供多个控制器或没有控制器，VS Code允许用户选择控制器。作为回报，扩展可以根据其领域模型的需求自由创建、修改和删除控制器。

笔记本单元格状态栏

NotebookCellStatusBarItemProvider API 替换了 createCellStatusBarItem 方法。它使扩展能够为每个单元格编辑器底部的状态栏贡献带有标签、图标和命令的项目。它遵循与许多其他 VS Code 扩展 API 相同的提供者模式。

测试

我们原本计划在本月完成新测试API的一个子集，然而我们专注于改进并将最终确定推迟到下个月，跟踪在issue #122208。本次迭代中进行的API更改主要是：

  • TestProvider 被重命名为 TestController，并且其方法也相应地被重命名。
  • TestItem 现在是作为由 vscode.test.createTestItem 调用的管理对象。
  • 测试结果现在通过标准的vscode.test.createTestResults方法创建，该方法可以在TestController.runTests内部或外部调用。

随着这些变化，还带来了一些额外的功能，例如显示原始测试输出的能力以及扩展指示加载测试中的错误。我们相信这些变化为未来的额外功能提供了坚实的基础，并且更紧密地与我们现有的扩展API保持一致。

我们还创建了一个测试适配器转换器扩展，它允许任何与现有的测试资源管理器 UI扩展一起工作的适配器自动插入到原生的 VS Code 测试中。转换器扩展今天可以手动安装，很快它将与测试资源管理器 UI 集成，为现有用户和适配器提供无缝迁移到原生测试的路径。

改进的ArrayBuffers与webviews之间的传输

在当前版本的VS Code中，向或从webview发送类型化数组有一些小问题：

  • 类型化数组，如UInt8Array，序列化效率非常低。当您需要传输大量数据（如几兆字节）时，这可能会导致性能问题。
  • 发送的类型数组在接收端不会重新创建为正确的类型。如果你发送一个UInt8Array，接收者会得到一个包含UInt8Array数据值的通用对象。

虽然这两个问题都是错误，但我们也不能在不破坏依赖现有行为的扩展的情况下修复它们。同时，新编写的扩展没有任何理由想要当前这种令人困惑且低效的行为。

因此，我们决定保留现有扩展的现有行为，但让新扩展选择更正确的行为。这是通过查看扩展的package.json中的engines来实现的。

"engines": {
  "vscode": "^1.57.0",
}

如果扩展目标为VS Code 1.57+，则应在接收端重新创建类型化数组，并且与webviews之间传输大型类型化数组的效率应大大提高。

请测试此行为，并告知我们它是否未按预期工作或导致现有代码出现意外的回归。

终端选项.message

这个新提案允许在进程启动之前在终端中显示一条消息。

vscode.window.createTerminal({
  message: '\x1b[3;1mSome custom message\x1b[0m'
});

调试适配器协议

异常断点与常规断点更好地对齐

setExceptionBreakpoints 请求现在可以选择性地返回一个与其它 set*Breakpoints 请求类似的 Breakpoint 数组。这使得客户端能够显示个别异常断点或过滤器的验证错误信息。从本版本开始，VS Code 在断点视图中显示这些错误。

重启请求现在可以获取调试配置更改

restart 请求现在接受一个新的可选参数 arguments，客户端可以通过该参数传递启动或附加配置的最新版本。通过这一新增功能，调试适配器可以使用调试配置中的最新值重新启动会话。

断开调试器并保持被调试程序挂起

disconnect 请求用于结束调试会话，并可以选择继续执行被调试程序或终止它。现在有一个新选项，可以在调试器断开连接后保持被调试程序处于挂起状态。这使得可以通过新的会话重新开始调试。

实现此功能的调试适配器必须通过supportSuspendDebuggee能力声明其支持。客户端可以通过向disconnect请求传递一个新的可选参数suspendDebuggee来使用此功能。

工程

Electron 12 更新

在这个里程碑中，我们完成了将Electron 12捆绑到VS Code的探索，感谢所有参与测试和在Insiders上进行自托管的每个人。这是一个重要的Electron版本，包含了Chromium 89.0.4389.114和Node.js 14.16.0。

Electron沙盒的进展

在这个里程碑中，我们继续为VS Code窗口做好准备，以便启用Electron的沙盒和上下文隔离功能。

具体来说：

  • 我们更改了所有需要的环境属性，以便在沙盒渲染器中访问VS Code窗口。
  • 我们正在探索在某些可能的情况下，通过选择性地启用iframe，将自定义编辑器从webview切换到iframe元素。
  • 我们能够将渲染器中一些原生模块或Node.js的需求转移到其他进程中，或者完全移除它们。
  • 我们使windows-process-tree具有上下文感知能力。

现在使用Service workers在webview中加载资源

在桌面版的VS Code中，webviews现在使用服务工作者来加载本地资源。VS Code的网页版本一直使用服务工作者来实现这一点，但之前桌面版的VS Code使用的是Electron协议。

在桌面版本中使用服务工作者，使我们能够更好地对齐桌面和网页之间网页视图的行为。它还帮助我们修复了一些棘手的错误，并让我们删除了大约1000行代码。

虽然这一变化对大多数webview扩展应该没有影响，但在一些边缘情况下可能会引起问题：

  • 扩展程序对webviews如何加载资源做出假设

    如果你的扩展直接使用了vscode-webview-resource:协议或硬编码了关于资源URI的其他假设，它可能不再有效。

    相反，请确保始终使用.asWebviewUri来创建资源的URI。还要记住，返回的URI格式在未来可能会发生变化。

  • 将iframe的src设置为指向磁盘上的HTML文件的扩展

    Service workers 无法看到此请求，因此我们不再支持此功能。这在网页上已经是这种情况，我们认为这种模式并不常见。

    推荐的修复方法是不要使用iframe，而是将HTML文件的内容内联到webview中。

代码库中未启用隐式覆盖

即将发布的TypeScript 4.3版本引入了一个新的override关键字，它告诉编译器子类中的方法覆盖了其父类中的方法。还有一个新的--noImplicitOverride标志，强制要求所有覆盖父类方法的方法必须使用override关键字：

class Foo {
   foo() {...}
}

class SubFoo extends Foo {
    foo() { ... } // Error when noImplicitOverride is enabled: missing override specifier
}

override 关键字有几个好处：

  • 在阅读代码时，它会提醒你某个方法正在覆盖基类中的方法

  • 尝试覆盖基类中不存在的方法是一个错误。这有助于捕获由于在基类中重命名方法但忘记在子类中更新方法名称而导致的错误。

在这次迭代中，我们在代码库中采用了override关键字，并为核心VS Code和所有内置扩展启用了--noImplicitOverride。虽然我们自动化了大部分工作，但这一更改确实帮助我们捕捉到了一些代码错误地重新声明属性或具有不清晰的继承模式的情况。

这种新的严格性规则也应该有助于我们在未来捕捉到一些常见的编程错误。

Windows 安装程序整合到 Windows 包管理器中

我们已经更新了Windows Package Manager的发布流程，以发布我们的用户和系统安装程序，支持arm64，并采用v1包清单模式，使我们能够将x86、x64和arm64的用户和系统安装程序合并到一个清单中。用户可以在安装包时使用--scope参数或通过winget CLI设置在用户和系统安装程序之间进行选择。

文档

更新的介绍视频

VS Code 的介绍视频已经更新。这些视频涵盖了从入门和使用扩展到 VS Code 功能如调试和版本控制。

VS Code 调试入门视频

新的C++视频

C++ 扩展团队创建了一系列入门视频，解释了如何配置 IntelliSense、构建和调试您的 C++ 项目。

VS Code背后的故事与技术

你可以阅读这篇采访，了解VS Code的历史和底层技术，采访对象是VS Code工程师Ben Pasero。Ben谈到了VS Code的早期发展以及使用Electron作为应用框架使VS Code能够在macOS、Windows和Linux上运行的经历。

合作伙伴扩展

Azure 机器学习

Azure Machine Learning 扩展使您能够为您的机器学习工作流程创建和管理强大的云计算资源。凭借其远程功能，您可以以安全、可审计和合规的方式无缝连接到您的计算资源。

Microsoft Azure 机器学习扩展

显著的修复

  • 108559: RunInTerminal 不使用工作区设置中指定的集成终端 bug
  • 118282: 调试器跳过进入skipFiles
  • 118731: 研究如何在异步打开浏览器窗口和标签页时避免Safari的弹出窗口拦截器
  • 119340: 如果启用了未捕获异常断点，运行而不调试永远不会终止
  • 121347: 从备份恢复时文件出现乱码
  • 119059: 自定义文本编辑器：恢复时备份会打开2个编辑器
  • 120245: CSS: !important 补全功能已损坏
  • 120393: 改进对webgl上下文丢失的处理
  • 120435: 移除 emmet.extensionsPath 的有效路径检查
  • 120882: 在资源管理器中粘贴文件不再在编辑器中打开该文件
  • 121148: 调试下拉菜单中显示了重复的启动配置
  • 120277: 在文件查找面板中的水平滚动条太小，并且滚动方向错误

感谢您

最后但同样重要的是，向本月为VS Code做出贡献的以下人员表示衷心的感谢：

对我们问题跟踪的贡献：

对 vscode 的贡献：

对 vscode-eslint 的贡献：

对 vscode-json-languageservice 的贡献：

对 vscode-vsce 的贡献：

对debug-adapter-protocol的贡献：

对 vscode-js-debug 的贡献：

对 vscode-generator-code 的贡献：