microsoft
/
vscode-docs
зеркало из https://github.com/microsoft/vscode-docs.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
vscode-docs/release-notes/v1_49.md

31 KiB
Исходник Ответственный История

Order TOCTitle PageTitle MetaDescription MetaSocialImage Date DownloadVersion
58 August 2020 Visual Studio Code August 2020 Learn what is new in the Visual Studio Code August 2020 Release (1.49) 1_49/release-highlights.png 2020-9-12 1.49.0

August 2020 (version 1.49)

Welcome to the Insiders build. These are the preliminary notes for the August 1.49 release of Visual Studio Code. As we get closer to the release date, you'll find details below about new features and important fixes.

Until the August milestone release notes are available, you can still track our progress:

We really appreciate people trying our new features as soon as they are ready, so check back here often and learn what's new.

If you find issues or have suggestions, you can enter them in the VS Code repository on GitHub.

Editor

Only format modified text

When contributing to another project, the Format on Save and Format Document commands can cause unwanted updates because they format lines that you have not changed. This behavior can result in large pull requests, which are hard to review and touch code you didn't intend to modify. There is now a new feature to help limited unwanted changes:

  • We added a new command Format Modified Lines, which allows you to only format new and changes lines.
  • There is a new setting editor.formatOnSaveMode, which makes Format on Save only apply to modified lines.

Note that modifications are defined by your source control provider, for example, changes as detected by Git, and that without changes in source control, no modified lines are formatted. The Quick Diff indicator is a reliable hint for what lines will be formatted.

Format only modified text

This also requires that the active formatter supports to formatting only a portion of a document, which most popular formatters do.

Format multiple selections

The Format Selection command is now multi-cursor aware. Select multiple lines or statements, trigger Format Selection, and formatting will be applied to all sections.

Find cursor move on type

When typing in the Find input box, VS Code automatically searches and moves the cursor to the nearest find result. You can now control if the cursor should jump to the find matches while typing by configuring editor.find.cursorMoveOnType. When disabled, VS Code will only move the cursor when you press Enter/Shift+Enter.

Disable editor.find.cursorMoveOnType

Workbench

Screencast mode keyboard indicator timeout

The new screencastMode.keyboardOverlayTimeout setting allows you to customize the time in milliseconds for the keyboard indicator.

Screencast mode mouse indicator color and size

The new screencastMode.mouseIndicatorColor and screencastMode.mouseIndicatorSize settings control the mouse indicator color and size.

Debugging

Debug Console filter

The Debug Console now supports filtering, making it easier for users to find the output they are looking for or to hide irrelevant logging output. The filter also supports exclude patterns (for example, patterns starting with an exclamation mark !). The filter only applies to program output but not to evaluations run by a user. Like other input boxes in VS Code, you can use the up and down arrow keys to navigate between old filter inputs.

Debug Consolde filtering

UX improvements

  • When debugging multiple sessions, VS Code now only renders the arrow in the glyph margin for the focused session. This should make it easier for users to distinguish which editor Call Stack decoration belongs to the debug session the user is interested in.

  • Large stack frames now show a Load All Stack Frames button to load all the remaining stack frames. Previously this was a Load More Stack Frames button, which would require multiple clicks for large stack traces.

    Load All Frames

JavaScript debugger improvements

Improved Auto-Attach

Auto Attach can now debug processes even without manually passing an --inspect flag to them. When Auto Attach is turned on, by default VS Code uses its "smart" mode to debug any Node.js script outside of node_modules folders, as well as some common 'runner' tools such as mocha and ts-node.

Image showing VS Code debugging a Node.js process launched from a terminal without an "--inspect" flag Theme: Codesong Theme

You can switch back to the old behavior, or choose to debug all Node.js scripts, using the debug.javascript.autoAttachFilter setting. If you want to change when the "smart" mode attaches, you can configure it in the debug.javascript.autoAttachSmartPattern setting.

As part of this, Auto Attach also now works with terminal multiplexers such as tmux, provided they inherit the session's environment variables.

Sourcemap handling in logged errors

Previously, the stack trace when logging a JavaScript error like console.log(error) would show the locations in your compiled code. If sourcemaps are available, VS Code will now process the stack trace to use the source locations. This is useful when debugging web apps that use bundlers like Webpack.

Image shows a beautified stack trace from a React app

Previously, a stack trace like this would have referenced links in the compiled bundle.js file.

Notable improvements

  • Previously, VS Code aggressively cached sourcemaps in a way that interfered with some types of tooling, such as Angular's ng serve and Nest.js nest start --watch. This is now fixed.
  • When working in a remote (SSH, Containers, or WSL), VS Code did not support attaching to browsers already running locally; this is now fixed.
  • You can now choose to stop if a conditional breakpoint throws an error by toggling the debug.javascript.breakOnConditionalError setting.

Contributions to extensions

Notebooks

Improve cell execution order label discoverability

Previously, the cell execute button would take the place of the execution order label when hovering or selecting a cell. This made it impossible to see the execution order label while executing a cell. We have moved it to be below the execute button, aligned with the base of the editor. This should make it easier to find. (In this example, it's the [6]):

cell execution order

Customize cell appearance

We've added two settings that let users customize the cell appearance:

  • notebook.cellToolbarLocation: Whether the toolbar should be shown on the left, the right, or hidden.
  • notebook.showCellStatusBar: Whether or not the cell Status bar should be visible.

Cell Status bar item contributions

It's now possible for extensions to contribute custom items to the cell Status bar, similarly to the VS Code Status bar. These items can be buttons that trigger commands, or plain text items. As an example, our GitHub issues notebook extension now contributes the Open x results command as a Status bar item:

Cell Status bar item

Enhanced text diff editor

In this release, we added a new type of diff editor for viewing changes in notebook documents. Traditional notebooks are stored in JSON format, which is easy to parse but not effective for diffing since most diff algorithms on text files are line-based. To improve this experience, we built an enhanced diff editor, which is aware of the concept of notebook documents and cells to help users quickly identify what cell content or metadata are changed.

Enhanced notebook text diff Theme: GitHub Theme

You can still switch to regular text diff editor temporarily from the editor action tool bar or disable this feature by turning off the setting notebook.diff.enablePreview.

Switch to regular text diff editor

GitHub Pull Requests and Issues

Work continues on the GitHub Pull Requests and Issues extension, which allows you to work on, create, and manage pull requests and issues. Some updates for this release include:

  • Converted pull requests and issues to a multi-repo model to better align with how the build-in Git extension works.

To learn about all the new features and updates, you can see the full changelog for the 0.20.0 release of the extension.

Extension authoring

Terminal link providers

The terminal link provider API is now stable. This API enables language/lint extensions to handle more obscure link formats that are not already supported and even support language-specific behavior.

Take the following Java exception for example:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 9
    at MyProgram.main(MyFile.java:10)

Using terminal link providers, it is now possible to have a link for java.lang.ArrayIndexOutOfBoundsException that goes to API documentation and create links for the symbols MyProgram or main.

The following example implementation creates a link for the first instance of the word "test" on each line:

window.registerTerminalLinkProvider({
    provideTerminalLinks: (context, token) => {
        // Detect the first instance of the word "test" if it exists and linkify it
        const startIndex = (context.line as string).indexOf('test');
        if (startIndex === -1) {
            return [];
        }
        // Return an array of link results, this example only returns a single link
        return [
            {
                startIndex,
                length: 'test'.length,
                tooltip: 'Show a notification',
                // You can return data in this object to access inside handleTerminalLink
                data: 'Example data'
            }
        ];
    },
    handleTerminalLink: (link: any) => {
        vscode.window.showInformationMessage(`Link activated (data = ${link.data})`);
    }
});

Debug extension APIs

  • DebugAdapterNamedPipeServer: VS Code offers three different ways of communication with Debug Adapters: via direct method calls, stdin/stdout, or TCP sockets. In this milestone, we've added a fourth type: via "named pipes". Our debugger sample "Mock Debug" shows how to use the DebugAdapterNamedPipeServer.

  • Changed timing of 'preLaunchTask': Before a debug session starts, the debug configuration's preLaunchTask is now launched in between the resolveDebugConfiguration and the resolveDebugConfigurationWithSubstitutedVariables calls of a DebugConfigurationProvider. Previously, it was launched after both calls. For details, see issue #95162.

  • Access Debug Adapter Protocol Breakpoints: VS Code breakpoints are independent from debug adapters and they exist outside of debug sessions. When a debug session starts, VS Code breakpoints are registered with the debug adapter of the debug session and VS Code receives Debug Adapter Protocol (DAP) breakpoints in return. That means one VS Code breakpoint maps to zero, one, or more DAP breakpoints (depending on the number of concurrently active debug sessions). VS Code maintains a mapping between its breakpoints and corresponding DAP breakpoints. In this milestone, we've added an API for accessing the mapping: the method DebugSession.getDebugProtocolBreakpoint returns a DAP breakpoint for a given VS Code breakpoint.

  • Finalized APIs: Three proposed extension APIs for debugging have been finalized and can now be used in extensions published on the Marketplace:

    • The function vscode.debug.stopDebugging for stopping a single specific or all debug sessions. With this new API, it is no longer necessary to use the less predictable Debug: Stop command (command ID: workbench.action.debug.stop) which only stops the "active" debug session.
    • The noDebug property of DebugSessionOptions controls whether the session about to start should run with or without debugging.
    • The compact property of DebugSessionOptions controls whether the parent of the newly created debug session will be hidden in the CALL STACK view as long as it only has a single child.

Task custom execution variable resolving

The API to resolve variables for custom execution tasks has been finalized. Variables in a custom execution task's definition are resolved and then passed into the task's callback.

export class CustomExecution {
    /**
     * Constructs a CustomExecution task object. The callback will be executed the task is run, at which point the
     * extension should return the Pseudoterminal it will "run in". The task should wait to do further execution until
     * [Pseudoterminal.open](#Pseudoterminal.open) is called. Task cancellation should be handled using
     * [Pseudoterminal.close](#Pseudoterminal.close). When the task is complete fire
     * [Pseudoterminal.onDidClose](#Pseudoterminal.onDidClose).
     * @param process The [Pseudoterminal](#Pseudoterminal) to be used by the task to display output.
     * @param callback The callback that will be called when the task is started by a user.
     */
    constructor(callback: (resolvedDefinition: TaskDefinition) => Thenable<Pseudoterminal>);
}

Task detail

The task detail API, which is used to show additional information about a task in the task Quick Pick, has been finalized. Task Detail

Proposed extension APIs

Every milestone comes with new proposed APIs and extension authors can try them out. As always, we want your feedback. This is what you have to do to try out a proposed API:

  • You must use Insiders because proposed APIs change frequently.
  • You must have this line in the package.json file of your extension: "enableProposedApi": true.
  • Copy the latest version of the vscode.proposed.d.ts file into your project's source location.

Note that you cannot publish an extension that uses a proposed API. There may be breaking changes in the next release and we never want to break existing extensions.

Contributable context menu for Variables view

We've added command contribution support for the context menu in the Variables view. This makes it possible to implement frequently requested features like variable formatting (e.g. "View as Hex") or viewing variables in custom data views:

java variables context menu

When a registered context menu command is executed, both the underlying variable and its container are passed as Debug Adapter Protocol (DAP) objects. Please note that VS Code's extension API uses opaque stand-in types instead of the real DAP types. In order to access their properties, they can be easily coerced into the corresponding DAP types.

Menu contributions for the Variables view are identified by a "debug/variables/context" key. General information about menu contributions can be found here.

To help with structuring menu commands into meaningful groups, we have added some predefined groups:

  • navigation: Commands related to navigation across VS Code. This group always comes first and is currently empty by default.
  • 1_view: Commands related to displaying variables in different view formats. Currently empty by default.
  • 3_modifications: Commands related to modifications of variables. Currently home of the "Set Value" command.
  • 5_cutcopypaste: Commands related to cutting, copying and pasting of variables. Currently home of the "Copy Value" and "Copy as Expression" commands.
  • z_commands: Other commands that do not belong to the above categories. This group comes last and currently contains the "Add to Watch" and "Break on Value changes" commands.

Typically, menu contributions in the Variables view should only apply to a specific debug type. This can be easily achieved by adding a "when" clause to the contribution. Here is one for Java:

"when": "debugConfigurationType == 'java'"

Since some menu contributions should only be available for variables of a specific kind, we have introduced a new optional context key debugProtocolVariableMenuContext, which receives its value from a property __vscodeVariableMenuContext of the underlying DAP type Variable (please note that the __vscodeVariableMenuContext property is not part of the DAP specification, because it is specific to VS Code and its menu contribution support).

This makes it possible to show an array related menu command only on variables where a property __vscodeVariableMenuContext got a value 'array' from the debug adapter:

  "contributes": {
    "menus": {
      "debug/variables/context": [
        {
          "command": "variables-view.showArrayAsCustomDataView",
          "when": "debugConfigurationType == 'java' &&
                     debugProtocolVariableMenuContext == 'array'"
        }
      ]
    }
  }

Engineering

Web Playground moved to a separate repository

The extension that drives our online web playground, as well as yarn web when running out of sources, has moved into its own repository.

Web Playground support for different versions

Our online web playground is now capable of running not only the latest Insiders version of VS Code, but also the Stable version or any released version by commit.

New query parameters allow to drive this:

  • quality=<stable|insider>
  • commit=<commit-sha>

Note: If you specify a commit, you must also specify it's associated quality.

Minimal sandboxed workbench

We continue to explore enabling Electron's sandbox option in VS Code. During this milestone, we worked on being able to bring up a minimal VS Code instance that is fully sandboxed by shimming various internals that today still require Node.js access. This will be a multi-milestone journey and you can track progress in issue #92164.

Making VS Code Trusted Types compliant

We have started an effort to make VS Code "Trusted Types" compliant. The goal is to prevent DOM-based cross site scripting vulnerabilities. You can learn more about trusted types at the web.dev Trusted Types site and follow our progress in issue #103699.

Notable fixes

  • 38137: Can't call sendText API or paste into terminal with long text
  • 82604: Web: editor does not provide a "Paste" action
  • 101110: Allow to configure workbench.editor.restoreViewState per language
  • 102199: JavaScript debugging: run to cursor can skip to next statement if cursor is after semicolon
  • 103052: Order of files in "Search files by name" results is incorrect
  • 103105: Debug: timeout after 1000 ms
  • 103414: Debug: better support when views are moved out of debug viewlet
  • 105481: macOS: detect high contrast theme

Thank you

Last but certainly not least, a big Thank You to the following people who contributed this month to VS Code:

Contributions to our issue tracking:

Contributions to vscode:

Contributions to vscode-json-languageservice:

  • @KapitanOczywisty
    • Resolve schemas from getMatchingSchemas argument PR #70
    • Resolve refs inside additionalItems PR #69
    • Fix multipleOf with float PR #67
    • Use propertyNames for completion proposals PR #65
    • Add support for defaultSnippets in patternProperties and additionalProperties PR #62

Contributions to vscode-eslint:

Contributions to language-server-protocol:

Contributions to vscode-recipes:

Contributions to vscode-mock-debug:

Contributions to vscode-js-debug: