Ignore specific errors

[basarat]

This keeps getting asked on stackoverflow (just this morning : http://stackoverflow.com/a/39627892/390330) so thought there should be an issue to track it.

Ideation

Lots of linters do this:

• Ignore errors for regions (using inline comments /** */).
• Ignore errors per file (configured using tsconfig or command line)
• Ignore certain error codes (configured using tsconfig or command line)

There needs to be 🚲 🏠 here so have at it 🌹

More

• I had the desire for something like this just for JS file but that went away when we got allowJs: Making JavaScript to TypeScript migration easier : Suppress errors #4094 ❤️
• An issue for tracking JavaScript specific error customization : Enable JavaScript specific warning behavior #6802

[mhegazy]

man.. this is one of my all time favorite topics :) As I mentioned in #9448 (comment), #8855 (comment), #6771 (comment), #3691 (comment), and i am sure there is more, errors are not the problem, and suppressing them is not the solution; this analogues of switching off your fire alarm. The real problem is you have a faulty fire alarm. So instead of muffling the errors, I would like to know what is the specific error, and why you find it useless. then we can talk how we can make the experience better.

[yortus]

Instead of suppressing compiler errors, it would be interesting to discuss the pros/cons of being able to override compiler options at the file/function level, at least those options that have only local effect.

The closest equivalent to this at the moment is to break up into multiple projects, each with their own tsconfig.json file. Perhaps that's the best solution for major splits (eg a project with both node (target: ES6) and browser (target: ES5) code).

But sometimes I wish I could override an option in a few places without spliting up the project. E.g., I could set the compiler options in tsconfig.json to their strictest setting, and then opt-out of them in a few specific declarations that for whatever reason TypeScript can't analyse properly, or that I need to revisit, but I know are not errors.

I think some people are not adopting the strictest flags at all, because they are all-or-nothing project-wide and bring up huge numbers of errors on their existing codebase.

[yortus]

A couple of examples to go with my previous comment:

---

Here is a util function from bluebird:

function toFastProperties(obj: any) {
    /*jshint -W027,-W055,-W031*/
    function FakeConstructor() {}
    FakeConstructor.prototype = obj;
    var l = 8;
    while (l--) new FakeConstructor();
    ASSERT("%HasFastProperties", true, obj);
    return obj;
    // Prevent the function from being optimized through dead code elimination
    // or further optimizations. This code is never reached but even using eval
    // in unreachable code causes v8 to not optimize functions.
    eval(obj);
}

It would be nice not to have to set allowUnreachableCode: true project-wide just because of this one special case. That would cause a loss of safety in the rest of the project. What if we could preface just this function with // @allowUnreachableCode: true, thereby preserving unreachability checking everywhere else in the project?

---

Here is part of a function from the TypeScript compiler:

            switch (searchSpaceNode.kind) {
                case SyntaxKind.MethodDeclaration:
                case SyntaxKind.MethodSignature:
                    if (isObjectLiteralMethod(searchSpaceNode)) {
                        break;
                    }
                // fall through
                case SyntaxKind.PropertyDeclaration:
                case SyntaxKind.PropertySignature:
                case SyntaxKind.Constructor:
                case SyntaxKind.GetAccessor:
                case SyntaxKind.SetAccessor:
                    staticFlag &= getModifierFlags(searchSpaceNode);
                    searchSpaceNode = searchSpaceNode.parent; // re-assign to be the owning class
                    break;
                case SyntaxKind.SourceFile:
                    if (isExternalModule(<SourceFile>searchSpaceNode)) {
                        return undefined;
                    }
                // Fall through
                case SyntaxKind.FunctionDeclaration:
                case SyntaxKind.FunctionExpression:
                    break;
                // Computed properties in classes are not handled here because references to this are illegal,
                // so there is no point finding references to them.
                default:
                    return undefined;
            }

Setting noFallthroughCasesInSwitch: false project-wide would cause a loss of safety in the rest of the project. What if we could preface just this function with // @noFallthroughCasesInSwitch: false, thereby preserving fall-through checking everywhere else in the project?

[RyanCavanaugh]

I really appreciate the examples -- these are what we're looking for, to be sure! But I'm going to break character here and state my strong subjective opinion about user code, which I usually try hard not to do: Both of those examples are horrifying.

Bluebird could just as easily use something like !!false && eval(obj) to avoid that error. Or wrap the whole thing in a meaningless try / catch, which deopts to my knowledge. Anything they do here is just super-suspect anyway as there are no guarantees V8 won't start doing smarter analysis and ignoring their unreachable eval. I would guess a hyper-low-level function like this (the 8-times loop to force a psuedoclass to be created... what?) occurs in extremely few libraries.

Our own use of IFT here is awful -- the second fall-through doesn't even save any LOC compared to just writing break; at the // Fall-through comment! The first instance is somewhat more excusable but I would still prefer we just never do this.

Again, my own opinion. I would like to see more examples and will try not to judge them so hard.

[yortus]

@RyanCavanaugh how would you prefer to rewrite the first fall-through in the tsc example? OR just not use switch at all?

[RyanCavanaugh]

            switch (searchSpaceNode.kind) {
                case SyntaxKind.PropertyDeclaration:
                case SyntaxKind.PropertySignature:
                case SyntaxKind.Constructor:
                case SyntaxKind.GetAccessor:
                case SyntaxKind.SetAccessor:
                case SyntaxKind.MethodDeclaration:
                case SyntaxKind.MethodSignature:
                    if ((searchSpaceNode.kind === SyntaxKind.MethodDeclaration) || 
                        (searchSpaceNode.kind === SyntaxKind.MethodSignature)) {
                        if (isObjectLiteralMethod(searchSpaceNode)) {
                            break;
                        }
                    }                                            
                    staticFlag &= getModifierFlags(searchSpaceNode);
                    searchSpaceNode = searchSpaceNode.parent; // re-assign to be the owning class
                    break;

[kitsonk]

Also, personal opinion, --noFallthroughCasesInSwitch can easily be turned off and put in the domain of a linter, which is where I think it personally is better suited.

As far unreachable code, I originally felt that it was the domain of a linter, but now seeing what CFA provides, I now feel that when you have a compiler the is evaluating the flow of your code, then unreachable code becomes an error, versus a stylistic issue, even if it is still valid at run-time. It is now clearly in the wheelhouse of TypeScript.

[yortus]

@RyanCavanaugh Oh cool, I thought empty cases also triggered a fall-through error but they don't.

[yortus]

Bluebird could just as easily use something like !!false && eval(obj) to avoid that error.

...sure, until Anders adds some more CFA goodness that statically detects that as unreachable code.

[kitsonk]

...sure, until Anders adds some more CFA goodness that statically detects that as unreachable code.

Well, it could be argued there is a big difference between an unreachable statement and a short circuited expression logic. I think that might be the argument with !!false && eval(obj) in that I know many minifiers evaluate expression logic like that for short circuits and do dead code removal. On the other hand, that is true for unreachable code as well. In any case, it is a dog chasing its tail, put one compiler hint here to avoid another compiler making a mistake.

[yortus]

@kitsonk tsc has already started clamping down on side-effect free (SEF) expressions as per #10814. It could in future (I'm speculating) also complain about !!false && eval(obj) as a side-effect-free (i.e. useless) expression. Interestingly the PR that fixes #10814 uses allowUnreachableCode as the opt-out flag to suppress SEF errors.

[mhegazy]

One philosophical distinction between errors of the like of noImplicitAny, can not find module, or type not assignable to, and ones reported by --allowUnreachableCode, --noFallthroughCasesInSwitch, and --noImplicitReturns, is that the later are more of linter functionality, that we are adding since "we are already there".

The compiler has done the control flow analysis, already so it might as well tell you you have an unreachable statement. these are not core to the type system, and are meant for the 90% case. if you want more customization for these you can switch them off entirely, and use a linter rule. linters already are built with exceptions for specific errors and different levels, etc..

The other errors are really at the core of what the compiler does. for instance, if it does not know what shape a module has, it can not say anything about the imports, or how they are used, further use of these types would not be safe either, since an error type are just any.,the tools can not guarantee that renaming x in one place will be safe, etc.. at the core is the TypeScript value -proposition.

Now, I am not saying all the errors that the compiler emit today are ideal. And this is why we should be having these discussions. and for instance, short-hand modules, and using of wild cards in module names were conceived because of users complaining about a too-stringent error message. if they were to switch that one off, they would have masked the real cause, and instead see a degradation of service in the compiler and the tools.

[nxpatterns]

The reason, why we would need such of feature is very simple:

We have old applications, which we have to migrate step by step into a new framework. (An example would be migrating old JavaScript/TypeScript/.. Codes from Angular1 to 2)

In the earlier steps we have to suppress some errors like this[foo] = bar and some other ones, so that the app is first runnable. If we can run the app in the new framework, we get the decision from Marketing/Management Department for the refactoring in depth. Marketing department is absolutely not interested in compiler errors.

We have a pre-configured build system (big company) and may only change tsconfig.json. Currently the build sytem drums out our app because of existing errors. And there are a big amount of source codes and we have not the resources to correct every error in a short given time. Therefore we need some feature like to deactive certain errors, which were ok at that time (at the time of writing of that old stuff and the list is long.

As you see, there are certain use cases, that are not considered by the creators of TypeScript :) The world is not perfect and you may not always expect perfect pre-conditions. Therefore the ability to deactivate (be it very important) errors is an essential feature for the real world.

Thank you!

[mhegazy]

As you see, there are certain use cases, that are not considered by the creators of TypeScript :) The world is not perfect and you may not always expect perfect pre-conditions. Therefore the ability to deactivate (be it very important) errors is an essential feature for the real world.

The typescript code base does not have --noImplicitThis or --strictNullChecks enabled for the same reason. so is not too strange of a scenario to the core team. what we have done instead is try with the new flag on, try to fix issues as much as possible, then iterate. once all issues have been fixed flip the switch. that has worked in the past for different new switches, we would hope it works with strinctNull as well.

[nxpatterns]

Dear Mohamed, thank you very much for your feedbacks but I can not emphasize that enough;

   I want to suppress, the error, which I want. That can be any of them.  

I appreciate the work from Microsoft very much, TS has a huge potential to be THE LANGUAGE OF WEB, but there is still no complete list, a kind of itemization of Error-Codes (TSWhatever <--> TSLint-Rule <--> Available Custom Rules <--> ...), we have to fish out them out of the source code. I think, there is still much work to do.