checkJs + suppressing errors = powerful

[ifle]

TypeScript Version: 2.3Code

Both these options will be very powerful

[mhegazy]

both options are enabled. please see https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files for more details.

[ifle]

// @ts-nocheck is not enough. I think the prefer way in most cases are defining ignored errors in tsconfig file, like this nocheck : [ "TS2001", "TS2012" ]. We have a several large projects with a lot of JS files. It's not good idea to touch all files for @ts-nocheck flag

[mhegazy]

We do not believe switching off specific errors across the whole project is a good idea. think of TS 2322 this is Type .. is not assignable to type ... disabling this across the project is meaningless at best.

today you have two modes, --checkJs on your whole project, and opt-out of some files using // @ts-nocheck; or opt-in files you want to check using // @ts-check.

You can list the files you want to check in your tsconfig.json / jsconfig.json and then have a different tsconfig.json / jsconfig.json for everything else.

[ifle]

We have 4 legacy .net web applications. One "small" application for example has 290 js files and we have > 20,000 typescript errors. Note that the all JS files are valid, but we not able to compile a solution. We not able doing "soft" migration. I agree that suppressing errors are not good idea for "new" projects that used modern technologies like angular, node etc, but for legacy, classic web applications these "soft" migration options will be very useful.

For example in our legacy application for the first stage we must suppress following errors : TS2304, TS2384, TS2393, TS2339, TS2365, TS2346, TS2322, TS2403, TS2345, TS7027, TS2362, TS1313, TS2300, TS2350, TS2453, TS2363, TS2349, TS2540, TS2447, TS2678. I know it's not ideal, but for the first stage this is a solution. That will allows us to compile solution without any error. We will remove errors from this list, but that can take a time. Really, I don't understand why do not add this option? Take a look to C#. C# language has suppressing warnings and not errors. There is reason why we can't suppressing errors in c#, in case of errors the application will not works, but in case of TS, generated JS is valid and application works as expected. Please give us option to choose what is bad or good for us.

P.S. Sorry for my bad english

[mhegazy]

I do not think switching off error codes is a good idea. it might work for local errors (like what a linter would do), but not for type system errors.

I can see a more config-bases solution to exclude some files listed by a glob patter for instance,

[teppeis]

@ifle @mhegazy I think comment-based inline suppressing is better like ESLint. http://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments This feature makes JavaScript to TypeScript migration easier.

/* typescript-disable */
const foo: string = 1;
/* typescript-enable */

or

// typescript-disable-next-line
const foo: string = 1;

also specifying the error code

/* typescript-disable TS2322 */
const foo: string = 1;
/* typescript-enable */

// typescript-disable-next-line TS2322
const foo: string = 1;

Closure Compiler has two options, 1: global setting by command line option, 2: @suppress annotations in comment (line-based or method-based). https://github.com/google/closure-compiler/wiki/@suppress-annotations

/** @suppress {checkTypes} */
const foo: string = 1;

ref: https://github.com/Microsoft/TypeScript/issues/4094

[ifle]

@teppeis I totally agree that both options (global and comment) are perfect. There are lot of products like Intelij, Resharper that allows to configure errors as warning, hint or suppress them globally or in comments.

[AllNamesRTaken]

Did this topic die off? It would really help yo be able to turn off or cover to warnings on a per file basis or by using globs in tsconfig.

[joelday]

@mhegazy Maybe a bit broad of an issue, but the ability to disable warnings that require a lot of gymnastic workarounds/comment noise/ignoring files for code that can't be changed yet would be extremely valuable. A good example of this is having to add type JSDoc annotations to any object that needs to be a React.CSSProperties. I'm trying to ease a very apprehensive org into adopting TypeScript, and allowJs and checkJs are great, but these kinds of 'gotchas' make people feel like the whole thing isn't worth it.