现已推出!阅读有关 10 月的新功能和修复。

2024 年 9 月(版本 1.94)

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

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

下载:Windows:x64 Arm64 | Mac:通用 英特尔 | Linux:deb rpm tarball Arm snap


欢迎使用 2024 年 9 月发布的 Visual Studio Code。此版本包含许多更新,我们希望您会喜欢它们,其中一些关键亮点包括

如果您想在线阅读这些发布说明,请访问 更新,网址为 code.visualstudio.com内部人员:希望尽快尝试新功能?您可以下载 nightly 内部人员 版本,并在新功能可用后立即尝试最新更新。

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.

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

拖放文件以添加聊天上下文

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

历史记录中包含的文件附件

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

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

Python 原生 REPL 中的内联聊天和补全

Python 扩展使用的原生 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.

选择任何这些选项都会将您带到一个快速选择器,您可以在其中更改扩展使用的帐户。

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.

历史项操作

在本里程碑中,我们扩展了源代码管理历史项的上下文菜单中可用的操作列表。 我们添加了操作,用于从历史项创建新的分支/标签,挑选历史项以及检出(分离)项。

Context menu for items in the Source Control Graph view.

源代码管理图表设置

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

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

笔记本

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

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

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

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

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

折叠差异视图中未更改的区域

笔记本差异视图现在尊重设置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 5.6 版本的所有信息 在 TypeScript 博客上。我们还在以下部分中包含了一些工具亮点。

检测一些常见的“始终为真”的编程错误

假设您在 JavaScript 或 TypeScript 中使用正则表达式并编写如下代码

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

糟糕!看起来我们忘记了在正则表达式上调用 .test(),这意味着 if 条件总是计算为真。这不是我们想要的。

尽管指出这个问题很明显,但这类错误令人惊讶地容易犯,甚至会导致 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 或 远程隧道 连接到远程计算机,或者使用 Windows 子系统 Linux (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 代码中问题的跟踪,并提供了更多上下文反馈。要集成它,请在 task.json 中的 task 中添加 "problemMatcher": "$python"。问题匹配器会扫描 task 的输出以查找错误和警告,并将它们显示在“问题”面板中,从而增强您的开发工作流程。

以下是如何在 task.json 文件中使用 Python 的默认问题匹配器的示例

{
  "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 拉取请求

GitHub 拉取请求 扩展已经取得了更多进展,它允许您处理、创建和管理拉取请求和问题。查看 0.98.0 版本的变更日志 以了解亮点。

扩展创作

删除桌面应用程序中的自定义分配器

在此版本中,我们删除了在 1.78 版本中添加到桌面应用程序扩展宿主中的自定义分配器。此自定义分配器充当桥梁,用于支持针对 Electron 运行时构建的与 V8 沙箱不兼容的 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 的稳定版本中,你可以通过 github.experimental.multipleAccounts 设置开启。

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

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

要使用此功能,只需触发登录操作(无论是使用内置功能(如设置同步)还是使用扩展),你将可以选择登录到另一个帐户。此功能与新的 帐户偏好快速选择 配合使用,如果你需要在以后更改帐户,则可以使用此功能。

虽然大多数事情应该继续使用你现有的扩展正常运行,但有些行为可能尚未与这个多帐户世界完美兼容。如果你认为有改进的空间,请在这些扩展中打开一个问题。借助相对较新的 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 中查看此向 MSAL 的过渡在所有 VS Code 中的详细状态。

TypeScript 5.7

此版本包含对即将发布的 TypeScript 5.7 版本的初始支持。查看 TypeScript 5.7 计划 以了解详细信息。

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

建议的 API

语言模型工具

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

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

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

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

查看 问题 #213274 以获取更多详细信息或提供反馈。

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

工程

ESM 正式发布在 VS Code 中

我们终于在 VS Code 的稳定版本中发布了我们的 ESM 工作。这意味着 VS Code 核心(electron、node.js、浏览器、worker)的所有层都使用 JavaScript 中的 importexport 语法进行模块加载和导出。我们所有对传统 AMD 加载器的使用都已禁用,并将作为我们 10 月份的“偿债周”的一部分被删除。

迁移到 ESM 极大地提高了启动性能。一方面,删除了许多 AMD 开销,另一方面,主工作区捆绑包大小也减少了 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 月初开始,我们已经完成了 从 yarn 切换到 npm,以在 microsoft/vscode 存储库中进行包管理。这个决定是基于 VS Code 的具体需求,并围绕以下标准进行:

  • 性能:我们最初迁移到 yarn 是出于性能方面的考虑,而 npm 现在也可以满足我们的需求。
  • 安全性:我们通过限制暴露并减少我们依赖的工具数量来提高供应链的安全性。

值得注意的修复

  • 226401 fileWatcher 持续以 200% 以上的 CPU 使用率运行
  • 10054 [WSL]:端口选项卡错误地报告在 WSL 中的端口被转发到本地,即使 localhostForwarding = false

感谢

最后但并非最不重要的是,衷心感谢 VS Code 的贡献者。

问题跟踪

对我们的问题跟踪的贡献

拉取请求

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` 的贡献