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

Clarify over TypeScript Compiler version used / compileOnSave #469

Closed
johnnyreilly opened this issue Jul 16, 2015 · 8 comments
Closed

Clarify over TypeScript Compiler version used / compileOnSave #469

johnnyreilly opened this issue Jul 16, 2015 · 8 comments
Labels

Comments

@johnnyreilly
Copy link
Member

Hi Folks,

First of all, thanks for your hard work with atom-typescript - it's amazing.

A little background on where I am. I'm just working out the best way to plug atom-typescript into my a current work project. This project is presently is written in React / ES6 and uses Babel with Browserify to transpile to ES5.

So that everyone remains on board with the migration I need to tread delicately and respect certain approaches used in the codebase. What this means is:

  1. Do not use atom to do the TS compilation. Instead this will probably be handled by @smrq's TSIFY. So atom-typeScript just provides the nice tooling but doesn't actually generate JS files. I think "compileOnSave": false has my back here but I'm not certain - is that right?
  2. Use a specify version of the TypeScript compiler (1.5-beta probably for now). It's unclear to me which version of the TypeScript compiler atom-typescript uses. Is it driven by the version in tsconfig.json? Or is that just an aide memoire?

I've been reading up the docs but the answers to the points raised above aren't too obvious to me. I'd be happy to update the atom-typescript documentation to clarify it once I know.

@johnnyreilly johnnyreilly changed the title Clarify over TypeScript Compiler version used Clarify over TypeScript Compiler version used / compileOnSave Jul 16, 2015
@basarat
Copy link
Member

basarat commented Jul 17, 2015

I think "compileOnSave": false has my back here but I'm not certain - is that right

Yes. (https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md#i-dont-want-atom-typescript-compiling-my-js)

Use a specify version of the TypeScript compiler (1.5-beta probably for now). It's unclear to me which version of the TypeScript compiler atom-typescript uses. Is it driven by the version in tsconfig.json? Or is that just an aide memoire?

No. Its ntypescript https://github.com/TypeStrong/atom-typescript/blob/master/package.json#L55 which is just a build of Microsoft/Master : https://github.com/TypeStrong/ntypescript

I'd be happy to update the atom-typescript documentation to clarify it once I know.

Faq would be a good place (https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md) to mention ntypescript. Although perhaps we will move to TypeScript nightlies which is something that the TypeScript team is planning 🌹

@nycdotnet
Copy link
Contributor

I've actually got a related question. Even in ntypescript/TypeScript 1.5, there will still be some ES6 stuff that doesn't transpile properly to ES5. One particular thing I'm thinking of is using let to declare the iterator of a for loop. If you reference the iterator in a function declared within the loop body, it's an error unless you're in ES6 mode because TypeScript can't (yet) transpile the new scope per iteration behavior into ES5. Babel can do this.

I was wondering if you'd have any interest to optionally support Babel from within atom-typescript as an optional alternate transpiler. I'm picturing the output of the TS language service being delivered to babel which would then actually do the writing to disk. Does this sound feasible?

@basarat
Copy link
Member

basarat commented Jul 17, 2015

I was wondering if you'd have any interest to optionally support Babel from within atom-typescript as an optional alternate transpiler. I'm picturing the output of the TS language service being delivered to babel which would then actually do the writing to disk. Does this sound feasible

Its actually somewhat trivial to do this. But I'm very biased in adding the transpilation features to TypeScript (and they will happen anyways). The ts source code is pretty fun to read (and I'm in the process of documenting during commutes http://basarat.gitbooks.io/typescript/content/docs/compiler/overview.html) ;)

I also plan to streamline TypeScript's workflows for using TypeScript as a first class non typed TS (aka JavaScript).

Motivation : like I said ... the ts compiler source code is easier to read than babel at least for me

@johnnyreilly
Copy link
Member Author

Cool - thanks for the response. I'll try and raise a docs PR soon.

The version thing is interesting. Atom will always be using the latest and greatest TS whereas TSIFY will be using (for now 1.5-beta). That's probably fine as long as I restrict myself to using lowest common denominator features (ie what TSIFY is using).

I had a first go using Babel/browserify/TSIFY and atom-typescript in concert. Got 90% of the way there. Unfortunately external dependencies aren't resolving with TSIFY whilst they are with atom.(screaming silently) I think this may be a bug with TSIFY though:

TypeStrong/tsify#60

Thanks chap.

johnnyreilly added a commit that referenced this issue Jul 18, 2015
Add clarity to the docs around version and not generating JS.  Raised to handle #469
@vjau
Copy link

vjau commented Jul 23, 2015

What's the difference between "compiOnSave" : false, and the compiler "noEmit" option ?

@basarat
Copy link
Member

basarat commented Jul 23, 2015

What's the difference between "compiOnSave" : false, and the compiler "noEmit" option

"compiOnSave" : false, is IDE only (and in fact atm atomts only). compiler "noEmit" option disables it for all tools (including atomts although we might show an error message like no emit was done instead of thinking that this is exactly what the user ordered)

@basarat
Copy link
Member

basarat commented Jul 27, 2015

closing issue to keep queue smaller. Feel free to continue any discussion here if you want 🌹

@basarat
Copy link
Member

basarat commented Sep 28, 2015

I've removed the (unused and unrespected ... purely for documentation) version option, as it confuses other people as well (with good reason) #617 🌹

@TypeStrong TypeStrong locked and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants