Explore running the TypeScript Playground as a vscode extension inside vscode.dev

[orta]

Take the concept of the playground, and remove our custom UI - have that run inside vscode.dev.

Proof of concept: https://github.com/orta/vscode-typescript-playground

[orta]

VSCode Powered Playgrounds Roadmap

The above proof of concept has been hooked up fully to vscode.dev now, and we've taken a step back to figure out how this can work structurally.

Today, the playground has its own copy of the TypeScript compiler API which is used to generate things like the .js, .d.ts, grab errors etc, it is used for introspection in the docs. We extract this TS version from Monaco's globals and pass it around to other tools.

We wonder if instead of the playground having a full copy of the typescript compiler, it instead sets up and makes requests to the tsserver provided by the default vscode typescript extension. Leaving the playground to effectively be a smart wrapper around the existing tsserver, with useful introspection tooling in the extension.

This solution has this nice balance of the TS team controlling the tsserver side (so TS can add extra tsserver commands for introspection when needed ) and the vscode team mostly focusing on the IDE side with a fully fleshed out vfs for testing stuff in provided by ts playground extension.

To make that work, we'd need a few things:

• The extension running on vscode.dev - https://github.com/microsoft/vscode-dev/pull/468
• The full language sever on vscode.dev serverless - [Discussion] Enable reading workspace contents on GitHub.dev TypeScript#46421
• A way to set the TS version to a https url - Allow loading custom typescript.tsdk settings on web hosts vscode#138211
• A way to make requests to the tsserver from typescript - Allow extensions to be able to make requests to the typescript extension's tsserver via commands  vscode#138279

This leaves a few holes where the ts API was used (e.g. the compiler UI dropdown) but that's solvable by knowing the TS version and knowing when a flag was added and pre-baking this info into the extension probably, and/or we add a tsservice command for info about the compiler's settings.

Examples

All of the code samples are available in JSON dumps by the TS website: https://www.typescriptlang.org/js/examples/en.json / https://www.typescriptlang.org/js/examples/ja.json - the playground just needs to ask for the hosted file: https://www.typescriptlang.org/js/examples/en/3-7/Syntax%20and%20Messaging/Flattened%20Error%20Reporting.ts

Running Code

vscode has a lot of security tooling set up in the JS environment which makes it hard to arbitrarily execute the user's JS, perhaps the debugging extension gives us a route for that. If not we can run it in a webworker, but capturing logs might get complicated then.

TS Version Support

Because we're looking at relying on the vscode side to handle the IDE integration, in theory we can only use versions which include this PR: microsoft/TypeScript#39656 ( 4.3+ ) out of the box. To handle backwards compat we can make builds of older versions of TypeScript which have this PR in user-land code to replicate the same behavior and put it in our CDN.

[orta]

microsoft/vscode#138621 would hook up the full tsserver (supporting multifile/ ATA at a bare minimum) to vscode ts playgrounds

[orta]

Confirming that the tsserver requests work well now that it's available in the nightlies. The files in our vfs have paths like ^/playfs/index.tsx, so I can call:

vscode.commands.executeCommand('typescript.tsserverRequest', 'emit-output', { file: "^/playfs/index.tsx" }).then(r => {
    console.log("Got", r)
})

Which would return the .ts and .js files if the TSServer was not in partial mode. microsoft/vscode#138621

[orta]

I've been exploring using the setting UI to showcase the tsconfig vars, this kinda works OK for prototyping:

But once I put in the full tsconfig the lack of subheadings and the single column really started to make it a bit unweidly, I might need to implement a custom settings page

[orta]

The codebase which it runs on is https://github.com/orta/vscode-typescript-playground - but I built out a monorepo for many vscode extensions in https://github.com/microsoft/TypeScript-VSCode-Extensions (for example me/Ron/Andrew branch have TS related extensions). The version on my account is further along than the version in the MS org.

We already have a typescript marketplace account, probably for the VS side, but I've not figured out how I can get access to a write token to be able to deploy with it though, so it's a bit stunted in usage.

I think the next major thing which needs building is for the vscode tsserver extension to use the vscode file system. I have a hunch that the web tsservice doesn't touch any user-land files and probably only gets given a file contents via the openFiles part of the protocol. This would mean that providing a vfs to vscode is not reflected in the tsserver APIs.

[orta]

Been exploring how to get the full server running in vsocde.dev - microsoft/vscode#138621 - right now there's a small change needed in vscode:

export const semanticSupportedSchemes = [
	file,
	untitled,
	walkThroughSnippet,
	vscodeNotebookCell,
];

and then in TS we need to change https://github.com/microsoft/TypeScript/blob/ed014db864165cab3f568eb8e2a0b6ea1ba5f624/src/tsserver/webServer.ts#L47 to be a semantic versions ( microsoft/TypeScript#47401 )

Next to work around the TSSrrver not having access to the vfs files. TSServer currently has all open tabs in memory but nothing else.

[orta]

Made a request about setting the URL from an extension to vscode: https://github.com/microsoft/vscode/issues/140559

[typescript-bot]

Hello! As per #2804, we are automatically closing all open issues. Please see #2804 for a description of what issues and PRs can be accepted going forward.