Clarify over TypeScript Compiler version used / compileOnSave

[johnnyreilly]

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.

[basarat]

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]

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]

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]

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.

[vjau]

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

[basarat]

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]

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

[basarat]

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