Allow --build with Intermediate Errors - shouldn't happen on tsconfig errors

[Knagis]

🔎 Search Terms

intermediate error

🕗 Version & Regression Information

This is about new feature in 5.6

⏯ Playground Link

-

💻 Code

tsconfig.json

{
    "extends": "../wrong/path/to/some/tsconfig.json",
    "compilerOptions": {
        // nothing, expects to inherit things
    }
}

🙁 Actual behavior

When compiling such project, tsc does complain that it cannot find the base config, however it continues building. This is a big problem when the base config contains important things like "outDir": "${configDir}/lib" - TS will happily build using the defaults, writing a ton of .js and .d.ts files next to the source files.

🙂 Expected behavior

For tsconfig.json file errors, do not continue building the project.

Additional information about the issue

No response

[sheetalkamat]

@DanielRosenwasser we never filtered what type of errors should block the emit. Eg in tsc. Config file can have errors like this option is unknown or these options specified wrong values. That should probably not block build, eg you wrote single quoted string and not double quoted that seems like something that shouldnt block you from building. I think noEmitOnError on project is only setting that allows you to not emit on any kind of error and thats a better fit for this.

[DanielRosenwasser]

@Knagis is there any reason you hit this, or a reason that a git clean -fd <your-source-directory> can't fix this?

[Knagis]

i encountered this during very large refactoring (moved folders for 100 packages in a monorepo). so i am updating paths left and right, fixing some other issues that pop up. unfortunately, some fixes require me to add new files, and in some folders we do have .js files, so they aren't ignored. and .d.ts files definitely aren't ignored.

thus when one project suddenly wrote all those .js and .d.ts files it was a very unexpected problem, git clean was the solution but as i found out later, when cleaning i did delete some files i had added earlier, but not staged/committed.

though there are many ways of running into this with malformed tsconfig files, in my case syntactically everything was correct, i was actually building a dependent project, for which the tsconfig was fixed and everything was green (vscode does show red squigly if the referenced file isn't found). It then unexpectedly pulled in a transient dependency that i hadn't prepared yet fully and that had the old wrong extends value.