Missing support for typescript 4 incremental compilation?

[clawoflight]

Expected Behaviour

Incremental compilation / .tsbuildinfo work as expected.

Actual Behaviour

The setting does not seem to be used: no .tsbuildinfo exists after building.

Steps to Reproduce the Problem

tsconfig.json:

{
	"compilerOptions": {
		"incremental": true,
		"tsBuildInfoFile": "./dist/.tsbuildinfo"
        }
}

[appzuka]

The short answer is that you probably don't want to use the tsc incremental option when you are building a project with webpack and ts-loader.

When you use tsc with the incremental option it compiles all the .ts files to .js files and creates a .tsbuildinfo file. The next time you run tsc it can tell from the .tsbuildinfo file which source files need rebuilding and which do not.

When you build a web project it is webpack which reads the source .ts files and it passes these through ts-loader. ts-loader passes the compiled .js file to webpack, which adds it to the bundle. Only the complete bundle .js file is emitted by webpack, not the individual .js files emitted by ts-loader

In development mode webpack only rebuilds files which need to be rebuilt. Therefore it is already doing what the incremental option does. If you restart webpack, it could not use a .tsbuildinfo file to only rebuild .ts files as necessary because all the .js files from the previous run were not stored on disk.

So in both development and production mode, having a .tsbuildinfo file would not help.

A longer answer is that the incremental option has already been added to ts-loader, but there is no documentation and no examples and people who have used it report that it does not even create the correct output. It is hidden behind the experimentalWatchApi option.

I spent some time looking into it. I was able to identify some issues and I submitted PR1159 and I can now build my projects using the option. However, I see no improvement in build time, which is the whole point of using the option (see discussion in PR1159).

I would love someone to show me how the option is supposed to work and an example of how it can improve performance. Until then, I would advise against enabling the experimentalWatchApi option as a quick solution unless you are prepared to spend time benchmarking how it changes performance, verifying that the output is correct and digging through the ts-loader source code to investigate.

[clawoflight]

Thank you very much for the very detailed response!
It's a bit sad to watch the JS ecosystem slowly rediscover every lesson learned in compiler design in the 80s and 90s though.

[stale]

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.

[clawoflight]

This is still an issue, don't mark it stale!

[appzuka]

Hi @clawoflight, could you explain how you would expect incremental compilation to work if it could be implemented in ts-loader?

In development mode, webpack already implements incremental compilation so there would be no benefit implementing this in ts-loader also.

Development mode is where you really need incremental compilation for fast development cycles. I can imagine huge projects where faster repeat production builds would be good, although if the project is so large it would probably be better to split it down with project references. This would give you incremental compilation as the references would not be rebuilt unless their source changed.

The --build option within tsc creates a build system for the tsc command, but ts-loader only functions within webpack, which is already a build system.

Implementing the incremental build option from tsc in ts-loader would require a fundamental change to the way ts-loader works. You would need to cache all the intermediate js files so that on the repeat build the .tsbuildinfo file could tell whether they need to be recompiled. Well-behaved webpack loaders are expected to process the files they are passed by webpack one at a time and not read directly from disk. ts-loader already reads files directly from disk sometimes but implementing incremental build would take it further away from the desired behaviour. It would break behaviour like loader chaining.

[mortyccp]

I can think of one benefit of having incremental compilation. It is to share the built with tools like ts-jest. For large project it might be a great deal.

[appzuka]

I have not used ts-jest but I use karma-webpack with ts-loader and the incremental compilation works fine. ts-loader can only be used with webpack and webpack already supports incremental compilation so I don't think there is anything to implement in ts-loader here.

[Leedehai]

Hi @appzuka could you add your response (the one on Oct 9, 2020, for example) to ts-loader's README.md? I find it really useful :)

[stale]

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.

[stale]

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