No emit in VS with semantic errors

[danquirk]

We're currently passing --noEmitOnError to tsc in VS so we've broken our basic behavior of emitting in the presence of type errors.

1.4 shipped like this.

[nycdotnet]

Check with @RyanCavanaugh as I seem to recall him saying this was intentional.

[DickvdBrink]

I believe it was intentional too, it had something to do with incremental builds if I recall correctly.

[RyanCavanaugh]

We shouldn't be emitting when there are syntax errors, but we should definitely emit if there are only type errors.

I've said a lot of things so I can't definitely say that I haven't said otherwise in the past 😞. Maybe someone can find a link.

[nycdotnet]

I looked back for it and I couldn't find Ryan saying this, so forgive me - I thought I remembered it.

I did find @mhegazy saying that this was intentional, though, and his explanation to me is explained here in the second paragraph:

#1712 (comment)

Thanks.

[mhegazy]

yes. this is an intentional change to allow MSBuild incremental build to work correctly. if you do not like this behavior you can opt out by setting MSBuild property in your project file:

<PropertyGroup>
    <TypeScriptNoEmitOnError>false</TypeScriptNoEmitOnError>
</PropertyGroup>

[danquirk]

We're gonna need to talk about this, particularly in concert with #1712. Emit despite type errors has been a core value prop from day 1 and changing the default to be otherwise is a significant design change.

[rwyborn]

This is not a bug, --noEmitOnError should definitely be enabled by default imo. Without it here is what happens:

• I make edits or sync changes to a bunch of .ts files, saving files as I go.
• As each file is saved, files with errors still generate a .js file and update its last modified time stamp.
• Once all my changes are done, I do a Build. Despite the fact that I have multiple files with errors in them the build reports as succeeded, with no errors reported.
• (No errors are reported because tsc checks the last modified time stamp and concludes the files are already OK and up to date)

Thus the only way to guarantee that I see all current errors in a larger many-file project is to always do a clean/rebuild.

When you scale this up to say a large scale ASP.NET projects with hundreds of files and multiple team members, having to always do clean/rebuild just becomes nonsensical. The whole point of typescript is to reliably catch errors during the build phase.

[danquirk]

The bad behavior here seems like an artifact of the fact that the compiler has multiple error codes to indicate its level of success/failure (emit, emitted with errors, etc), but then on build we don't check that to the same fidelity (only checking whether or not the JS is there). If the compiler saw the file was 'up to date' but was also aware that the last time it was emitted included errors then it could re-compile it again in the same way it does today if --noEmitOnError had been on and that JS file didn't exist.

[rwyborn]

I agree that in an ideal world the compiler would know if the last emit included errors and then re-compile. However now you are talking about caching compile error state somewhere, which adds a lot of complexity and edge cases to the .

If we look at the precedent set by all the other major compiled languages (C#, C++ etc), the behavior is always that there is no emit on any error. This keeps the compiler dirty state check simple (timestamp compare) and overall makes for a more robust compiler... even if it does exclude some partial error cases that would otherwise be nice to support.