Expose getOutputJavaScriptFileName from tsbuild

[andrewbranch]

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?

[andrewbranch]

Given the labels and milestone, I'll go ahead and start a PR 🙂

When you get a chance, I appended a question to the end of the issue that might have been missed:

Since the function will become public, should there be a unit test added for it, or does coverage by existing tsbuild tests suffice?

[ajafff]

it would make sense also to export getOutputDeclarationFileName and possibly getOutputFileNames

I need those functions to exclude outputs of referenced projects from linting.

[benmccann]

getOutputFileNames is currently exposed, but does not seem to work properly. It causes issues in the Rollup plugin, which tries to use it (rollup/plugins#287 (comment), rollup/plugins#287 (comment))

[RyanCavanaugh]

@benmccann can you please log a separate issue with steps to reproduce, and we can take a look? Thanks!

[andrewbranch]

FWIW the original motivation of this issue is no longer relevant, as other new APIs handled project references support in ts-loader more holistically. I think it would be ok to close this.