[transform API]: Allow passing `getEmitResolver` into `TransformationContext` and expose `getEmitResolver` from `Program`

[ahnpnl]

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 transform API to process AST of TypeScript source codes with some custom AST transformers.

• Use swc or esbuild to compile ts to js with 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...)

[andrewbranch]

@rbuckton for thoughts?

[frigus02]

At Google we would also benefit from having the EmitResolver available 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:

• To transform user-written .default accesses on imports, we need to find the import declaration for a given identifier. (code). EmitResolver#getReferencedImportDeclaration would help here.
• To transform imports and still elide type-only imports, we need to know if a given identifer was used in a value position. EmitResolver#isReferencedAliasDeclaration would help here.

@rbuckton, would you consider making EmitResolver and some of its methods public?

[timocov]

Having exposed program's EmitResolver would benefit tools like dts-bundle-generator or @microsoft/api-extractor as 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's EmitResolver or globalThis symbol it would be quite problematic or even impossible.

FYI @microsoft/api-extractor is using an internal method already to get EmitResolver in order to use hasGlobalName to perform described check.

@andrewbranch @rbuckton do you have any concerns re exposing it to public?

[rbuckton]

EmitResolver is primarily an emit-focused wrapper for TypeChecker. 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 on TypeChecker instead. For example, rather than making EmitResolver public just to access hasGlobalName, we could instead expose TypeChecker's existing resolveName method for the same functionality, i.e.: checker.resolveName(name, /*location*/ undefined, SymbolFlags.All, /*excludeGlobals*/ false).

[timocov]

we could instead expose TypeChecker's existing resolveName method for the same functionality, i.e.: checker.resolveName(name, /location/ undefined, SymbolFlags.All, /excludeGlobals/ false).

@rbuckton this makes sense, thanks! For this particular use-case, can I create a PR with opening this API?