Disable --noImplcitAny, --noImplicitThis and --strictNullChecks in .js files

[mhegazy]

• Implicit Any errors should be disabled in .js even if --noImplicitAny is set for the whole compilation.
• noImplicitThis inferences should be enabled, but errors disabled
• Similarly, inferences for --strictNullChecks for null and undefined types should stay, but errors like Variable is used before being assigned or Object is possibly undefined should be disabled.

This allows for users to mix and match .ts and .js files, and enable strict checks for the .ts files without having errors in the .js file

[Jessidhia]

Variable is used before being assigned is definitely useful in .js files when used with const. The let case is not as easy, but will the compiler still be able to do TDZ inference?

[mhegazy]

The compiler can not get TDZ right all the time. in .ts files if the compiler misses, users can use the non-null assertion operator !, but that is not possible in a .js file, hence disabling the error.

for instance:

var x;
setx();
x++;

function setx() { 
    x = 0;
}

So either we report the error, and users can not disable it, or not report the error at all.

[Jessidhia]

What I'm wondering is whether TypeScript will be able to flag this specific error:

x // ReferenceError
let x // or `class x`

var doesn't create a TDZ so it's fine to just consider it undefined.

[mhegazy]

that is a different error. block scoped variables are flagged if used before they are declared in general, this is not impacted by --strictNullChecks.

[cyrilletuzi]

It would be a huge downgrade to deactivate all these options. checkJs is here to give the power of TS type checking also in JS files, which is a great idea. And the real power of TS is the strict mode. If it's just to infer types when it's possible, checkJs has no use, as good editors like VS Code already do that in JS from a long time...

I'm a JS/TS trainer, so I've played with the new checkJs in strict mode with all the cases I usually teach during courses, and except for a few issues (mainly relative to partial JSDoc support and a cast problem with DOM elements), it works very well.

I've seen no issue with noImplicitAny and the case you mention isn't affected by this option, so what's the reason to want to disable it ?

For strictNullCheck : I have no idea how to solve your case, but at first glance I would say it's weird (bad ?) code and it seems OK to me that an error is raised so I opt for a better solution (after all, it's one goal of strict mode). If there is real situations like this, only the inconvenient errors should be disabled but not all the strictNullCheck option.

And in all cases (like in TS by the way), strict modes are options : so if a project don't want (or can't) be strict, then it just have to not activate those options (which is the default).

But that would be a very bad news to disable strict modes for those who want them.

[mhegazy]

Seems like too many folks are using --strictNullChecks and --noImplicitAny with --checkJs in the wild. closing for now.