-
Notifications
You must be signed in to change notification settings - Fork 205
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
Comments
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
Faq would be a good place (https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md) to mention |
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? |
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 |
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: Thanks chap. |
Add clarity to the docs around version and not generating JS. Raised to handle #469
What's the difference between "compiOnSave" : false, and the compiler "noEmit" option ? |
|
closing issue to keep queue smaller. Feel free to continue any discussion here if you want 🌹 |
I've removed the (unused and unrespected ... purely for documentation) |
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:
"compileOnSave": false
has my back here but I'm not certain - is that right?version
intsconfig.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.
The text was updated successfully, but these errors were encountered: