在 VS Code 中试用

2024 年 9 月 (版本 1.94)

更新 1.94.1:此更新解决了这个安全问题

更新 1.94.2:此更新解决了这些问题

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


欢迎阅读 Visual Studio Code 2024 年 9 月的发布说明。此版本包含许多更新,希望您会喜欢。以下是其中的一些主要亮点:

如果您想在线阅读这些发布说明,请访问 code.visualstudio.com 上的更新Insiders:想尽快试用新功能?您可以下载每晚的 Insiders 版本,并在最新更新可用时立即试用。

GitHub Copilot

在聊天中切换语言模型

之前,我们宣布您可以注册提前访问 OpenAI o1 模型。获得访问权限后,您将在 VS Code 中的 Copilot Chat 中看到一个 Copilot Chat 模型选择器控件,用于选择聊天对话使用的模型版本。

Copilot model picker control in the Chat view enables switching to another language model.

内联聊天中的 GPT-4o

我们将 Copilot 内联聊天升级到 GPT-4o,以便在使用编辑器中的聊天时为您提供更快、更准确、更高质量的代码和解释。

聊天中的公共代码匹配

您可以允许 GitHub Copilot 返回可能与 GitHub.com 上公开可用的代码相匹配的代码。当您的组织订阅个人订阅启用此功能时,Copilot 代码补全已为您提供了有关检测到的匹配项的详细信息。现在,我们也在 Copilot Chat 中向您显示公共代码的这些匹配项。

如果您的组织或订阅启用了此功能,您可能会在响应末尾看到一条消息,其中包含一个查看匹配项链接。如果您选择该链接,将打开一个编辑器,其中显示匹配代码引用的详细信息以及更多详细信息。

Chat code referencing example.

在 GitHub 博客上获取关于 GitHub Copilot 中的代码引用的更多信息。

聊天中的文件建议

在聊天输入字段中,您现在可以输入 #<filename> 来获取文件名建议,并快速将它们作为上下文附加到您的提示中。这适用于支持文件附件的聊天位置,例如聊天视图、快速聊天、内联聊天和笔记本聊天。

我们改进了 Copilot 响应中提到的任何工作区文件路径的呈现。当您提问 @workspace 问题时,这些路径非常常见。

您首先会注意到,工作区文件的路径现在包含一个文件图标。这使您可以在聊天响应中轻松区分它们。文件图标基于您当前的文件图标主题

Paths to workspace files in the response now render using file icons.

这些路径是交互式链接,只需选择它们即可打开相应的文件。您甚至可以使用拖放功能在新编辑器组中打开文件,或者在拖放之前按住Shift将其插入到文本编辑器中。

默认情况下,这些链接仅显示文件名,但您可以将鼠标悬停在其上以查看完整文件路径。

Hovering over a workspace path to see the full workspace path.

您还可以右键单击其中一个路径以打开上下文菜单,其中包含其他命令,例如复制资源的相对路径,或在操作系统的文件资源管理器中显示文件。

The context menu for a workspace path in chat provides options to open the file or copy its path.

我们计划在接下来的迭代中进一步改进工作区路径的呈现,并对响应中的符号名称进行类似的改进。

拖放文件添加聊天上下文

现在,您可以通过将文件或编辑器选项卡从工作台直接拖到聊天中,轻松将其他文件作为聊天提示的上下文附加。对于内联聊天,按住Shift 并拖放文件以将其作为上下文添加,而不是在编辑器中打开它。

历史记录中包含文件附件

有多种方法可以将文件或编辑器选择作为相关上下文附加到您的聊天请求。以前,此上下文仅添加到当前请求中,并且不包含在后续请求的历史记录中。现在,这些附件保留在历史记录中,这样您就可以继续引用它们而无需重新附加。

Chat conversation shows that Copilot keeps track of attached files across multiple prompts.

Python Native REPL 中的内联聊天和补全

Python 扩展使用的 Native REPL 编辑器现在直接在输入框中支持 Copilot 内联聊天和代码补全。

在笔记本中接受并运行生成的代码

当您使用 Copilot 内联聊天在笔记本中生成代码时,您现在可以从内联聊天中接受并直接运行生成的代码。

在笔记本聊天中附加变量

当您在笔记本中使用 Copilot 时,您现在可以在请求中附加 Jupyter 内核中的变量。添加变量使您可以更精确地控制聊天请求的上下文,从而从 Copilot 获得更相关的响应。

您可以在内联聊天中输入 # 后跟变量名,或使用 📎 控件 (⌘/ (Windows, Linux Ctrl+/)) 来添加上下文变量。

刷新了聊天用户体验

我们刷新了聊天视图,提供了全新的简洁欢迎体验,并更新了聊天输入区域的布局。您现在可以使用 @ 按钮轻松找到可用的聊天参与者和斜杠命令列表,包括内置的以及您已安装的扩展中的聊天参与者。您仍然可以通过在聊天输入框中输入 /@ 来查找参与者和斜杠命令。

Updated Chat view welcome experience.

语义搜索结果 (预览)

设置github.copilot.chat.search.semanticTextResults

搜索视图使您能够对文件执行精确搜索。我们现在为搜索视图添加了功能,该功能使用 Copilot 提供语义相关的搜索结果。

此功能仍处于预览阶段,默认情况下,此设置未启用。请试用并告诉我们您的想法!

修复测试失败 (预览)

设置github.copilot.chat.fixTestFailure.enabled

我们添加了专门的逻辑来帮助您诊断失败的单元测试。在某些情况下,此逻辑由 /fix 斜杠命令触发,您也可以使用 /fixTestFailure 斜杠命令直接调用它。此命令默认在聊天中启用,但可以通过设置 github.copilot.chat.fixTestFailure.enabled 禁用。

自动化测试设置 (实验性)

设置github.copilot.chat.experimental.setupTests.enabled

我们添加了一个实验性 /setupTests 斜杠命令,它可以帮助您配置工作区的测试设置。此命令可以推荐测试框架,提供设置和配置步骤,并建议一个 VS Code 扩展来提供 VS Code 中的测试集成。这可以为您节省时间和精力,以便开始对代码进行测试。

当您使用 /tests 命令为您的代码生成测试时,如果您的工作区似乎尚未设置此类集成,它可以推荐 /setupTests 和测试扩展。

从聊天开始调试 (实验性)

设置github.copilot.chat.experimental.startDebugging.enabled

在此里程碑中,我们改进了实验性的 /startDebugging 斜杠命令。此命令使您能够轻松找到或创建启动配置并无缝开始调试您的应用程序。当您在 Copilot Chat 中使用 @vscode 时,/startDebugging 现在默认可用。

A user types /startDebugging flask app port 3000 in the panel chat and is provided with the launch configuration.

命令中心中的聊天 (实验性)

设置chat.commandCenter.enabled

我们正在尝试在命令中心中提供一个访问聊天的入口。它提供了对所有相关聊天命令的快速访问,例如启动不同的聊天体验或将上下文附加到您的提示。请注意,要显示聊天命令中心入口,命令中心本身需要启用。

Chat Command Center button and the drop-down menu with relevant chat actions.

改进的时间上下文 (实验性)

设置github.copilot.chat.experimental.temporalContext.enabled

通过时间上下文,您可以指示内联聊天将最近打开或编辑的文件视为聊天上下文的一部分。我们改进了此功能,邀请大家试用。

自定义指令 (实验性)

设置github.copilot.chat.experimental.codeGeneration.useInstructionFiles

设置github.copilot.chat.experimental.testGeneration.instructions

在上一里程碑中,我们引入了自定义的代码生成指令。我们进一步扩展了此功能,以便在工作区的 .github/copilot-instructions.md 文件中定义用于代码生成的共享指令。这些通用指令补充了您自己的个人代码生成指令。使用设置 github.copilot.chat.experimental.codeGeneration.useInstructionFiles 启用代码生成指令文件。

此外,您现在可以在设置中定义测试生成的指令或从文件导入它们。例如,如果您总是想对测试使用特定的单元测试框架。在设置 github.copilot.chat.experimental.testGeneration.instructions 中配置测试生成指令。

辅助功能

入门

我们的帮助菜单现在包含一个辅助功能入门演练,这使得您可以更轻松地探索和使用辅助功能选项。该演练向您介绍了辅助功能帮助对话框、辅助功能信号、键盘快捷方式等功能。

Get Started with Accessibility Features product walkthrough.

注释辅助功能改进

我们为注释线程控件引入了一个可访问的视图。该视图包含相关的编辑器上下文,使您能够保持专注,而无需在编辑器和可访问视图之间切换。同样,现在在注释面板的可访问视图中提供了编辑器上下文。

我们还引入了注释:聚焦当前行的注释命令,该命令允许您使用键盘快速从编辑器移动到注释控件。编辑器中还有一些新操作可用于转到下一个和上一个注释范围:注释:转到下一个注释范围注释:转到上一个注释范围

工作台

更改扩展的帐户偏好设置

在此迭代中,我们探讨了如何改进更改扩展首选帐户的体验。例如,如果您有多个 GitHub 帐户,并且不小心使用了错误的帐户登录 GitHub Copilot,现在需要使用另一个帐户。

现在可以通过多种方式更改该偏好设置。

  • 活动栏中的帐户菜单 > <您的帐户> > 管理受信任的扩展 > 选择扩展的齿轮图标

    Manage trusted extensions Quick Pick, with gear button highlighted.

  • 扩展视图 > 使用身份验证的扩展的上下文菜单(或齿轮图标) > 选择帐户偏好设置

    Account preferences option in the context menu of an extension.

  • 扩展详细信息视图 > 齿轮图标 > 选择帐户偏好设置

    Account preferences option in the gear menu of an extension.

选择其中任何一个选项都会带您到一个 Quick Pick,您可以在其中更改扩展使用的帐户。

The account preference Quick Pick that enables you to select extensions for a given account.

当您更改扩展的帐户偏好设置时,这会向扩展发送一个事件,由扩展来正确处理。如果您没有看到预期的行为,请针对该扩展报告问题,以便处理帐户偏好设置体验。

另外,如果您对此流程有任何反馈,也请告知我们。

查看与配置文件关联的文件夹和工作区

在此里程碑中,我们在配置文件编辑器中引入了文件夹和工作区部分。此部分集中列出了与特定配置文件关联的所有文件夹和工作区。在此部分中,您可以添加或修改文件夹,或在新窗口中打开文件夹或工作区。

Folders & Workspaces section in the Profile editor.

更新所有配置文件中的扩展

在此里程碑中,我们引入了更新所有配置文件中扩展的功能。如果您有多个配置文件并希望保持扩展版本同步,此功能非常有用。以前,您必须切换到每个配置文件并更新该配置文件的扩展。

扩展视图中的警告

当存在任何无效扩展或因版本不兼容而禁用的扩展时,扩展视图现在会显示警告徽章及相关信息。

Extensions view shows a warning badge and description about the warning.

在资源管理器中查找

我们改进了资源管理器视图中的查找功能,以便更容易在大项目中搜索文件。您可以使用键盘快捷方式 ⌥⌘F (Windows, Linux Ctrl+Alt+F) 在文件资源管理器中打开查找控件。搜索时,您可以在模糊匹配和连续匹配之间切换,以获得更灵活的结果。

请注意,在搜索过程中,某些上下文菜单操作会暂时禁用。敬请期待更多改进!

发布说明

我们在发布说明中引用设置的语法得到了简化 (setting.name),在发布说明编辑器中显示时,它也具有现在熟悉的设置齿轮呈现效果。

Setting URL in release notes enables navigating to the Settings editor directly.

编辑器

内嵌提示改进

我们添加了设置 editor.inlayHints.maximumLength,它控制内嵌提示在多少个字符后被截断。

我们还修改了内嵌提示的更新策略,现在在键入时,它们应该更快地更新,但不会导致光标发生水平移动。

实验性编辑上下文

在此里程碑中,我们引入了一个新的实验性设置 editor.experimentalEditContextEnabled。此设置启用了 EditContext API 以增强 VS Code 中的编辑体验。采用 EditContext API 使我们能够修复某些 IME 输入法错误。总的来说,我们相信它将长期改善编辑体验,最终将默认启用。

启用此设置后,请确保重新加载您的 VS Code 窗口以利用它。

源代码管理

源代码管理图视图改进

在上一里程碑中,我们添加了新的源代码管理图视图。在此里程碑中,我们一直致力于扩展新添加视图中可用的功能以及优化视图的布局。

存储库选择器

当您打开包含多个存储库的文件夹/工作区时,源代码管理图视图标题会显示一个存储库选择器。默认情况下,源代码管理图视图显示活动存储库,与状态栏中的信息匹配。您可以使用存储库选择器将源代码管理图视图锁定到特定的存储库。

Repository picker control in the title of the Source Control Graph view.

历史项引用选择器

在此里程碑中,我们为源代码管理图视图标题添加了一个新的历史项引用选择器。您可以使用此引用选择器将图中显示的历史项过滤到不同的分支,或查看多个分支。

History item reference Quick Pick control to choose one or more items.

默认情况下,历史项引用选择器设置为 Auto,它会为当前历史项引用、其远程以及可选的基础版本渲染图表。

History item reference picker control in the title of the Source Control Graph view.

历史项操作

在此里程碑中,我们扩展了源代码管理历史项上下文菜单中可用的操作列表。我们添加了从历史项创建新分支/标签、选择历史项(cherry-pick)和检出(detached)一个项的操作。

Context menu for items in the Source Control Graph view.

源代码管理图设置

在此里程碑中,我们添加了一组新设置,以便您可以自定义图表

  • scm.graph.badges - 控制在源代码管理图视图中显示哪些徽章
  • scm.graph.pageOnScroll - 控制当您滚动到列表末尾时,源代码管理图视图是否加载下一页项
  • scm.graph.pageSize - 在源代码管理图视图中显示和加载更多项时的默认项数

笔记本

跨单元格的多光标支持 (预览)

通过设置 notebook.multiCursor.enabled,笔记本编辑器现在支持跨单元格的多光标编辑。目前,这只能通过快捷方式 Ctrl+D 触发,并支持核心编辑器操作以及有限的编辑器命令子集。

Diff 编辑器显示文档元数据更改

笔记本 Diff 编辑器现在还显示对文档元数据的更改,例如内核信息和单元格语言。

Notebook dif editor showing side-by-side changes to the document metadata.

在 Diff 视图中折叠未更改区域

笔记本 Diff 视图现在遵循设置 diffEditor.hideUnchangedRegions.enabled。启用后,未更改的代码块默认会折叠,这使得在大笔记本中查看更改更加容易。

Diff editor shows unchanged code blocks as collapsed.

Web Worker 中的笔记本序列化 (实验性)

此版本引入了一个实验性功能,可在 Web Worker 中启用笔记本序列化。当您处理大型笔记本时,这有助于减少扩展宿主进程中的主线程阻塞时间。默认情况下,此功能处于禁用状态,但可以通过将设置 ipynb.experimental.serialization 设置为 true 来启用。

调试

支持数据着色

VS Code 支持来自调试适配器协议的新文本样式功能。这使得变量视图、监视视图、悬停提示和调试控制台中的数据可以通过 ANSI 转义序列进行着色。

JavaScript 调试器

改进的 HTML 元素显示

我们改进了 JavaScript 调试器中 HTML 元素的显示方式。以前,它们作为原始对象呈现,难以导航。现在,它们更接近于 DOM 结构,并且我们利用新的着色功能提供一些基本的语法高亮显示。

HTML elements are colorized in the JavaScript Debug Console.

启动配置中 Node 命令的自动完成

现在,launch.json 文件中提供了新的自动完成助手,适用于安装在您的 node_modules 中的命令行应用程序。这使得更容易为 vitestnest 等工具设置调试。

更整洁的已加载源视图

我们更改了 Node.js 内置模块、评估脚本和 WebAssembly 模块的源路径结构方式,以使已加载源视图更整洁且更易于浏览。

语言

TypeScript 5.6

我们的 JavaScript 和 TypeScript 支持现在使用 TypeScript 5.6。这一重要更新包含许多语言和工具方面的改进,以及重要的错误修复和性能优化。

您可以在 TypeScript 博客上阅读关于 TypeScript 5.6 发布的所有内容。我们还在以下部分包含了一些工具方面的亮点。

检测一些常见的“总是为真”的编程错误

假设您在 JavaScript 或 TypeScript 中使用正则表达式并编写了这样的代码

const str = '...'
if (/\d+(\.\d+)?/) {
  ...
} else {
  ...
}

哎呀!看来我们忘记了对正则表达式调用 .test(),这意味着 if 条件始终评估为 true。这不是我们想要的。

即使指出后这个问题很明显,但犯这样的错误却出奇地容易,甚至导致了 VS Code 中的真实错误!谢天谢地,TypeScript 现在会报告程序中一些最常见的“总是为真”错误。这包括测试 if 条件时针对一个永远不会是值的值,或者条件表达式中有一侧无法访问,例如 /abc/ ?? /xyz/

查看 TypeScript 发布说明了解更多示例和此功能的工作原理详情。

区域优先诊断

在非常长的 JavaScript 或 TypeScript 文件中工作?多亏了区域优先诊断,您应该会更快地看到类型错误诊断。这意味着我们尝试获取当前可见代码的诊断并首先显示它们,即使文件的其余部分诊断仍在计算中。

此优化最适用于具有数千行的复杂文件。对于较小的文件,您可能不会注意到任何变化。

改进的 JavaScript 和 TypeScript 提交字符

提交字符可以在输入时自动接受补全,从而加快编码速度。例如,在 JavaScript 和 TypeScript 中,. 通常被视为提交字符。这意味着要键入 myVariable.property.,您只需键入 myv.p.,第一个 . 接受 myVariable 的补全,第二个 . 接受 property 的补全。

这些提交字符现在由 TypeScript 计算,这意味着它们可以更好地考虑程序的结构。我们也可以随着时间的推移继续改进对它们的支持。

提交字符默认启用,但可以通过将设置 editor.acceptSuggestionOnCommitCharacter 设置为 false 来禁用。

自动导入的排除模式

新的 autoImportSpecifierExcludeRegexes 允许您通过使用正则表达式从特定包中排除自动导入。例如,要从像 lodash 这样的模块的子目录中排除自动导入,您可以设置

{
  "typescript.preferences.autoImportSpecifierExcludeRegexes": ["^lodash/.*$"]
}

您可以使用 javascript.preferences.autoImportSpecifierExcludeRegexes 配置 JavaScript,使用 typescript.preferences.autoImportSpecifierExcludeRegexes 配置 TypeScript。更多详情请参阅TypeScript 5.6 发行说明

远程开发

远程开发扩展允许您使用开发容器、通过 SSH 或远程隧道连接的远程机器,或者适用于 Linux 的 Windows 子系统 (WSL) 作为功能齐全的开发环境。

亮点包括

  • 通过 SSH/隧道连接到 Kubernetes 容器
  • 手动指定 GPU 可用性

您可以在远程开发发行说明中了解这些功能的更多信息。

对扩展的贡献

Python

运行带覆盖率的测试

现在可以在 VS Code 中运行带覆盖率的 Python 测试了!要运行带覆盖率的测试,请在测试资源管理器中选择运行覆盖率图标,或从通常触发测试运行的任何菜单中选择“运行带覆盖率”。如果您使用 pytest,Python 扩展将使用 pytest-cov 插件运行覆盖率;如果使用 unittest,则使用 coverage.py

覆盖率运行完成后,编辑器中会突出显示行以表示行级覆盖率。可以在底部的运行结果面板中关闭或重新打开这些高亮,最近一次测试运行下方会显示“关闭测试覆盖率”或“查看测试覆盖率”。此外,测试资源管理器的“测试”选项卡下方会出现一个“测试覆盖率”选项卡,其图标也是烧杯状,您也可以通过命令面板中的 测试: 聚焦到测试覆盖率视图 (⇧⌘P (Windows, Linux Ctrl+Shift+P)) 导航到该选项卡。在该面板中,您可以查看工作区中每个文件和文件夹的行和分支覆盖率指标。

有关运行带覆盖率的 Python 测试的更多信息,请参阅我们的Python 文档。有关测试覆盖率的一般信息,请参阅 VS Code 的测试覆盖率文档

Python 默认问题匹配器

Python 扩展现在包含一个默认的问题匹配器,可以简化 Python 代码中的问题跟踪,并提供更多上下文相关的反馈。要集成它,请将 "problemMatcher": "$python" 添加到 task.json 文件中的 tasks。问题匹配器会扫描任务输出中的错误和警告,并在“问题”面板中显示它们,从而增强您的开发工作流程。

下面是一个使用 Python 默认问题匹配器的 task.json 文件示例

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Run Python",
      "type": "shell",
      "command": "${command:python.interpreterPath}",
      "args": ["${file}"],
      "problemMatcher": "$python"
    }
  ]
}

Python 终端 REPL 中的 Shell 集成

Python 扩展现在包含一个设置,用于选择启用或禁用 PYTHONSTARTUP 脚本。该脚本在您输入 python 或通过任何其他方式在终端中启动 Python REPL 之前运行。如果选择启用,则可以使用终端 shell 集成功能,例如命令装饰、重新运行命令、运行最近的命令(如果在 Mac 或 Linux 系统中)。可以通过设置 python.terminal.shellIntegration.enabled 来启用此功能。

Pylance 语言服务器模式

有一个新设置 python.analysis.languageServerMode,它允许您在我们当前的 IntelliSense 体验和为性能优化而设计的轻量级体验之间进行选择。

如果您不需要完整的 IntelliSense 功能,并希望 Pylance 尽可能节省资源,可以将 python.analysis.languageServerMode 设置为 light。否则,要继续使用当前 Pylance 的体验,可以将其设置为 default

这项新功能会覆盖以下设置的默认值

设置 light 模式 default 模式
"python.analysis.exclude" ["**"] []
"python.analysis.useLibraryCodeForTypes" false true
"python.analysis.enablePytestSupport" false true
"python.analysis.indexing" false true

上述设置仍然可以单独更改以覆盖默认值。

GitHub Pull Requests

GitHub Pull Requests 扩展已取得更多进展,它使您能够处理、创建和管理 pull requests 和 issue。请查看该扩展的 0.98.0 发行版的变更日志以了解亮点。

扩展创作

在桌面应用中移除自定义分配器

在此版本中,我们已从桌面应用程序扩展宿主中移除了在 1.78 版本中添加的自定义分配器。此自定义分配器作为支持与 V8 沙箱不兼容、且基于 Electron 运行时构建的 Node.js 原生插件的桥梁。您可以参考此跟踪问题获取更多背景信息。

我们已确保排名前 5000 的扩展不受此更改的影响。如果您的扩展或其依赖项受到此更改的影响,您可以尝试以下补救建议:

  • 如果您的扩展使用 n-api,那么在使用外部数组缓冲区时将返回状态 napi_no_external_buffers_allowed。在这种情况下,您可以切换到使用 API 的复制版本 napi_create_buffer_copy
  • 如果您的扩展使用 node-addon-api,请参考此文档以获取替代 API 和编译时设置。
  • 如果您想避免复制带来的性能开销,可以使用 V8 分配器来确保缓冲区后端存储与 V8 沙箱兼容。

我们还添加了遥测功能,用于识别可能受影响的扩展和原生插件,以便我们主动联系扩展作者并在可能的情况下提供帮助。如果您的扩展受到影响,并且上述建议均无效,请在我们的讨论帖中留言,我们将乐意提供帮助。

调试适配器协议

我们在调试适配器协议中规范化了如何在变量和输出显示中进行文本着色和样式设置。着色通过 ANSI 控制序列实现,并要求客户端和调试适配器在其初始化请求和功能中分别支持 supportsANSIStyling

预览功能

多个 GitHub 帐户

现在可以在 VS Code 中同时登录多个 GitHub 帐户了。

此功能在 VS Code Insiders 中默认启用。在 VS Code 的 Stable 版本中,您可以通过 github.experimental.multipleAccounts 设置来开启此功能。

以下是一些您可能需要多个帐户的场景:

  • 使用帐户 1 用于设置同步,帐户 2 用于 GitHub Pull Request 扩展
  • 使用帐户 1 用于 GitHub 扩展(用于推送),帐户 2 用于 GitHub Copilot

要使用此功能,只需触发登录操作(无论是通过内置功能如设置同步,还是通过扩展),系统就会提供登录不同帐户的选项。如果您需要在后期更改帐户,此功能还可以与新的帐户偏好快速选择功能很好地搭配使用。

虽然大多数功能应该可以继续与您现有的扩展一起工作,但某些行为可能还无法完全适应这种多帐户环境。如果您认为有改进的空间,请在这些扩展上提交 issue。借助相对较新的 vscode.authentication.getAccounts('github') API,扩展能够很好地处理多个帐户。

在下一个迭代中,我们计划默认对所有用户开启此功能。

基于 MSAL 的 Microsoft 身份验证

我们一直在努力让我们的 Microsoft 身份验证堆栈使用 MSAL(Microsoft 身份验证库)。这是一项巨大的工程,但在此迭代中我们取得了很大进展。这项工作涵盖了所有 VS Code 客户端,包括 VS Code 桌面版和 VS Code for the Web

  • 对于 vscode.dev,我们已为所有 Microsoft 身份验证请求启用了基于浏览器的 MSAL.js。换句话说,vscode.dev 现在完全基于 MSAL。

  • 对于 VS Code 桌面客户端,我们通过设置 microsoft.useMsal 启用了此功能。目前将其放在设置后面,是因为我们计划转向代理流程,这将使 VS Code 能够使用操作系统的身份验证状态。因此,为了尽可能减少中断,我们将先完成这项工作,然后再广泛启用此功能。话虽如此,如果您渴望尝试这种新的身份验证方式,我们欢迎您尝试并向我们提供反馈。

您可以在 issue #178740 中查看 VS Code 所有客户端向 MSAL 过渡的详细状态。

TypeScript 5.7

此版本包含对即将发布的 TypeScript 5.7 版本的初步支持。请查看TypeScript 5.7 计划以了解详情。

要开始使用 TypeScript 5.7 的预览版构建,请安装 TypeScript Nightly 扩展

提议的 API

语言模型工具

我们将继续迭代我们的 LanguageModelTool API。该 API 包含两个主要部分:

  1. 扩展能够注册*工具*的能力。工具是供语言模型使用的功能片段。例如,读取文件的 Git 历史记录。

  2. 语言模型支持工具的机制,例如扩展在发出请求时传递工具,语言模型请求调用工具,以及扩展将工具调用的结果反馈回来。

在此里程碑中,我们添加了工具在运行前请求用户确认的功能。这对于可能产生某些副作用的工具很有帮助。

请查看issue #213274 以了解更多详情或提供反馈。

注意:该 API 仍在积极开发中,可能会发生变化。

工程

VS Code 正式发布 ESM 支持

我们终于在 VS Code Stable 版本中发布了 ESM 相关工作。这意味着 VS Code 核心的所有层(electron、node.js、browser、workers)都在 JavaScript 中使用 importexport 语法进行模块加载和导出。所有对旧版 AMD 加载器的使用均已禁用,并将在 10 月的“技术债清理周”期间移除。

迁移到 ESM 极大地提高了启动性能。一方面,移除了大量的 AMD 开销,另一方面,主工作台 bundle 的大小也减小了 10% 以上。

Graph showing the trend of the main bundle load time, showing a large drop after introducing ESM.

现在我们已完全转换为 ESM,我们计划改进 VS Code 的工程系统。借助 ESM,许多现代工具将能为我们所用,我们非常高兴在不久的将来分享更多详细信息。

注意:扩展不受此更改的影响,并且不通过 ESM 加载,请参阅 https://github.com/microsoft/vscode/issues/130367 了解详情。

使用 NPM 作为默认包管理器

自 2024 年 9 月初,我们已在 microsoft/vscode 仓库中完成了从 yarn 到 npm 的包管理切换。此决定基于 VS Code 的特定需求,并围绕以下标准:

  • 性能:我们最初因性能原因转向 yarn,现在 npm 也能满足我们的需求
  • 安全性:通过限制暴露面和减少依赖的工具数量,使我们的供应链更安全

值得关注的修复

  • 226401 fileWatcher 持续占用 200%+ 的 CPU
  • 10054 [WSL]:当 localhostForwarding = false 时,端口选项卡错误地报告 WSL 中的端口已转发到本地

感谢

最后但同样重要的一点,向 VS Code 的贡献者们致以最诚挚的**感谢**。

问题跟踪

对问题跟踪的贡献

Pull Requests

vscode 的贡献

vscode-docs 的贡献

vscode-extension-samples 的贡献

vscode-js-debug 的贡献

vscode-jupyter 的贡献

vscode-languageserver-node 的贡献

vscode-pull-request-github 的贡献

vscode-python-debugger 的贡献

vscode-vsce 的贡献

vscode-wasm 的贡献

language-server-protocol 的贡献