Making JavaScript to TypeScript migration easier : Suppress errors

[basarat]

Motivation

I am looking for community ideas to make partial migration from JavaScript to TypeScript easier. Currently the errors suppression mechanism is ugly : http://basarat.gitbooks.io/typescript/content/docs/types/migrating.html and can cause long term pain. (Am I overlooking something?)

Plan

I imagine that one creates a .ts file and writes plain JavaScript inside it and has a way to tell TypeScript to only reports errors that are invalid JS. Anybody have suggestions on how the configuration for this should look like?

[RyanCavanaugh]

We've been talking a lot about this lately. Migration is painful enough in certain cases to be an adoption blocker.

that are invalid JS

I have some ideas, but I'm curious how you define this? Syntactic errors only?

[basarat]

I'm curious how you define this

Implementation

I feel like going though diagnostics disabling reporting all to begin with, and then switching on the ones that make sense for all JavaScript. Especially switching on the Syntactic ones.

Configuration

• Providing finer control over diagnostics so that a team controls what valid JS means to them. Question : How to specify these ignored error codes?
• Secondly how to tell compiler this .ts file should be treated like js.

Both questions are configuration related (assuming an implementation around using diagnostic error codes sounds reasonable).

[spion]

I don't understand - in what way is the migration painful? The compiler still generates JS files. The editor (or an external filtering tool) can be used to filter out error messages in unrelated code (based on both paths or error codes), i.e. tsc | tsc-filter-errors.

Do you mean something like having reporting options (exclude globs and codes) as a part of tsconfig.json?

"errorReporting": {
  "excludeFiles": ["src/legacy/**/*.ts", ...],
  "excludeCodes": [7005, ...]
}

Besides there is no better todo message than a compiler error: its there exactly as long as the code isn't annotated and its impossible to forget to add/remove it.

[RyanCavanaugh]

Pushing the filtering downstream means multiple toolchains have to agree on the error filtering schema, and implement them with 100% consistency. It's herding 🐈 🐈 🐈

It's also more natural to specify in the file itself what the "migration state" of that file is instead of mucking with a giant list of files in a config file somewhere (not to mention if that file is used in multiple projects). Flow uses a similar setup.

Besides there is no better todo message than a compiler error

We kind of have to acknowledge developer irrationality on this front. No one can get away with checking in a toolchain that produces 150 errors and tell their team "Hey guys, we'll fix those when we get around to it". I've worked on teams that did try that (with a style checker that just produced a total number of warnings in the default build pipeline) and the number of errors actually grew over time because it was totally ignored.

[basarat]

Reading the blog post and not having tried it myself http://blogs.msdn.com/b/typescript/archive/2016/01/28/announcing-typescript-1-8-beta.aspx can this be closed because of allowJS or is there something more? 🌹

[mhegazy]

sounds good. closing. we can reopen if there are other feedback.

[billti]

#6802 could potentially come into play here also. That issue will track any design & implementation.

[born2net]

I agree, I think a developer should a super power of TS to hide an error if he/she decides to...
maybe a ///TS_IGNORE above a line that ts inferred an error on...
be great!

[zmoshansky]

I would propose maintaining syntax consistency with palantir/tslint#1175.
ts:disable-next-line

[Venryx]

"errorReporting": {
  "excludeFiles": ["src/legacy/**/*.ts", ...],
  "excludeCodes": [7005, ...]
}

The above would be great!

Currently, the inability to disable specific errors that I don't care about is the biggest downside for me about TypeScript. (mostly for cases where I just want it to default to type "any", because I know the code works fine despite not being compile-time-guaranteed type-safe)

This is because it means a larger overhead to "switching" to TypeScript--you have to change the majority of the files in your code base all at once to avoid the error markings. Ideally, someone would be able to transition into TypeScript by disabling the tamer yet more widespread errors until a later point. (and perhaps never even updating certain files, e.g. external libraries)

[AllNamesRTaken]

The above is really needed. Here is an example of code that I believe is correct but throws a bunch of errors:

export type Constructor<T> = new (...args: any[]) => T;
export default function FooableMixin<T extends Constructor<{}>>(Base: T) {
    return class extends Base implements IFooable {
        constructor(...args: any[]) {
            super(...args);
        }
    }
}
export class BaseBar {}
export class FooableBar extends FooableMixin ( BaseBar ) {}

This throws: TS4060, TS4093 and TS4020
Because I cannot export the anonymous class so its public.

A really nice solution would be to not turn off Errors but turn them into Warnings.

[BobFrankston]

There is another flavor of the issue when I use an existing library such as http://trackingjs.com/. I want to suppress errors based on their place (library) rather than specific errors. This may need to be a tsconfig option.

[brunolemos]

Maybe this should be reopened? This is the issue we end up to when looking for how to ignore tsc errors (be it by error code, by files, etc). There are some proposals above but I don't think we have any live solution for this yet?

cc @mhegazy

[brunolemos]

For my specific case, the --skipLibCheck tsc flag was enough.