Typescript: noImplicitAny flag and 3rd party libraries with not compatible type definitions

[sobanieca]

TypeScript Version: 2.5.3

main.ts

import sgMail = require("@sendgrid/mail");

sgMail.setApiKey("{ApiKey}");

    let msg = {
        "to": "{recipient}",
        "from": "{sender}",
        "subject": "test",
        "text": "test"
    };

sgMail.send(msg);

tsconfig.json

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "outDir": "./dist/",                        
    "strict": true,                           
    "noImplicitAny": true,               
  }
}

package.json

{
    "main": "main.js",
    "directories": {
        "test": "test"
    },
    "dependencies": {
        "@sendgrid/mail": "^6.1.4"
    },
    "devDependencies": {},
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "start": "tsc && node dist/main.js"
    }
}

Expected behavior:
I would expect this code to be compiled without any errors. But I'm very new to Typescript and maybe I'm missing something. I tried with "declare module" (and similar) but without luck. Maybe it's related to fact that module is imported with "import =" syntax.

Actual behavior:
Compiler is throwing error about some internal library (in this case @sendgrid/helpers) definitions:

node_modules/@sendgrid/helpers/classes/email-address.d.ts(11,3): error TS7010: 'fromData', which lacks return-type annotation, implicitly has an 'any' return type.
node_modules/@sendgrid/helpers/classes/email-address.d.ts(16,3): error TS7010: 'setName', which lacks return-type annotation, implicitly has an 'any' return type.
node_modules/@sendgrid/helpers/classes/email-address.d.ts(21,3): error TS7010: 'setEmail', which lacks return-type annotation, implicitly has an 'any' return type.

[mhegazy]

--noImplicitAny tells the compiler to warn once there is a declaration with no explicit type, or an intialization that the compiler can infer from. This applies to all files in your compilation. the rational here is that these types can bleed into your code, i.e. if you use the return type of one of these methods, etc.

We recommend all declaration files be compiled with --strict to ensure they do adhere to the strictest possible settings.

For this issue, this seems like a bug in @sendgrid/mail that they should address.

you can also use --skiplibcheck to skip reporting errors in any .d.ts file in your compilation.

[sobanieca]

Thanks a lot for super quick response! I can't find detailed description of skipLibCheck flag. If I use it, does it mean that only definitions in "node_modules" will not be checked by compiler? Or it will affect also other files in my code?

[mhegazy]

I can't find detailed description of skipLibCheck flag.

Please see http://www.typescriptlang.org/docs/handbook/compiler-options.html

If I use it, does it mean that only definitions in "node_modules" will not be checked by compiler? Or it will affect also other files in my code?

All .d.ts files in your project will not be checked. you still can use them, but the compiler will not report errors in them.

[sobanieca]

Thanks. I wonder if there are any side effects about "skipLibCheck" flag. If I understand correctly, .d.ts files exist only for external libraries. The way I want to develop in Typescript is:

• I want to be as much strict as possible about the code that I control.
• I don't want to fix "others" bugs and be slowed down due to some 3rd party errors.

If such solution can be resolved by turning on 'noImplicitAny' and 'skipLibCheck' flags than it sounds great :)

If I can recommend something - I used 'tsc init' command to generate tsconfig.json file. 'noImplicitAny' is turned on by default (as by default "strict" flag is set). In this file there are many flags mentioned (commented out), but there is no 'skipLibCheck' flag there. It would be great to have it there. Also, I think it should be turned on by default.

[mhegazy]

I do not think we want to turn on --skipLibCheck by default. the flag hides any errors in declaration files. The declarations in these files do affect your code, e.g. the return type of a function you use, or a contextual type that affects and object literal or a function expression you write. so it is not true that you can make this separation of what "my types" and "their types" are.
As i noted earlier, this is a bug in the declaration file you got, and you should reach out to the author to generate the .d.ts files with --strict to cater for all users (those with --strict true and those without it). as a workaround, you can use --skipLibCheck but know that you are muffling your fire alarm. So use it with discretion.

[sobanieca]

Ok, thanks. That's what I was affraid of. So maybe there should be an option to skip specific lib check? Something like

skipLibCheckFor: [
    "@sendgrid/mail"
]

Current solution (skipLibCheck) sounds to me a bit like 'all or nothing'. I will have to keep the flag until sendgrid fixes their type definitions, thus affecting other definitions.
I wonder if there is another solution, namely, create own declaration that fixes errors and merge it with the one that was provided by sendgrid.

[mhegazy]

I think it is a library issue that should be fixed by the library author. it is not expected that each user would put an exclusion for some libraries in their config file. the experience is not great, and does not really scale.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.