ts-node "compiles" all TypeScript files upon boot up

[alexgorbatchev]

I'm using ts-node to get gulpfile.ts to work and it appears that ts-node compiles all TypeScript files when gulp starts. If I have errors in clientside files that aren't required anywhere in the gulpfile.ts file, gulp still fails to start because ts-node fails with TypeScript errors.

I have my clientside files linked in tsconfig.json, which might be causing this side effect. I'm worried that eventually when the project gets larger it will become a real problem because ts-node will unnecessarily compile all TypeScript files.

[blakeembrey]

You're definitely correct and I was thinking about this after you logged it. We need to load all the files by default, since there could be type information in the files array. However, it should be possible to filter those to only .d.ts files for the initial load. Interestingly, this is actually going to be an issue with all current tooling - including Webpack loaders, Browserify plugins, etc. that don't implement this.

Awesome point 👍 Do you have any thoughts on filtering the results for only .d.ts to start?

[alexgorbatchev]

I don't have enough background here to understand why it's necessary? I imagined that ts-node is a pretty thin shell on top of TypeScript.

[blakeembrey]

For interested parties: I'm using the TypeScript language services which requires entry points and definition files on load (E.g. to declare modules, etc). However, since this isn't tsc and we have the entry points, we only need the definition files known upfront.

I'll be implementing a patch for this tonight in any case, but if someone has a better approach please chime in 😄 Otherwise I'll be implementing a flag in tsconfig for definition files only. Then I'll keep the same code about (but I need to switch to using ts.getPreEmitDiagnostics). It may be possible to switch to using a program instance, but the REPL relies on a lot of the language service specifics to function.

The issue from #13 was that when noEmitOnError is enabled, you won't get any diagnostics unless you explicitly check for them. There's a code path that just emits skipped. Anyway, that's a brain dump for anyone listening - I'll patch this tonight.

[alexgorbatchev]

Thanks for the explanation! Is it possible to separate how REPL and /register work and would that make /register lighter?

[blakeembrey]

Most of the code would end up identical in either case, so it's not a huge change. I'd be able to wrap either API internally depending on whether we're using the REPL interface too. It is probably lighter, just how much I haven't tested.

@basarat Do you have any idea how much lighter using only the program interface over the language services would be?

@alexgorbatchev There's a lot of other things to consider with a change like that. For example, when someone invalids the node require cache this would require restarting a new program instance which would be much slower and would result in potentially different state/errors. These are all probably reasonable trade-offs though, but I'd love to solve it better, not just differently.

[basarat]

Do you have any idea how much lighter using only the program interface over the language services would be?

Not a significant difference at all. Language Service is mostly a program snapshotting tool (so it just passes it down to program if code doesn't change). In fact most calls to Language service are like syncHostData -> getProgram -> call function on program. Hope that helps 🌹

[blakeembrey]

Released with v0.4.0. Please let me know how well it works for you 👍 I'm opening anew issues for the program replacement.

[alexgorbatchev]

very cool, thank you very much!