Project compiles OK but hangs when --watch is added

[benjaminjackman]

TypeScript Version: 3.0.0-dev.20180616 and 2.9.2

Search Terms: typescript watch --watch hangs stalls slow

Hi I have minimized one of my projects to an example source (which I have attached [1]) that:

1. Compile fine when not using watch mode (takes about 5 seconds to compile on my machine)
2. Hangs the compiler when using watch mode (doesn't complete it's compile).

To compile the example:

1. download the zip and unzip it and enter that directory
2. run yarn install to add the project's deps.
   3a. run yarn tsc-ok for the example where it does compile
   3b. run yarn tsc-bad for the example where it doesn't

BTW: Is there some way for me to tell the compiler to dump out the source files it is processing as it processes them? It would be extremely helpful for tracking this down to the specific issue.

1: Source Code: tsc-watch-hangs.zip

[devuo]

This is potentially related to #25018

[sheetalkamat]

In the attached repro, the declaration emit takes forever (which is used in --w mode to determine set of files to emit). This seems to repro as well on doing tsc --d
@weswigham can you please take a look and see why declaration is taking forever.

[benjaminjackman]

@sheetalkamat If it's not too much trouble to explain (or if there is somewhere you could point me I'd really appreciate it), how were you able to see that? Are you running the compiler in a debugger / are there flags I can enable that dump out compiler phases / the files being processed.

[sheetalkamat]

@benjaminjackman i just ran your code with node tsc.js --inspect-brk --d as i suspected that is what is causing the issue. I paused debugger and it was stuck in declaration emit.

[weswigham]

I'm not sure it's so much as hanging as taking (close to) forever because of the number of types it needs to print structurally with import types (mixin pattern + inferred conditional types = nonlocal aliases for all the things). I cut the sample down in size and it actually completes (after an inordinate amount of time). A telltale sign is the fact that the memory usage doesn't really go up (or it does, but incredibly slowly) - meaning neither stack space nor heap are in heavy overuse (and breaking randomly, you're usually never more than ~5 types into an anonymous type stack, at most). I'm guessing that getModuleSpecifiers results need to be cached when so many inferred types are going to be printed using (the same) specifiers, since to do its calculation it needs to traverse the program's files/the filesystem, which is rather expensive to be repeating.

[weswigham]

While caching is probably still a good idea, given how often I was breaking into that code, on further inspection that isn't the root problem, sadly - just an aggravating factor. T.T

[weswigham]

If you wait for them (which is actually faster with specifier caching, though still a few minutes at least), the types for that project look like, for example:

If I may be so bold: Thems some large types. 1300 lines for one type argument.

[weswigham]

Most of it is repeitions of the same structural type, unfortunately:

{
        good: import("h-mst/src/BetterMobxStateTreeTs").ModelReferenceFactory<string | number, import("h-mst/src/BetterMobxStateTreeTs").ModelInstanceForAllIn<{
            id: import("h-mst/src/BetterMobxStateTreeTs").IndentifierFactory<string>;
            color: string;
            tags: import("h-mst/src/BetterMobxStateTreeTs").OptionalFactory<string[] | import("mobx/lib/types/observablearray").IObservableArray<string>, string[], import("mobx/lib/types/observablearray").IObservableArray<string> & import("h-mst/src/BetterMobxStateTreeTs").IToJson<string> & import("h-mst/src/BetterMobxStateTreeTs").IStateTreeNode>;
            transient: import("h-mst/src/BetterMobxStateTreeTs").OptionalFactory<boolean, boolean, boolean>;
        }> & import("h-mst/src/BetterMobxStateTreeTs").IToJson<import("h-mst/src/BetterMobxStateTreeTs").ModelSnapshotForAllIn<{
            id: import("h-mst/src/BetterMobxStateTreeTs").IndentifierFactory<string>;
            color: string;
            tags: import("h-mst/src/BetterMobxStateTreeTs").OptionalFactory<string[] | import("mobx/lib/types/observablearray").IObservableArray<string>, string[], import("mobx/lib/types/observablearray").IObservableArray<string> & import("h-mst/src/BetterMobxStateTreeTs").IToJson<string> & import("h-mst/src/BetterMobxStateTreeTs").IStateTreeNode>;
            transient: import("h-mst/src/BetterMobxStateTreeTs").OptionalFactory<boolean, boolean, boolean>;
        }>> & import("h-mst/src/BetterMobxStateTreeTs").IStateTreeNode & {
            readonly abbrev: string;
            readonly isFood: boolean;
        }>;
        amount: import("h-mst/src/BetterMobxStateTreeTs").NumberFactory;
    }

@benjaminjackman is there some kind of alias we should be striving to use instead of these verbose structural decompositions?