-
Notifications
You must be signed in to change notification settings - Fork 520
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
New ts_project rule should have a worker and honor ts --incremental #1726
Comments
Stateful compilers have been discussed with Bazel many times: https://groups.google.com/forum/#!topic/bazel-discuss/3iUy5jxS3S0 As with workers, they run contrary to the reproducibility safeguards of Bazel, but are necessary for high performance for some compilers. For higherkindness/rules_scala, we implemented stateful compilation by having the worker write the state to disk, cached by the target name. (Though fearing non-reproducibility, we made it be opt-in: AFAIK Swift also has incremental compilation. |
I did some research on this yesterday after chatting with @mrmeku about some options.
In practice that seems easy enough to achieve, and it closely models what you would do with plain
Our basic model would be that a
and it then calls
it also needs to prevent writes to stdout, and read stdin to find protos and respond to them in some way, probably using the The second option is like tsc_wrapped or https://github.com/Asana/bazeltsc/blob/master/src/bazeltsc.ts - we can write a custom TS compiler for use in watch mode. We have lots of experience doing this and it's not very hard, but it does mean we have a constrained peerDep on typescript, and will expose us to some extra surface of bugs that you might see under Bazel and can't reproduce with vanilla tsc - and that goes against a design principle of the
I think we'd need users to be aware that every
Right now my understanding of .tsbuildinfo isn't sufficient to feel really confident, but my sense is like @pauldraper says above - we let tsc write the .tsbuildinfo somewhere that it can find on the next execution of that same project, so that the built-in incrementality model still works. I don't remember if tsc also wants to read the .tsbuildinfo from dependent targets, but that's easy enough to pass along on a Provider. I have to set this down again, don't have time to dedicate to it this week. Here are some bits I was playing with to understand it better: master...alexeagle:ts_project_worker |
Some more research and experimentation tonight. My original hope of just reusing Looking more at the minimal TS program we'd have to write as a wrapper, I see that TS introduced a public API for writing such a watcher, so it's better than when we first implemented tsc_wrapped at Google. See https://github.com/microsoft/TypeScript/blob/v3.9.7/src/compiler/watchPublic.ts |
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs! |
Any update? |
Yeah it's documented here We still need feedback to help promote it to a stable API but should be in separate issue(s) |
TypeScript has a mechanism to avoid unneeded work in re-compiles, the
--incremental
flag and.tsbuildinfo
file.We should figure out a way to use these under Bazel to speed up compiles of
ts_project
rules.The text was updated successfully, but these errors were encountered: