@types/vscode for extension usage

[octref]

Update:

New system will:

• For each tag such as 1.34.0 pushed to VS Code
• Generate a new commit is and push to master of https://github.com/microsoft/vscode-DefinitelyTyped
• Endgame master is responsible for sending a PR against DefinitelyTyped/DefinitelyTyped

---

Ref: microsoft/vscode-extension-vscode#147

DefinitelyTyped, question for publishing old versions of types: DefinitelyTyped/DefinitelyTyped#33738

Tracking here for testing later.

Current Problem:

• vscode.d.ts is fetched by running a script, node_modules/vscode/install
• The script depends on update server, so when it's down dependency install for extension fails
• yarn and npm can't fully cache the vscode module

Proposed solution:

• For each release of VS Code, we publish @types/vscode corresponding to the VS Code version. For example VS Code 1.32.0 => @types/vscode@1.32.0
• We seldom have breaking API changes, so most people can roll with "@types/vscode": "^1.32.0" and always get latest API.

VS Code related changes:

Extension authors can use engines.vscode to specify which versions of VS Code their extensions support. With this change, engines.vscode is no long used for fetching corresponding dts files.

I think this is a good change. I want to develop always with latest vscode.d.ts but if I don't use any new API, I can still support older versions. If I want to lock to specific versions of vscode.d.ts I can always use exact version such as "@types/vscode": "1.32.0".

[octref]

We might be able to include proposed dts in @types/vscode too. @jrieken should we do this?

[jrieken]

@jrieken should we do this?

Not sure, not the biggest fan because proposed api changes a lot and proposed api doesn't work with vscode-stable, only insiders. having it out and published might send the wrong mesage

[octref]

@jrieken And I assume we don't publish types for recovery build, such as 1.32.1, correct?

[jrieken]

Yeah, we shouldn't as the API doesn't change

[octref]

We'll publish 1.14 to 1.32 @types/vscode. This has to be done one PR per version.

• Published: 1.14-1.32

Other tracking:

• Update samples https://github.com/Microsoft/vscode-extension-samples
• Update beginner guide https://code.visualstudio.com/api
• Ping TS team to update type registry and add @types/vscode: https://www.npmjs.com/package/types-registry. (This is updated once a week automatically)
• Add wiki for updating vscode.d.ts on DefinitelyTyped.
• Update endgame template to include @types/vscode publishing step.
• Close Add Switch for Offline Installation vscode-extension-vscode#93
• vsce for validating @types/vscode against engines.vscode
• Azure function for publishing nightly/proposed API (maybe use it for automating sending PR to DefinitelyTyped too).
• Move vscode NPM module to point to microsoft/vscode project
• Add script for automating dts publishing https://github.com/Microsoft/vscode/blob/master/scripts/generate-definitelytyped.sh

[octref]

@jrieken I plan to update the extension generator, so the template uses latest engine.vscode and @types/vscode.

Do you feel there's a need for vsce to check that the downloaded vscode.d.ts corresponds to engine.vscode? I can think of cases where author want to specify "fetched dts" and "supported VS Code version" differently, but during today's discussion there are concerns that users would use API only available in newer versions but forget to update engines.vscode.

[jrieken]

Code version" differently, but during today's discussion there are concerns that users would use API only available in newer versions but forget to update engines.vscode.

Yeah, that's something something you get for free today and something we loose with the decoupling work. Yeah, I think adding a check to vsce and also some package.json validation makes sense.