Typescript: Skip typechecking; only emit

Created on 6 Aug 2015  路  8Comments  路  Source: microsoft/TypeScript

I am often already convinced of my programs type safety before I run my simple bash script to compile through TypeScript, compile through babel, and run. I do not currently see any mechanism to simply emit JavaScript code instead of typechecking. Is it already done somewhere/not currently feasible/not worth it?

Question

Most helpful comment

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.

All 8 comments

Then why use TypeScript?

I am using the atom-typescript package with Atom, so the code does get typechecked.

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.

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!

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.

For completeness here is some documentation for ts.transpile.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jbondc picture jbondc  路  3Comments

dlaberge picture dlaberge  路  3Comments

weswigham picture weswigham  路  3Comments

kyasbal-1994 picture kyasbal-1994  路  3Comments

MartynasZilinskas picture MartynasZilinskas  路  3Comments