Making JavaScript to TypeScript migration easier : Suppress errors #4094

Closed
basarat opened this Issue Jul 31, 2015 · 14 comments

Comments

Projects
None yet
@basarat
Contributor

basarat commented Jul 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@RyanCavanaugh

RyanCavanaugh Jul 31, 2015

Member

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?

Member

RyanCavanaugh commented Jul 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@basarat

basarat Jul 31, 2015

Contributor

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

Contributor

basarat commented Jul 31, 2015

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

@basarat basarat referenced this issue in TypeStrong/atom-typescript Jul 31, 2015

Closed

Using atom typescript with plain js files #509

@spion

This comment has been minimized.

Show comment
Hide comment
@spion

spion Jul 31, 2015

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.

spion commented Jul 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@RyanCavanaugh

RyanCavanaugh Jul 31, 2015

Member

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.

Member

RyanCavanaugh commented Jul 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@basarat

basarat Jan 29, 2016

Contributor

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? 🌹

Contributor

basarat commented Jan 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Jan 29, 2016

Contributor

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

Contributor

mhegazy commented Jan 29, 2016

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

@mhegazy mhegazy closed this Jan 29, 2016

@billti

This comment has been minimized.

Show comment
Hide comment
@billti

billti Feb 2, 2016

Member

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

Member

billti commented Feb 2, 2016

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

@tomwayson tomwayson referenced this issue in Esri/esri-system-js May 31, 2016

Closed

Visual Studio 2015 RC1 & Esri System Js #6

@born2net

This comment has been minimized.

Show comment
Hide comment
@born2net

born2net Jun 30, 2016

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!

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

This comment has been minimized.

Show comment
Hide comment
@zmoshansky

zmoshansky Jul 18, 2016

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

zmoshansky commented Jul 18, 2016

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

@Venryx

This comment has been minimized.

Show comment
Hide comment
@Venryx

Venryx Dec 20, 2016

"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)

Venryx commented Dec 20, 2016

"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

This comment has been minimized.

Show comment
Hide comment
@AllNamesRTaken

AllNamesRTaken Apr 3, 2017

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.

AllNamesRTaken commented Apr 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@BobFrankston

BobFrankston Aug 11, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Jan 15, 2018

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 commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Jan 15, 2018

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

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

@Microsoft Microsoft locked and limited conversation to collaborators Jul 3, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.