Discussion: should fixes be allowed to cause type errors for invalid code

[ajafff]

Currently there are only 100% safe fixes (with the exception of outstanding bug reports). That means:

• fixes don't introduce parse errors
• fixes don't alter runtime semantics
• fixes don't introduce type errors

This is about the last bullet point. Some fixes were even removed because they might cause type errors. Related: #160, #248, #186

Should rules be allowed to autofix such cases and cause type errors on the next compilation?
To be honest, the code is faulty anyway. The programmer should be notified there's something wrong.
The code (before and after autofixing) should not be shipped to production without being looked at.

Due to bullet point #2 rules cannot autofix all cases of "duplicate property" or "unreachable code" because that might change runtime semantics.

For posterity: there's also a proposal to introduce potentially unsafe fixes #207

[ajafff]

After revisiting #186 and looking at #248 again, I think it's acceptable for fixes to cause compiler errors as long as it doesn't change runtime behavior.

That means those object spread related fixes are fine because the result is still the same (if you ignore the compiler error).
Autofixing return-never-call (#160) on the other hand is not desired. Although the types say a function never returns, it's not guaranteed to be the case when executed. Therefore fixing this should be a suggestion that needs the developer's action to actually apply.

Other rules such as no-useless-escape proposed in #203 should not be autofixed. Such errors need to be looked at by a human to decide the correct action.