Suggestion

As discussed with @RyanCavanaugh in TypeStrong/ts-loader#815, export the currently internal function getOutputJavaScriptFileName from src/compiler/tsbuild.ts: https://github.com/Microsoft/TypeScript/blob/fe387cc7f0739256337771e62398a565fbcf82c1/src/compiler/tsbuild.ts#L291-L297

For symmetry, maybe it would make sense also to export getOutputDeclarationFileName and possibly getOutputFileNames, but those aren’t needed immediately.

Use Cases

TL;DR: support TypeStrong/ts-loader#815 without duplicating logic from the TS compiler.

When using program.getSourceFile() on a *.ts file that's part of a project reference, the result describes the *.d.ts file built by the composite project (if it’s built). Because there are several compiler options which change where files get emitted (e.g. declarationDir), it’s not quite trivial to figure out where the corresponding *.js file is. In the issue linked above, we need to read that plain JavaScript file into Webpack in order to take advantage of the fact that project references have already been built.

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. new expression-level syntax)

I'm happy to make the accompanying PR if it sounds good to you all. Since the function will become public, should there be a unit test added for it, or does coverage by existing tsbuild tests suffice?