TS compiler swallows a syntax error

[wycats]

http://www.typescriptlang.org/Playground#src=test(%22foo%22%20function()%20%7B%20%7D)%3B

Input: test("foo" function() { });

Output: test("foo", function() { }); (it "fixed" the missing comma)

Expected: an error of some kind

[vladima]

If I open your Playground link I can see the expected error

Command line compiler yields similar results

vladima@vladima-ux31a:~/sources/playground/7602$ cat t.ts
test("foo" function() { });
vladima@vladima-ux31a:~/sources/playground/7602$ ./node_modules/.bin/tsc --version
Version 1.8.9
vladima@vladima-ux31a:~/sources/playground/7602$ ./node_modules/.bin/tsc t.ts
t.ts(1,12): error TS1005: ',' expected.
vladima@vladima-ux31a:~/sources/playground/7602$

[ghost]

But if you wait for few seconds on the page, the right hand output window will show the undesired fixed output which @wycats is referring to.

It turned out the output window tend to fix errors in many other cases and it never shows fatal errors. So this is probably not a real bug per se, but certainly an undesired outcome..

[vladima]

TS compiler does not guarantee correctness of the emit output if errors were reported. If you don't want to emit anything in presence of errors you can use noEmitOnError compiler option.

[dead-claudia]

@vladima Syntax errors resulting in a code emit is surprising, though. It's not like you're dealing with type errors, in which the code may still work, or an external API changed, and you're having to migrate types (the types might not check, but the output still works).

[vladima]

AFAIR initially policy regarding syntax errors was exactly as you've described it. However later we've changed it I think based on user requests, pinging @mhegazy if he remembers more details

[mhegazy]

that is correct. previously syntax errors blocked emit, where as semantic errors did not. Users have found that confusing. we switched to a model where errors, regardless of their source, would not block emit, and added a flag, --noEmitOnError, to allow to disable this behavior.
The current behavior is by design, and the recommendation is to use --noEmitOnError if generating output is not desired if errors occurred.