Per the recent incidents (microsoft/vscode#69656), I think it's a good opportunity for us to split vscode node modules into 2 pieces:

• @types/vscode
• vscode-test

Explanation

vscode node module contains 3 scripts:

• compile: no longer used
• install: used to fetch vscode.d.ts according to engine.vscode in package.json
• test: used for extension test (also lib/testRunner)

Problems

• install asks update server for finding matching vscode.d.ts version (actual dts files fetched from GitHub). When update service is down, all extension deps install (CI or local development) could fail.
• yarn install and npm install can't be completed offline, even if they have caching: Add Switch for Offline Installation #93
• test depends on a lot of node modules (13MB). Everyone has to download them even if they just want to use the API.
• test needs some improvements. For example, for running extension tests against multiple workspaces, I had to pull out the test scripts and modify them manually Vetur. Also add flag / env var to enable downloading and unzipping to .vscode-test without running tests... #124, people want functionalities exposed from test so they can build upon them.

Benefits of splitting vscode into @types/vscode and vscode-test

• No awkward postinstall scripts after each npm install for extension
• Users don't have to pull in the 11MB dependencies of test. They pull a few kb of vscode.d.ts from @types/vscode, and it's fully cached by npm/yarn.
• vscode.d.ts are hosted on NPM which is pretty reliable. d.ts live in a @types package as they should be.
• test now lives in its own repo. It's easier to make improvements, release new versions, expose functionalities (for example, import { downloadVSCodeExecutable } from vscode-test).

Challenges

We can't put all versions of vscode.d.ts into @types/vscode and let TS infer which one, from engines.vscode.

However I think we can publish vscode.d.ts the same version as we do for VS Code, since all our 1.x API are backwards compatible. Most users also auto-update to latest version, so extension authors could use "@types/vscode": "^1.31.0" and safely get minor updates.

/cc @Microsoft/vscode for thoughts.