[Public API request] make parseForESLint accept ts.sourceFile

[Quramy]

I want a public API for TypeScript language service plugin ( this is related to #254 (comment) ).

API proposal

Signature

parseForESLintFromSourceFile(
    sourceFile: ts.sourceFile,
    options?: ParserOptions | null,
): ParseForESLintResult

Expected behavior

This new function should works almost the same as parseForESLint. However, the following points are different:

• result.ast should be converted by @typescript-eslint/typescript-estree/src/ast-converter directly.
• result.services.program should be undefined ( I want to skip to call createProgram)

Motivation

I develop a TypeScript language service plugin to integrate tsserver and ESLint, https://github.com/Quramy/typescript-eslint-language-service.

In tsserver, ts.LanguageService does:

• tokenize source text and create an AST node. And the parsing is so fast because of ts.IncrementalParser.
• provide ts.Program ( So ts-estree don't need call createProgram )

Of course, I can provide a language service plugin using only public @typescript-eslint/parser APIs. But they accept only string text. So source code's text would be tokenized twice if using these public APIs. It's so silly.

Now I use some internal APIs ( see https://github.com/Quramy/typescript-eslint-language-service/blob/v1.2.3/src/ast-converter.ts#L187 ) for the above performance reason. But depending on them is too fragile.

Please consider it.

Quramy

[octogonz]

I'm working on a toolchain that invokes the TypeScript compiler and also ESLint. Currently both of these tasks perform the full steps of: load source files, tokenize, parse, and perform semantic analysis. This is an expensive operation, so it's unfortunate to do it twice.

It seems that we could cut the time in half by sharing the ts.program object between the compiler and ESLint.

@Quramy Is that the same thing you are proposing here? (I'm unfamiliar with parseForESLint because currently I'm invoking ESLint directly, which loads the TypeScript parser indirectly.)

[bradzacher]

Happy to accept a PR for both cases!
It's not something we'll actively work on ourselves, as there's little call for it for the majority of the userbase, and we've got our hands full with everything else.

Quramy has built a ts language server plugin to coordinate linting via the language server instance, instead of installing an eslint plugin.

---

For the case of accepting a ts.SourceCode file, you'd essentially be wanting a thin wrapper on top of the conversion logic. I.e. you essentially want a function which does this, without the SourceCode creator:

typescript-eslint/packages/typescript-estree/src/parser.ts

Lines 299 to 309 in 611dff3

	/**
	* Create a ts.SourceFile directly, no ts.Program is needed for a simple
	* parse
	*/
	const ast = createSourceFile(code, extra);
	/**
	* Convert the TypeScript AST to an ESTree-compatible one
	*/
	const { estree } = astConverter(ast, extra, false);
	return estree as AST<T>;

---

For the case of sharing a ts.Program, this is a bit of a larger problem which doesn't really fit into our codebase as well.
Our codebase is built around using ts.createWatchProgram, because it gives us a BuilderProgram, which is internally designed to be more amenable to the "incremental change" use case.

Our code (as of the commits I merged on the weekend) does a lot of manipulation of this program as well (in order to handle the IDE's persistent state usecase).

So you'd probably want something a bit different - a thin wrapper which accepts a set of programs ahead of the lint, and then when asked to parse a file, it iterates over the programs until it finds one that has the file, and then uses the same API above to convert the SourceFile.

[octogonz]

Cool. Should I open a separate issue for my scenario? I might work on this if I get some time.

[bradzacher]

You can if you want - there's no huge need to open a new issue.

[JoshuaKGoldberg]

I'll tackle the original request of making parseForESLint also accept a source file once #5834 is in.

[JoshuaKGoldberg]

#5892 was merged into the v6 branch. This'll be available as part of our upcoming v6 major version! 🚀