configOverride ignored when build: true

[whamtet]

Current behavior

configOverride ignored when build:true

Expected behavior

configOverride should either work when build:true or the documentation should more clearly explain why not. Happy to submit a PR for either case once this is clarified. You accepted a documentation PR from me the other day.

Steps to reproduce the issue

Clone the below repo. Try running npm start with build in webpack.config.js set to both true and false. When build: false the plugin correctly detects the configOverride and does incremental compilation.

Issue reproduction repository

https://github.com/whamtet/template-ts-webpack

Environment

• fork-ts-checker-webpack-plugin: 7.2.6
• typescript: 4.6.3
• eslint: n/a
• webpack: 5.72.0
• os: OSX 11.6.3 Intel CPU

[piotr-oles]

Hi! 👋🏻 Thanks for the report. There is no explicit logic that disables config overwrite for build: true, but I guess this is probably related to project references 🤔 When you have build: true, it creates multiple typescript projects, each with its own configuration. I think we overwrite only the entry one (but maybe even this doesn't work? I'm not sure how typescript is handling this).
My point is that it's hard to define how configOverwrite should behave in the case where we have multiple tsconfg.json files. Personally, I would expect that this overwrites only the entry config file, but I guess there are some use-cases, where overwriting all config files would be desired behaviour.
What do you think? What behaviour do you expect?

[whamtet]

Probably just leave as is, but clarify the documentation. I do not have multiple project references but I set build: true because I needed to set ‘write-references’ true to get it to spit out the tsBuildInfo caching file, this raises two questions: 1) should I have to set write-references: true to get it to spit out tsBuildInfoFile? 2) does build: true have to be set when write-references is set?

…

On Apr 15, 2022, at 16:44, Piotr Oleś ***@***.***> wrote: Hi! 👋🏻 Thanks for the report. There is no explicit logic that disables config overwrite for build: true, but I guess this is probably related to project references 🤔 When you have build: true, it creates multiple typescript projects, each with its own configuration. I think we overwrite only the entry one (but maybe even this doesn't work? I'm not sure how typescript is handling this). My point is that it's hard to define how configOverwrite should behave in the case where we have multiple tsconfg.json files. Personally, I would expect that this overwrites only the entry config file, but I guess there are some use-cases, where overwriting all config files would be desired behaviour. What do you think? What behaviour do you expect? — Reply to this email directly, view it on GitHub <#734 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOSIPYB6R6BUXO2OG3G7TDVFEM6ZANCNFSM5TPYCRDA>. You are receiving this because you authored the thread.

[whamtet]

Any more thoughts @piotr-oles ? To help solve this issue I need to understand the design intent points 1) and 2) above

[piotr-oles]

should I have to set write-references: true to get it to spit out tsBuildInfoFile?

According to TypeScript docs, it should be possible to spit out tsbuildinfo with incremental: true mode, which does not need build: true. I don't think it's currently supported in the plugin 🤔
There is a separate API to create incremental program, so I'm not sure if WatchProgram supports incremental: true. You can try it out, and see if it's possible to emit .tsbuildinfo without build: true (but with incremental: true in the tsconfig.json). Here is file that contains some interesting conditions regarding .tsbuildinfo emit: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/main/src/typescript/worker/lib/tsbuildinfo.ts
And it looks like we try to emit this in the WatchProgram: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/main/src/typescript/worker/lib/program/watch-program.ts#L54

[wootencl]

I'll mention I'm seeing this in an nx monorepo as well and suspect its for the the reasons mentioned: multi config files/projects throughout the repo. Not a huge deal but figured I'd call it out as another data point.

Aside, it would be nice if it could override a multi project setup but understandably maybe not worth the investment.