Ability to over power TS and ignore specific error by developer

[born2net]

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

[fluffywaffles]

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.

[rozzzly]

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

const foo: string = 7 as any;

Is that what your looking for?

[born2net]

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

[rozzzly]

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

[born2net]

that would be awesome...

[rozzzly]

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

[born2net]

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

[fluffywaffles]

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. ;)

[mhegazy]

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

[zpdDG4gta8XKpMCd]

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';

[born2net]

ok but again, the issue is not specifically on casting

[zpdDG4gta8XKpMCd]

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

[born2net]

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

[rozzzly]

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.