-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Comments
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. |
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. |
emitting to |
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. |
@johnnyreilly would you be interested to put this as a sample in https://github.com/Microsoft/TypeScriptSamples |
Hi @mhegazy, Once I've got a working version in place I'll look to do that. |
thanks @johnnyreilly! |
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. |
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
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 |
You may have a look on that https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files |
@hitmands, that can be a solution for my case if I can use |
@StreetStrider if you're using TS files just use the |
@aluanhaddad great 👍 thank you. |
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).
The text was updated successfully, but these errors were encountered: