TypeScript: Ability to over power TS and ignore specific error by developer

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

const foo: string = 7 as any;

Is that what your looking for?

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

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?

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

ok but again, the issue is not specifically on casting

I lack both the time and desire to maintain my own typings definitions for 3rd party libraries 😉

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

I ran across https://github.com/Microsoft/TypeScript/pull/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!

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

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

_{<kbd>ClassA.ts</kbd>}

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

_{<kbd>ClassB.ts</kbd>}

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.

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 an interface+class combo

interface Animal {
  numberOfLegs: number;
  // a gazillion more properties
}

interface Dog extends Animal {
}

class Dog  {
  breed: string;

  constructor(animal: Animal, breed: string) {
    Object.assign(this, animal);
    this.breed = breed;
  }
}

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

@amiraliakbari You can assert window as any type, which effectively lets you opt out of type checks:

(window as any).console = {};

I lack both the time and desire to maintain my own typings definitions for 3rd party libraries 😉

And that is perfectly fine. just use declare module "moment"; which is the equivalent of declare var $: any for modules, and the compiler will not bother you about it again.

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

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

The instruction is supposed to work for a single line at a time. If you’re seeing a lot of compiler errors in your project, you might check that you should have less strict compiler options, such as leaving noImplicitAny off (i.e., variables are implicitly any if not annotated). You could also leave some files as JS and set allowJs on but checkJs off.

@mhegazy I’ve hit this kind of problem in a number of different ways.

My current situation (the entire flow assumes declaration mode):

• class decorators require a class declaration (not class expression) and I’m inside a function - in principle this could be fixed, but it’s not today.
• ok, no problem I’ll make the expression a declaration
• no dice, the declaration now has an unused name
• ok, no problem I’ll return it
• no dice, Return type of public method from exported class has or is using private name
• … ?

Basically, the root cause here is that expressions can’t be decorated, but it’s unreasonable for you to drop everything to implement that functionality. In the meantime, it’s sensible for me to simply suppress this error. I’d be fine if suppressing an error required me to find the associated TypeScript issue and say something like // TS-LIMITATION:#9448 although I suspect that would result in a huge amount of new pointless issues from your perspective.

I’d even be fine if you added specific targeted suppressions for known issues that you aren’t ready to take up yet, but only if that was done quickly and without too much design effort (that would make the mechanism pointless 😉 )

A new SO question that needs to suppress noUnusedLocals error: https://stackoverflow.com/questions/45519476/is-it-a-typescript-antipattern-to-dynamically-call-a-member-function-stored-in-a

Another example of how this would be useful:

const req = https.request({
        host: 'www.google.com',
        method:'GET',
        path:'/',
        port: 443,
}, (res) => { 
    console.log(res.connection.getPeerCertificate());
});

The getPeerCertificate says it doesn’t exist due to faulty definitions in the node https (also this).

It still compiles and works with the big red underline, but it would be very nice to do

console.log(res.connection.getPeerCertificate()); //ts:disable-line

The downside to adding declare module "moment"; is that you will no longer have any IDE intellisense or static type checking for any moment-related code. And the anys that arise tend to bleed out into surrounding code, shutting down many static checks there as well. It’s a heavy price to pay for suppressing errors related to a single problematic enum value.

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

tsc can be configured to emit the output regardless of type errors, look at the noEmitOnError option.

If you’re using ts-loader, it also has a new transpileOnly option where it will simply transpile and not show any errors.

@leocaseiro Why does it need to be private? In this case onClick is a method that angular will end up using. A similar problem always happens when we declare private variables that we use in a template. If you do use them in the template simply make the variables public. It makes sense since you are letting angular use them.

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.

@RyanCavanaugh Well, for that matter, (!true)works … I didnt even think of those as possibilities because I (as an ex-compiler-writer) gave the compiler more credit with regard to constant/literal expression collapsing… I guess I figured if it was going to be a busy-body about if (false), it would know if (!true) was the same thing!

@polyglotinc if (!!false) {

I have a question. First the code, and the error that TypeScript is highlighting:

import {Directive, ElementRef, Input, OnChanges, SimpleChange} from '@angular/core'

@Directive({
  selector: '[blankAttr]',
})
export class BlankAttr implements OnChanges {
  @Input('blankAttr') private attrName: string // <--- TS Error: unused variable

  constructor(private el: ElementRef) {}

  public ngOnChanges(changes: {[key: string]: SimpleChange}): void {
    const change: any = changes.attrName 
    const prevValue: any = change.previousValue

    if (prevValue) {
      this.el.nativeElement.removeAttribute(prevValue)
    }
    this.el.nativeElement.setAttribute(change.currentValue, '')
  }
}

The problem I have is I need to declare the @Input decorator to allow the attribute to be passed a string. But I only care about the value of that string when it changes. And I can get the previous and current value when handling the change event.

Can we have a // ts-ignore now? Or is there another way to solve this nicely?

If I want to bring a library file into a project (e.g. Chartjs), I often save it as a TS file (I like to keep all source files as TS and compiled as JS) and import it with a triple slash ref into the TS file that requires it. However, the TypeScript then complains endlessly about errors in that file (naturally as it is merely a standard JS file saved off as TS).

However, the ability to add:

/*ts-errors-disable*/ to the start of the library file and /*ts-errors-enable*/ to the end would reduce the output of errors that aren’t relevant but still allow devs to keep all source files as TS.

Or should I just be doing things fundamentally differently?

Suppressing errors is useful when there is a bug in tsc.

A bug preventing emit should be fixed. It is highly unlikely the ability to ignore an error would every cause tsc to suddenly emit something when it has a bug that makes it crash.

It didn’t – switched to Babel – it worked

@mhegazy I’m ok with muffling the fire alarm in code that’s generated by a very well-tested tool. The code is good, they’re just not using state-of-the-art language features, and they shouldn’t have to.

How about a less controversial example - what if the generated code has an unused local? That causes no harm to my code - except in the case where I have to turn off noUnusedLocals in tsconfig - which is what I am doing now.

@rpadovani just use any:

expect(isValidId(78 as any)).toBe(false);

declare var Symbol: any;

I have this issue with a node core library (net, node 6.9 LTS):

server = net.createServer({ pauseOnConnect: true }, function(connection) { ... }) 
// [ts] severity: 'Error'
message: 'Argument of type '{ pauseOnConnect: boolean; }' is not assignable to parameter of type '{ allowHalfOpen?: boolean; }'.
  Object literal may only specify known properties, and 'pauseOnConnect' does not exist in type '{ allowHalfOpen?: boolean; }'.'

And also with ioredis library:

var redis = new Redis(CONFIG.redis); 
// [ts] severity: 'Error'
message: 'Only a void function can be called with the 'new' keyword.'

As @yortus and @adamreisnz pointed, this is a common problem as definition files are not always correctly updated. Besides, If you have to sacrifice TS benefits using declare module "x"; why would you use TS in the first place?

you could just add a local copy. say something as simple as:

// ./overrides/moment.d.ts
declare module "moment";

// tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "baseUrl": ".",
        "paths": {
            "moment": ["overrides/moment.d.ts"]  // override definition for moment
        }
    }
}

now the compiler will be checking against your local copy of override/moment.d.ts instead of the one coming with the package. obviously this can be a local copy of moment declaration file, or a small set of things you need.

TS errors do not block the code generation. You could choose to ignore them, but what these are telling you is that the compiler can not assert the correctness of your code.

here’s another case where I would love to have this feature:

interface Animal {
  numberOfLegs: number;
  // a gazillion more properties
}

class Dog implements Animal {
  breed: string;

  constructor(animal: Animal, breed: string) {
    Object.assign(this, animal);
    this.breed = breed;
  }
}

Right now there’s an error from ts:

[ts] Class ‘Dog’ incorrectly implements interface ‘Animal’ Property ‘numberOfLegs’ is missing in type ‘Dog’

As you can see, the compiler is totally wrong, but I don’t want to (and I shouldn’t be forced to) copy all the properties from the interface just for the compiler’s sake.

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.

@webia1 You might be interested in #19139 which is still open.

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

I dont want to get unreachable code error (where I am happy to annotate “shut up on unreachable code error right here”) when I do something like if (false){ ...complicated debug code that I dont want to delete/forget... }

+1. This will be useful for testing, since I need to make sure my code throws an error when it is passed in something it is not expecting.

@lukescott in a .d.ts within the scope of the compiler:

declare module './**/reducer' {
  export = {
    [reducer: string]: () => void; /* or whatever */
  };
}

errors do not block the generation of outputs, nor the tooling

That’s not true. We have a (quite common - it comes from starter) setup in webpack which in production build crashes and does NOT output anything. And it should be that way - compiler reports error(s), programmer goes back and fixes them. Why use types when whole team ignores them because build is “working”? Similarily if tsc fails to compile then auto-refresh doesn’t work (plugin is intentionally written that way - it doesn’t refresh if your code is wrong [or considered wrong by compiler]).

Suppressing errors is useful when there is a bug in tsc. E.g. this should compile:

interface A {
  isEmpty(x: any[] | string | object): boolean;
}

const a: A = <A>{};
a.isEmpty({a: 1});

but in current TS release it fails.

Edit: fixed function call (copied wrong line)

Unless you have no emit on error, it will emit. So it does produce ES5.

Why try to dumb down TypeScript, to what purpose?

It’s about moving a team from ES5 => ES6 (Babel or TS) => TS in all it’s glory – in baby steps.

My impression was that TS is an addition to JS allowing you to step in at what level you are at. The reason for my complaint is the dummy example provided throws an Error and hence does not produce ES5. IMO passing linting should not be mandatory to transpile.

true at at creation but not when used – don’t MOM me!

That is specifically what TypeScript is designed to do. If you don’t want to use types and casting, why are you using TypeScript? As pointed out several times in this thread, it will still emit the code, so you ignore errors at your own peril already. Why try to dumb down TypeScript, to what purpose?

@leocaseiro public is the default visibility level so you do not need to specify it.

onTouchStart={<any>''}

you do not need to commit the .js files. let’s say you are using a dependency say react. typically you will not commit react-0.12.0.js in your repo, but you want to use it. noramlly you would include this in a sccript tag from a CDN for instance. let’s also say @types/react does not exist, or you do not want to use it. so in your project add a new declaration file call it declarations.d.ts and add:

declare module "react"; // just saying the module is of type any

this tells the compiler that there is a module called “react” and it will just use it, no need to include any .js files.

@benjaminabbitt It seems that foo (_bar: any, baz: any) works for you: a name starting with "_" is not forced to be used.

Add: I believe that the ability to override/ignore special errors is important.

This code has the desired effect of having the dependency be mocked within the tested component but TypeScript throws an obvious “Cannot assign to ‘Dependency’ because it is not a variable.” error.

this is an error in ES6. so some time in the future when engines support ES6 modules nativelly, your tests will need to be rewritten.

Alternatively you can have your ComponentToTest accept an argument for Dependency, and your tests can pass that, or have test hook that allows you to override the value of Dependency before invoking methods on ComponentToTest.

I am currently converting a huge JS project into typescript and after doing the conversion when I run gulp build command I see around 2000 TS errors during compilation and majority of the errors are related to Property not defined on a class or Module not defined. I think there must be some way to suppress these types of errors as the output JS files are getting generated.

Im using the experimental bind syntax

this is really more than dismissing one warning. The parser does not support it, so the resulting tree is completely wrong, all of the compiler features from this point on will not work, so no type inference, no compatibility checks, no formatting, no completion, nothing. so you would be better off ignoring all errors, or just working in a .js file.

@DethAriel Basically what you’re asking for is a way to express post condition side effects in the type system. That’s interesting but I have a feeling it would lead to some terribly convoluted code.

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. 😉

that would be awesome…