Async LanguageServiceHost

[zikaari]

Search Terms

language, service, host, async, api

Suggestion

It'd super awesome if Language Service would accept a LanguageServiceHost with async API

Use Cases

Using LanguageService in environments where readFileSync is not available like browsers (using browserfs package or fs provided by WebSockets)

I'm working on an app like CodeSandbox but a bit more sophisticated.

Examples

class Host implements ts.LanguageServiceHost {
  async getScriptSnapshot(filename: string): Promise<ts.IScriptSnapshot> { }
  async readFile(filename: string): Promise<string> {}
}

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[zikaari]

It'd be a delight if there was an abstraction like so:

interface ITypeScriptServiceHost {
  getFile(absPath: string): string | Promise<string>
  listDir(absPath: string): string[] | Promise<string[]>
  watch?(absDirPath: string, cb): { close(): void }
}

class TypeScriptService extends LanguageService {
  constructor(host: ITypeScriptServiceHost) { }

And the above system would take care of resolving paths, finding tsconfig.jsons (root and nested), considering the module resolution algorithm and what not.

[abhishiv]

I would second this as well. Also would be interested to learn how people are dealing with this limitation in the meantime. As I see, that makes it impossible to integrate LanguageServiceHost/CompileHost in an async filesystem.

[kitsonk]

I would be supportive of this too, but of course async at this level means that the whole of the compiler would become async, which would fundamentally change everything. TypeScript still runs in environments where async is not a native language feature, which would also be a challenge. This isn't as simple adding the APIs.

As I see, that makes it impossible to integrate LanguageServiceHost/CompileHost in an async filesystem.

Almost every filesystem is "async" by nature. It is the bindings to the filesystem that block until a request that resolves. All current implementations of the TypeScript compiler accomplish this one way or another.

[kitsonk]

We've been talking about this further in context of Deno. Because we support remote modules, a level a parallelisation of resolving and fetching modules improves performance. At the moment we have to find ways to do this in the privileged side, but present it back to the JavaScript runtime as a synchronous operation. The only solution we have found causes a silly number of threads to be created and destroyed. Having the compiler be able to support some sort of async version, would really help in managing resources.

[oldrich-svec]

@kitsonk You could do that manually by calling ts.preProcessFile(fileContent) on the main file. From that you get typeReferenceDirectives, referencedFiles and importedFiles that you can then use to async download the referenced files. The files can then again be recursivelly analysed with the preProcessFile. At the end, you get a list of all the files needed and their content. That you can then use in LanguageServiceHost.

Alternativelly, I on the client start a worker in which I do the fetching using a synchronous version of xmlhttprequest - then I can use LanguageServiceHost directly.

[kitsonk]

@oldrich-svec oooh... thank you! that is very very handy! 👍

[manuth]

Does anyone of you know a workaround for creating an asynchronous getSemanticDiagnostics?