Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   DiscussionIssues which may not have code impactIssues which may not have code impact

   on Jul 31, 2015
2. RyanCavanaugh commented on Jul 31, 2015

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jul 31, 2015

   Member

   More actions

   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?
3. basarat commented on Jul 31, 2015

   

   Basarat Ali Syed (basarat)

   on Jul 31, 2015

   ContributorAuthor

   More actions

   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).
4. spion commented on Jul 31, 2015

   

   spion (spion)

   on Jul 31, 2015

   More actions

   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.

   👍React with 👍10Reacted by Joe Brown, Priyanshu Jindal, lightGo, Juan Delgadillo, Adam Mazzarella, Richard Lewis, Ananías Hilario, Bruno Lemos, Bek and Alex Filatov
5. RyanCavanaugh commented on Jul 31, 2015

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jul 31, 2015

   Member

   More actions

   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.
6. basarat commented on Jan 29, 2016

   

   Basarat Ali Syed (basarat)

   on Jan 29, 2016

   ContributorAuthor

   More actions

   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? 🌹
7. mhegazy commented on Jan 29, 2016

   

   Mohamed Hegazy (mhegazy)

   on Jan 29, 2016

   Contributor

   More actions

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

   👍React with 👍1Reacted by AngularNinja.com
8. Mohamed Hegazy (mhegazy)

   closed this as completedon Jan 29, 2016
9. billti commented on Feb 2, 2016

   

   Bill Ticehurst (billti)

   on Feb 2, 2016

   Member

   More actions

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

   👍React with 👍1Reacted by AngularNinja.com
10. born2net commented on Jun 30, 2016

    

    AngularNinja.com (born2net)

    on Jun 30, 2016

    More actions

    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!

    👍React with 👍15Reacted by Zachary Moshansky, Faraz Yashar, Ivaylo Ivanov, Mathieu Lorber, rubyboy, Sunny Gonnabathula, MyEidos, Fabio Spampinato, Jakub Strojewski, Simon Kurtz and 5 more
11. zmoshansky commented on Jul 18, 2016

    

    Zachary Moshansky (zmoshansky)

    on Jul 18, 2016

    Last edited by zmoshansky

    More actions

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

    👍React with 👍4Reacted by Jakub Strojewski, Artem Zagorodnyuk, Bruno Lemos and Ben Hughes
12. Venryx commented on Dec 20, 2016

    

    Stephen Wicklund (Venryx)

    on Dec 20, 2016

    Last edited by Venryx

    More actions

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

    👍React with 👍7Reacted by Matthew Kendrick Co, beeman, Stephen Smit, Roy Breidi, Nikos, Bruno Lemos and Ryan
13. AllNamesRTaken commented on Apr 3, 2017

    

    AllNamesRTaken (AllNamesRTaken)

    on Apr 3, 2017

    Last edited by AllNamesRTaken

    More actions

    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.
14. BobFrankston commented on Aug 11, 2017

    

    Bob Frankston (BobFrankston)

    on Aug 11, 2017

    More actions

    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.

    👍React with 👍1Reacted by Deryost
15. brunolemos commented on Jan 15, 2018

    

    Bruno Lemos (brunolemos)

    on Jan 15, 2018

    Last edited by brunolemos

    More actions

    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 Mohamed Hegazy (@mhegazy)

    👍React with 👍2Reacted by Boris Berman and Michal Vanko
16. brunolemos commented on Jan 15, 2018

    

    Bruno Lemos (brunolemos)

    on Jan 15, 2018

    More actions

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

    locked and limited conversation to collaborators on Jul 3, 2018