Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose getOutputJavaScriptFileName from tsbuild #26410

Closed
4 tasks done
andrewbranch opened this issue Aug 13, 2018 · 5 comments
Closed
4 tasks done

Expose getOutputJavaScriptFileName from tsbuild #26410

andrewbranch opened this issue Aug 13, 2018 · 5 comments
Labels
Committed The team has roadmapped this issue Help Wanted You can do this Suggestion An idea for TypeScript
Milestone

Comments

@andrewbranch
Copy link
Member

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?

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Committed The team has roadmapped this issue Help Wanted You can do this labels Aug 13, 2018
@RyanCavanaugh RyanCavanaugh added this to the Community milestone Aug 13, 2018
@andrewbranch
Copy link
Member Author

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
Copy link
Contributor

ajafff commented Aug 28, 2018

it would make sense also to export getOutputDeclarationFileName and possibly getOutputFileNames

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

@benmccann
Copy link
Contributor

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
Copy link
Member

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

@andrewbranch
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Committed The team has roadmapped this issue Help Wanted You can do this Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants