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

Using TypeScript for type checking, not for transpilation #4765

Closed
johnnyreilly opened this issue Sep 13, 2015 · 13 comments
Closed

Using TypeScript for type checking, not for transpilation #4765

johnnyreilly opened this issue Sep 13, 2015 · 13 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@johnnyreilly
Copy link

Hi,

TypeScript doesn't provide transpilation for all ES6 constructs. I've been writing ES6 + JSX and working with Babel and React of late. I'm more than happy with the way Babel transpiles and brings in core js. It works really well.

But I still want TypeScript in the mix for static typing purposes. There's 2 ways to go about this; use TypeScript to emit ES5 and work out how to bring core-js into the mix. I'm not aware of clear guidance on how to make TypeScript play well with core js. I don't think it's out there - and to be fair I haven't tried it out.

The other way, and the way I currently favour, is just using TypeScript for static typing and handing off transpilation to a 3rd party tool such as Babel. This seems potentially possible at present through the use of these compiler options: "target": "ES6" and "jsx": "preserve"

I'm guessing this is something that will always work as long as you target the highest ES emit target (currently ES6 but as async / await etc start to drop then presumably ES7 will become the highest). Is this behaviour we can rely on? Is there any reason we should not?

Is there anything I've overlooked? Does the module import syntax cause any issues? Perhaps the caveat is: the user must be writing 100% ESLatest code + types. And TypeScript-only features (enums for example) will still be transpiled I guess (otherwise how would they work).

@kitsonk
Copy link
Contributor

kitsonk commented Sep 13, 2015

I believe if you target ES6 and preserve JSX, then currently the compiler will not try to rewrite your code and emit things essentially as they are. Of course the future is hard to say... if ES7 introduces things that need to be degraded to work on ES6, then I suspect the TypeScript team will have to introduce an ES7 target.

There seems to be some sort of acceptance too that "micro-targeting" is becoming a necessity, meaning that specific features can be emitted or not. So I say the future holds more control over what what gets emitted, not less.

The one thing you haven't indicated though, is around packaging. Considering that while the module format for ES6 is standardised, the loading and resolution of ES6 modules is a matter of much debate. So I think you need to consider what you would want TypeScript to do or not do around emitting modules.

@johnnyreilly
Copy link
Author

Re: modules, I'm currently experimenting with TSIFY since I'm experienced with (and like) Browserify. That said, I'd be open to using WebPack or something else if TSIFY doesn't work out. As I understand it TypeScript aims to be ES6 compliant and it looks like most of the module story is in place with TypeScript 1.6.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 14, 2015

emitting to es6 should work.

@mhegazy mhegazy added the Question An issue which isn't directly actionable in code label Sep 14, 2015
@johnnyreilly
Copy link
Author

Thanks @mhegazy - I'm making some progress with TSIFY here. At present it doesn't support resolving TSX which should hopefully be fixed by TypeStrong/tsify#76.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 15, 2015

@johnnyreilly would you be interested to put this as a sample in https://github.com/Microsoft/TypeScriptSamples

@mhegazy mhegazy closed this as completed Sep 17, 2015
@johnnyreilly
Copy link
Author

Hi @mhegazy,

Once I've got a working version in place I'll look to do that.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 17, 2015

thanks @johnnyreilly!

@johnnyreilly
Copy link
Author

okay, tsify has some problems but webpack with ts-loader is just what I needed. i'm writing JSX in TypeScript, transpiling with Babel and unit testing with Karma. It's beautiful. You can see the working setup here:

https://github.com/johnnyreilly/globalize-so-what-cha-want

I'll try and create a "hello world" cutdown example that could be used in https://github.com/Microsoft/TypeScriptSamples when I get some free time.

@StreetStrider
Copy link

Hello. The topic is kinda old, I come here from search. Summarizing topicstarter question, I want to ask: is there any way to use TypeScript just for typechecking, similarly like I can use Flowtype's flow check?

…using TypeScript for static typing and handing off transpilation to a 3rd party tool…

I need this type of thing.

I currently want to use TypeScript inside Rollup infrastructure, so I expect Rollup + TS plugin to solve all transpiling work for me (I can even use Babel plugins as topicstarter or another Rollup plugins). I need just a simple tool to do typescript check. Is there a way to do this in 2017?

@hitmands
Copy link

You may have a look on that https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files

@StreetStrider
Copy link

@hitmands, that can be a solution for my case if I can use --checkJs on .ts. Actually, in my case I'm using TS extensively, but I bundle it not with tsc, but with typescript for Rollup. Also it's awesome that TypeScript now supports declarations inside comments (just like FlowType). The whole soft-mode feature is cool now.

@aluanhaddad
Copy link
Contributor

@StreetStrider if you're using TS files just use the --noEmit flag.

@StreetStrider
Copy link

@aluanhaddad great 👍 thank you.

@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