Typescript 1.1 support

[bestander]

Typescript 1.1.0-1 is out. A lot of gulp plugins depend on this repo. Possible to update to 1.1?

[jednano]

There's only one gulp plugin that depends on this repo and that's gulp-typescript. gulp-typescript-compiler is blacklisted.

Now that the facts are straight, I'm as eager as you to get support for 1.1, but I'm also not able to devote time to this anytime this week, so it might be a while.

[pspeter3]

I would really appreciate it if we upgraded this and gulp-typescript is there anything I can do to help? Eg, will you take a pull request?

[jednano]

See https://github.com/ivogabe/gulp-typescript/pull/26

[jednano]

And yes, I would take a pull request.

[svallory]

@jedmao I just pushed a new version of typescript-compiler. Instead of monkey patching typescript, I'm now compiling the source with some additions. You can take a look and copy some code over to typescript-api, but maybe we should join forces. What do you think?

@gavinhungry what you think?

[gavinhungry]

@svallory What "additions" are you working with? I am far from familiar enough with the TypeScript compiler internals or API to make a reasonable assessment, which is why typestring relies on typescript-api. I defer to @jedmao.

[jednano]

@svallory I'm not comfortable with those "additions" either. My intent here was to expose the TypeScript API without touching it in any way, shape or form. Don't hold your breath for a TS 1.1 or 1.3 update either. I'm holding out for TS 1.4's Language Service public API and I suggest you all use gulp-typescript in the interim. I'm using it myself on my projects now and I give major props to @ivogabe for his work there. It's an excellent plugin.

Since this ticket was originally created, in such a short time, we're already at TS 1.3. Let's countdown to TS 1.4!

[svallory]

@gavinhungry and @jedmao I didn't make any changes to typescript itself I just reference it. The additions are simply the [CompositeCompileHost](), the compile, compileString and compileStrings functions and some classes for type checking.

The typescript compiler is written in typescript. So what I did was reference typescript and compile to a single file. That strategy beats monkey patching every time. It's much more sustainable.

[svallory]

btw, the tests I've written make sure the output is exactly the same as the generated by the command line tsc compiler.

[jednano]

Yeah, and those additions that you've pointed out are doing too much. The intent of this project was to expose the API... period! Zero else. This way, people can use it however they want. If you have a better thing going on, I suggest you have a separate project that does nothing else but expose the api and your existing project would depend on that one and extend it with your additions.

[svallory]

I was just trying to help. The purpose of typescript-compiler project is to expose simple compile methods. So it is not doing too much. I though we could start an organization with different typescript related packages for different needs. That's all. Anyway, my code is still open source and if you want to move away from monkey patching, be my guest.

[jednano]

I realize you're trying to help and your goal to expose simple compile methods is a noble one. I know you feel that's not doing to much, but we'll have to disagree about that. What happens if someone else decides to create simple compile methods that are just a bit different than yours? Maybe they pass-in arguments differently? Maybe the function names are a bit different. Maybe they think their version is better than yours. My point is that your library is doing 2 things, which is 1 too many. One thing is to expose the API. The other is to extend it.

[flcdrg]

I'm interested in getting this working with TypeScript 1.4. Any reason not to try doing this?

[jednano]

@flcdrg that depends on what you intend to do with it. Is there any reason gulp-typescript can't do what you're trying to do? What's your goal?

[flcdrg]

I'm looking to support building typescript in ember-cli. I'm open to alternatives, but I ended up here via broccoli-typescript

-----Original Message----- From: "Jed Mao" notifications@github.com Sent: ‎26/‎02/‎2015 5:37 PM To: "jedmao/typescript-api" typescript-api@noreply.github.com Cc: "David Gardiner" david@gardiner.net.au Subject: Re: [typescript-api] Typescript 1.1 support (#1)

@flcdrg that depends on what you intend to do with it. Is there any reason gulp-typescript can't do what you're trying to do? What's your goal? — Reply to this email directly or view it on GitHub.

[ivogabe]

You can also just require('typescript'), in version 1.4 a public api is exposed.

[flcdrg]

Yeah, I reckon that might be the easiest path.

On 26 February 2015 at 19:16, Ivo Gabe de Wolff notifications@github.com wrote:

You can also just require('typescript'), in version 1.4 a public api is exposed.

— Reply to this email directly or view it on GitHub https://github.com/jedmao/typescript-api/issues/1#issuecomment-76141658.

[gavinhungry]

@svallory @flcdrg The TypeScript 1.4 API is reasonable easy to work with - I've updated https://github.com/gavinhungry/typestring to use it, instead of typescript-api. Maybe my crappy module will provide what you need.

[flcdrg]

You are correct - it was pretty straight forward to use. I've managed to get something working in https://github.com/flcdrg/ember-cli-typescript

Thanks for the suggestions!

[svallory]

Thanks @gavinhungry! I tryed that, but the api doesn't expose all I need :/ I've implemented a compilation method which accepts a custom compiler host and it now works even on Rhino :) But to do that I had to stick to compiling my package with the typescript source