Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip typechecking; only emit #4176

Closed
ludamad opened this issue Aug 6, 2015 · 8 comments
Closed

Skip typechecking; only emit #4176

ludamad opened this issue Aug 6, 2015 · 8 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@ludamad
Copy link

ludamad commented Aug 6, 2015

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?

@kitsonk
Copy link
Contributor

kitsonk commented Aug 6, 2015

Then why use TypeScript?

@ludamad
Copy link
Author

ludamad commented Aug 6, 2015

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

@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Aug 6, 2015
@RyanCavanaugh
Copy link
Member

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.

@ludamad
Copy link
Author

ludamad commented Aug 6, 2015

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!

@RyanCavanaugh
Copy link
Member

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.

@mhegazy
Copy link
Contributor

mhegazy commented Aug 6, 2015

For completeness here is some documentation for ts.transpile.

@mhegazy mhegazy closed this as completed Aug 10, 2015
@pauldraper
Copy link

pauldraper commented Apr 6, 2017

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.

@testerez
Copy link

testerez commented Jul 16, 2017

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.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

6 participants