ts-node "compiles" all TypeScript files upon boot up about ts-node HOT 8 CLOSED

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?

from ts-node.

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.

from ts-node.

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.

from ts-node.

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

from ts-node.

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.

from ts-node.

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 🌹

from ts-node.

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

from ts-node.

very cool, thank you very much!

from ts-node.