Ts-loader: idea: splitting typechecking and transpilation

Created on 5 Dec 2016  路  4Comments  路  Source: TypeStrong/ts-loader

I'm just mulling ideas for how we could improve the performance of ts-loader; or at least the experience of people using it. One thing that occurs (and I haven't tested this at all) is having ts-loader run itself as 2 child processes with 2 different responsibilities:

  1. run ts-loader in transpileOnly to produce JS output. It's fast; that's the point
  2. run ts-loader in full-fat mode (i.e. non transpileOnly === false). It's slower but is only responsible for reporting errors. Somehow we'd need to tweak this so that nothing was actually emitted since process 1 would be handling that. Not totally sure what a good way to do that would be but I'm sure there is one.

With this approach, the emit would happen pretty quickly. That's the advantage. My feeling is that most of the time when ts-loader is triggered then it's going to be emitting valid code and people will be able to F5 their way to glory. They spend less time waiting for ts-loader to spin. And when there's errors; well they still find out with this approach. In fact they'll find out in pretty much the same amount of time.

Anyway; before I spend time actually experimenting I'd be interested to know if anyone else has any thoughts / comments on this? Is it not actually a good idea for a reason I haven't considered? Entirely possible! Do tell me if so.

cc @jbrantly @HerringtonDarkholme @Strate

@s-panferov - I'm particularly interested in your views; I seem to recall ATL has something like this already? (you may even have mentioned looking at submitting a PR to that end?)

enhancement wontfix

Most helpful comment

@johnnyreilly ATL had exactly this approach in 2.x, but I decided to move away from it because transpileOnly mode isn't really reliable: it can't emit some decorator metadata or const enums (which requires type analysis of the whole project).

I came up with another approach (similar to what tsserver does): just fork TS runtime in a separate process and communicate with it using IPC. After I stabilize this approach in ATL I plan to move it to ts-loader.

All 4 comments

@johnnyreilly ATL had exactly this approach in 2.x, but I decided to move away from it because transpileOnly mode isn't really reliable: it can't emit some decorator metadata or const enums (which requires type analysis of the whole project).

I came up with another approach (similar to what tsserver does): just fork TS runtime in a separate process and communicate with it using IPC. After I stabilize this approach in ATL I plan to move it to ts-loader.

Ah - thanks @s-panferov. I'll hold off for now then!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Closing as stale. Please reopen if you'd like to work on this further.

Was this page helpful?
0 / 5 - 0 ratings