Repository navigation
[transform API]: Allow passing getEmitResolver into TransformationContext and expose getEmitResolver from Program #46793
Description
Suggestion
🔍 Search Terms
- getEmitResolver
- transform API
✅ Viability Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
⭐ Suggestion
transform API is quite nice and convenient because using this API doesn't need to invoke Program to compile ts to js to use custom AST transformers. However, it doesn't allow the case which requires to access to EmitResolver. It would be nice if transform API can allow users to pass getEmitResolver into the TransformationContext.
Currently, getEmitResolver isn't exposed for both TransformationContext as well as Program interfaces.
📃 Motivating Example
An ideal example would be like this
export function constructorParametersDownlevelTransform(program: ts.Program): ts.TransformerFactory<ts.SourceFile> {
const typeChecker = program.getTypeChecker();
const reflectionHost = new TypeScriptReflectionHost(typeChecker);
return (ctx: ts.TransformationContext) => {
return getDownlevelDecoratorsTransform(
typeChecker,
reflectionHost,
[],
false,
false,
true,
)({
...ctx,
getEmitResolver: ctx.getEmitResolver()
? ctx.getEmitResolver
: program.getDiagnosticsProducingTypeChecker().getEmitResolver,
});
};
}
💻 Use Cases
I am trying to experiment the idea:
-
Use
transformAPI to process AST of TypeScript source codes with some custom AST transformers. -
Use
swcoresbuildto compiletstojswith the newly transformed source.
As far as I can tell, process AST with transform API is pretty fast. If I can process AST without using Program to do the full compilation step but use swc or esbuild to compile, that would help me to achieve the goal that: fast compilation + source is processed in such a way I want (Jest hoisting, Angular downlevel constructor etc...)
Activity
andrewbranch commentedon Nov 12, 2021
Ron Buckton (@rbuckton) for thoughts?
frigus02 commentedon Jan 12, 2023
At Google we would also benefit from having the
EmitResolveravailable in transformers. Use cases:To improve edit/refresh performance during development we would like to transpile TS to JS without type checking. Ideally we would do that using
ts.transpileModule(). We still have to do some transforms, though, and for 2 cases we don't see a way to do them without type checker or emit resolver:.defaultaccesses on imports, we need to find the import declaration for a given identifier. (code).EmitResolver#getReferencedImportDeclarationwould help here.EmitResolver#isReferencedAliasDeclarationwould help here.Ron Buckton (@rbuckton), would you consider making
EmitResolverand some of its methods public?timocov commentedon Dec 27, 2023
Having exposed program's
EmitResolverwould benefit tools likedts-bundle-generatoror@microsoft/api-extractoras well - in their case we need to perform a name collision resolution while generating new nodes or updating existing ones and try to preserve user's input as much as possible. Without exposing either program'sEmitResolverorglobalThissymbol it would be quite problematic or even impossible.FYI
@microsoft/api-extractoris using an internal method already to getEmitResolverin order to usehasGlobalNameto perform described check.Andrew Branch (@andrewbranch) Ron Buckton (@rbuckton) do you have any concerns re exposing it to public?
rbuckton commentedon Jan 2, 2024
EmitResolveris primarily an emit-focused wrapper forTypeChecker. You can almost always get the same information from the checker directly, and if you're using our API to run custom transformers, you would already have access to the checker. I'd be more interested as to whether there is missing functionality that we should be exposing onTypeCheckerinstead. For example, rather than makingEmitResolverpublic just to accesshasGlobalName, we could instead exposeTypeChecker's existingresolveNamemethod for the same functionality, i.e.:checker.resolveName(name, /*location*/ undefined, SymbolFlags.All, /*excludeGlobals*/ false).timocov commentedon Jan 2, 2024
Ron Buckton (@rbuckton) this makes sense, thanks! For this particular use-case, can I create a PR with opening this API?