ts-loader config with transpileOnly: true and experimentalWatchApi: true

[AClimber]

I read the article here: https://webpack.js.org/guides/build-performance/#typescript-loader
and I decided to check performance with transpileOnly: true and experimentalWatchApi: true options.
When I use these options together I don't see that the incremental build TS feature works, because tsconfig.tsbuildinfo file is not generated and build time has the same time like only with transpileOnly

So my questions are:

1. Why tsconfig.tsbuildinfo is not generated when transpileOnly: true and experimentalWatchApi: true?
2. Can I use these options together to get performance profit?

Steps to Reproduce the Problem

I used this project https://github.com/TypeStrong/ts-loader/tree/master/examples/fork-ts-checker-webpack-plugin

the last version of the packages:

"devDependencies": {
    "ts-loader": "7.0.5",
    "typescript": "3.9.3",
    "webpack": "4.43.0",

Case 1: experimentalWatchApi: true

File: tsconfig.json
{
    "compilerOptions": {
          ***
        "incremental": true,
        "tsBuildInfoFile": "./tsconfig.tsbuildinfo"
    }
}

File: webpack.config.production.js

***
module: {
        rules: [
            {
                test: /.tsx?$/,
                use: [
                    { loader: 'ts-loader',
                      options: {
                        experimentalWatchApi: true
                    }
                    }
                ],
            }
        ]
    },

npm run build

Actual Behaviour

Version: webpack 4.43.0
Time: 2691ms
Built at: 05/29/2020 12:00:00 PM
                  Asset       Size  Chunks                    Chunk Names
..\tsconfig.tsbuildinfo   11.6 KiB          [emitted]         
             index.html  532 bytes          [emitted]         
                main.js    289 KiB       0  [emitted]  [big]  main

tsconfig.tsbuildinfo is generated

Expected Behaviour

tsconfig.tsbuildinfo is generated

Case 2: transpileOnly: true and experimentalWatchApi: true

File: tsconfig.json
{
    "compilerOptions": {
          ***
        "incremental": true,
        "tsBuildInfoFile": "./tsconfig.tsbuildinfo"
    }
}

File: webpack.config.production.js

***
module: {
        rules: [
            {
                test: /.tsx?$/,
                use: [
                    { loader: 'ts-loader',
                      options: {
                        transpileOnly: true,
                        experimentalWatchApi: true
                    }
                    }
                ],
            }
        ]
    },

npm run build

Actual Behaviour

Version: webpack 4.43.0
Time: 1888ms
Built at: 05/29/2020 12:03:15 PM
     Asset       Size  Chunks                    Chunk Names
index.html  532 bytes          [emitted]         
   main.js    289 KiB       0  [emitted]  [big]  main

tsconfig.tsbuildinfo is not generated

Expected Behaviour

tsconfig.tsbuildinfo is generated

[johnnyreilly]

Why tsconfig.tsbuildinfo is not generated when transpileOnly: true and experimentalWatchApi: true?

transpileOnly: true does not support tsconfig.tsbuildinfo. That's the behaviour of tsc. You could try transpileOnly: false

[AClimber]

@johnnyreilly thank for your answer.
Do I understand correctly that I cannot use the incremental build TS feature when transpileOnly is true?
Or this feature works, but tsconfig.tsbuildinfo is not generated?

[johnnyreilly]

Or this feature works, but tsconfig.tsbuildinfo is not generated?

I believe it is this

[appzuka]

Looking through the ts-loader code I can see that the experimentalWatchApi option is used to select the watch api of TypeScript:

ts-loader/src/instances.ts

Line 321 in cb487e4

if (instance.loaderOptions.experimentalWatchApi) {

However, if transpileOnly is true the code above is never executed:

ts-loader/src/instances.ts

Line 292 in cb487e4

if (instance.loaderOptions.transpileOnly) {

So it seems to me that transpileOnly and experimentalWatchApi are mutually exclusive. This also seems to make sense as, if I understand correctly, experimentalWatchApi should speed up compile time by only transpiling files which have been changed. But transpileOnly speeds up even more by only transpiling the single file it is given. So by specifying transpileOnly you are directing the compiler to transpile only one file; watching for other changes as well would make no sense.

This comment from @sheetalkamat seems to confirm that with transpileOnly there will be no tsbuild info file, which I assume means the new watch api is not used.

#999 (comment)

So it is unfortunate that the webpack documentation indicates that you can use both together:

https://webpack.js.org/guides/build-performance/#typescript-loader

Searching on Github I see many people have copied this configuration hoping that it will give a speed boost. Some are then trying experimentalWatchApi on its own and experiencing problems. From several issues that have been raised it seems that experimentalWatchApi is not yet ready for production.

If my understanding is correct I'll submit a PR to update the webpack documentation to show that transpileOnly+ForkTsCheckerWebpackPlugin is the current way to boost speed and remove the reference to experimentalWatchApi.

[johnnyreilly]

So it is unfortunate that the webpack documentation indicates that you can use both together:

https://webpack.js.org/guides/build-performance/#typescript-loader

Gosh I didn't know that was the case!

From several issues that have been raised it seems that experimentalWatchApi is not yet ready for production.

Yes, I'd always intended it to become the default way to use ts-loader. Due to the various issues people raised that never happened. And I've never found the time to look into it in depth.

If you were looking for something to get your teeth into @appzuka, then it's worth considering having a go at seeing if you could get the experimentalWatchApi closer to Production ready.

Obviously, you don't have to do this at all! But if you were after a challenge then this could be that. 😎

[appzuka]

Is there a repo to show how experimentalWatchApi should be used? I understand how --build and --incremental work with tsc, but I'm struggling to see how this works with ts-loader. When you run tsc --build you get all the ts files transpiled to js files in the outDir. When you run again with --incremental tsc is able to only re-build files which need to be rebuilt because it knows which files have changed by looking in .tsbuildinfo.

But under webpack, the intermediate js files are not saved. ts-loader transpiles them to js files and tells webpack to add them to the bundle. Webpack produces one or more bundles, but it does not save the js files. So when you run webpack again it still needs to re-transpile all ts files, even if .tsbuildinfo indicates the ts files have not changed. I feel I must be missing something and will continue to dig into the code.

I tried it with watch mode using webpack-dev-server and it did work, with some caveats. The first compilation worked but when I changed a ts file for the first time it did not update the bundle. It did work on subsequent updates. I have a minimal repo and am investigating why this happens. If I can understand how this should work and get it reliable I'll submit a PR and some documentation.

[johnnyreilly]

Is there a repo to show how experimentalWatchApi should be used?

There isn't - but really just imagine taking the vanilla example and switching on that option. It should, theoretically, work exactly the same as with it off but just be faster in watch mode.

https://github.com/TypeStrong/ts-loader/tree/master/examples/vanilla

You could also take a look at ts-loader's sister project:

https://github.com/TypeStrong/fork-ts-checker-webpack-plugin

Which I believe uses the same API internally (not certain 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.

[stale]

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