Skip typechecking; only emit #4176

Activity

1. kitsonk commented on Aug 6, 2015

   

   Kitson Kelly (kitsonk)

   on Aug 6, 2015

   Contributor

   More actions

   Then why use TypeScript?
2. ludamad commented on Aug 6, 2015

   

   ludamad (ludamad)

   on Aug 6, 2015

   Author

   More actions

   I am using the atom-typescript package with Atom, so the code does get typechecked.
3. Ryan Cavanaugh (RyanCavanaugh)

   added

   QuestionAn issue which isn't directly actionable in codeAn issue which isn't directly actionable in code

   on Aug 6, 2015
4. RyanCavanaugh commented on Aug 6, 2015

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Aug 6, 2015

   Member

   More actions

   The typechecking step has to run for the emit to be correct. The emit will happen either way, though, so you can simply pipe the console output of tsc to /dev/null. A fancier solution would be to use the compiler's transpile API directly.
5. ludamad commented on Aug 6, 2015

   

   ludamad (ludamad)

   on Aug 6, 2015

   Author

   More actions

   What part of typechecking informs the emit? I am mostly interested in skipping it for performance reasons, as I am led to believe this is most of the time spent. Can the transpile API do a correct emit ignoring all type annotations? That sounds like a good suggestion if so, thank you!
6. RyanCavanaugh commented on Aug 6, 2015

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Aug 6, 2015

   Member

   More actions

   The actual types the compiler sees doesn't matter in terms of producing correct emit, but it's the typecheck phase that, for example, sets the flag that tells the emitter that the second arrow function (but not the first) needs to have var _this = this; emitted in its enclosing scope. Ultimately these are more like syntactic checks than type system checks, but it's more efficient to do those two things at the same time (instead of in two passes) since the majority of the time, you want both to happen.

   class Foo {
       fn1() {
           let x = () => { null; };
       }
       fn2() {
           let y = () => { this.fn1(); };
       }
   }

   The transpile API should be a bit faster because it doesn't include lib.d.ts.
7. mhegazy commented on Aug 6, 2015

   

   Mohamed Hegazy (mhegazy)

   on Aug 6, 2015

   Contributor

   More actions

   For completeness here is some documentation for ts.transpile.
8. Mohamed Hegazy (mhegazy)

   closed this as completedon Aug 10, 2015
9. pauldraper commented on Apr 6, 2017

   

   Paul Draper (pauldraper)

   on Apr 6, 2017

   Last edited by pauldraper

   More actions

   The typecheck phase is lengthy and requires type inference. It is convenient to get sub-second iteration time for active development work, and then the safety of type checking when creating the final product.

   Since tsc's output does not depend on types (as opposed to say, gcc), it would be very possible -- IMO prudent -- to separate these rather different steps.
10. testerez commented on Jul 16, 2017

    

    Tom Esterez (testerez)

    on Jul 16, 2017

    Last edited by testerez

    More actions

    After some time working with typescript, I realize that it makes more sense for me to disable type checking during compilation.

    My motivations:

    1. I want the build to be as fast as possible so I can iterate quickly and have faster unit tests
    2. If I have a typing error, I still want to be able to run my program and fix the typing issue when I decide to. I know it does not block the emit but afaik ts-loader and awesome-typescript-loader will stop on compilation errors.
    3. I use a vscode task to get all typing errors accross the project directly in my editor. So I don't need another check during my webpack or server side compilation (using ts-node). We also check types with a prepush hook to ensure that we don't introduce type errors in the repo.

    So with my workflow, having compilation and type checking as different tasks makes a lot more sense. This is something I appreciate in Flow's approach.

    👍React with 👍14Reacted by Gregory Jacobs, Artur Klesun, Alexander Ulitin, Kei Son, navels, Anton Fedchenko, Alex, Prashant Tiwari, Augustus, thirtyseven37 and 4 more
11. microsoft

    locked and limited conversation to collaborators on Jun 19, 2018