Ability to over power TS and ignore specific error by developer

A developer should be able to add a comment above a ts error such as

/// TS_IGNORE
let a:string = 1

and have the compiler not report that error...
there are certain scenarios the developer knows best and want to quiet down the error reports.

kind of like :any

regards

Sean

Agreed. Longing for something like Java's @SuppressWarnings, in particular for the case described here:

The following:
const typeMetadataKey = Symbol('type');

function type(name: string): PropertyDescriptor {
 return Reflect.metadata(typeMetadataKey, name);
}
Produces the error: Unable to resolve signature of class decorator when called as an expression..

When used as below:
class Person {
  @type('string')
  firstName: string;
}
The decorator does work as expected and will compile but gives the error above.

If you have thoughts on how this might be resolved happy to dig into it if someone would like to point to the right direction.

Just cast it (cast isn't official term, but same concept)

const foo: string = 7 as any;

Is that what your looking for?

I just gave an example, not really a case (I know all about casting) , I do have other cases such as
super being called after first line of constructor and other issues...

will make transition into TS easier from JS + sometime you change a lib and get tons of errors and you just want to clean things up as you know as the developer for the reason...

this is an important feature

So something like // tslint:disable?
Possibly even letting you turn on/off specific checks tsc performs?
eg: const FooBar: string = 'rozzzly'; // tslint:disable-line camelcase

that would be awesome...

I don't know... I think that might be out of the scope of tsc. That's what linters are for.

there has to be able to "shut it up" :)

I think there's a case to be argued for suppressing errors/warnings on "experimental" features, like decorators, where the API is a bit volatile and the errors may not always be accurate. You get a (very specific) version of this just using the tsconfig "experimentalDecorators" field, but it only suppresses one type of warning.

To play my own devil's advocate, this could encourage new users of TypeScript to suppress warnings they do not understand instead of learning why the warning occurs. And with experimental features, everyone is sort of a new user - having the ability to suppress errors could make users complacent with bugs in new features, instead of opening issues.

Ultimately, I still want my Syntastic output to be clean. Which means suppressing the error. Of course, that would be after I open the issue for a possible bug and try to learn more. ;)

The problem with "shutting it up" is you do not know what you get out of "it". so is let a:string = 1 a number or a string?, what if there is another declaration of a, does it merge or not? what if some one captured the type of this variable e.g. return {a} ; , should they be assignable to { a : number } or { a: string }, or both.

one fundamental thing, errors are all ignoble. errors do not block the generation of outputs, nor the tooling.

There are different mechanisms to allow you to suppress checking of certain parts of your code, e.g. any, type assertions (casts), and ambient declaration.

so for instance, if you have a library that has "invalid" definition, you can just remove it, and replace it with declare module "blah" { export = any }. or declare var $: any and you are good to go.

As i usually reply to these requests, i think your problem is not in suppressing the error. the real issue is you got an error that you do not find useful. suppress that does not solve the underlying problem it just covers it, and has ramifications of an inconsistent state with no warning. The right solution is to know what is the error you are getting? what library is it? and why the compiler is giving you an unuseful error...

And for this we need to know more about your use case.

We have done some work in TS 2.0 to resolve some of these underlying issues, for instance;

Support shorthand ambient module declarations and wildcard chars in module names that allows for an easy way to disable a whole module or even a set of modules e.g. declare module "@angular\*";
Module resolution changes to allow you to override where a module definition is loaded from
allowing for duplicate definitions with the same type accross .d.ts files
new --skipLibCheck to not type check any .d.ts files
support for --typeRoots to allow overriding where declaration files are loaded from

just use any, this is how "shut it up", merits of doing so (or actually a lack of thereof) is a different question

let x: PieInTheSky = <any> 'cake is a lie';

ok but again, the issue is not specifically on casting

<any> gives you vanila javascript with 100% freedom from all annoying things of TypeScript, so what else do you need?

in my case I call super not as fisrt line of constructor and need to quiet the error

Instead of trying to force it to accept an antipattern, why not write try something like this:

_ClassA.ts

class A {
    constructor() {
        this.init();
    }
    protected init() {
        // does nothing by itself
    }
}

_ClassB.ts

class B extends A {
    constructor() {
        super();
        console.log('rest of code from B\'s constructor');
    }
    protected init() {
        console.log('this runs before the rest of code from B\'s constructor');
    }
}

This is what makes typescript so awesome, and also annoying. It forces you to write better code and it makes you a better developer. Converting a project is not fun; you might consider it to be a developer's "initiation" or perhaps, "trial by fire." 😆 But you learn a lot, and its totally worth it imho.

As mentioned in #19109 we still don't have the ability to suppress a specific error.

I think basic scenario outlined in this issue has been addressed. we can create a new issue to track global error suppression using error number. We have been reluctant to use error codes in such way because they lack expressiveness.

This instruction works only per file, right? Is it possible to make it work over folder?

Why did you close this issue? The solution is still missing! Why do you have meaningless discussions for 2 years instead of integration a proper error-suppressing-possibility?

(Adding this comment here as it might be useful for those who stumble upon this issue, as I did)

I ran across #21602 and it might be the solution.

Just add // @ts-ignore to your code ~~(or even // @ts-ignore <some code error> to ignore only the specified error)~~.

Tested it here with TypeScript 2.7.2 and it works!

ts-ignore

(or even // ts-ignore to ignore only the specified error).

#21602 was not merged. You can't ignore only certain errors.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) you're right! I've updated my comment. Thanks!

Arrived here looking to suppress error TS2339.

document.getElementById('theme-admin').disabled = false; /* tslint:disable */
document.getElementById('theme-member').disabled = true; /* tslint:disable */

Navigation Menu

Repository navigation

Ability to over power TS and ignore specific error by developer #9448

131 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Ability to over power TS and ignore specific error by developer #9448

Description

Activity

fluffywaffles commented on Jun 30, 2016

rozzzly commented on Jun 30, 2016

born2net commented on Jun 30, 2016

rozzzly commented on Jun 30, 2016

born2net commented on Jun 30, 2016

rozzzly commented on Jun 30, 2016

born2net commented on Jun 30, 2016

fluffywaffles commented on Jun 30, 2016

mhegazy commented on Jun 30, 2016

zpdDG4gta8XKpMCd commented on Jul 1, 2016

born2net commented on Jul 1, 2016

zpdDG4gta8XKpMCd commented on Jul 1, 2016

born2net commented on Jul 1, 2016

rozzzly commented on Jul 2, 2016

131 remaining items

mhegazy commented on Oct 12, 2017

Lonli-Lokli commented on Oct 17, 2017

nxpatterns commented on Jan 10, 2018

miltonbecker commented on Mar 20, 2018

RyanCavanaugh commented on Mar 20, 2018

miltonbecker commented on Mar 20, 2018

tomshaw commented on May 19, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions