Please consider splitting Visual Studio into a separate GitHub project

[NoelAbrahams]

With the proliferation of IDEs for writing TypeScript it is becoming increasingly incongruous to raise VS issues on the TypeScript GitHub project.

The failure to release a VS update for the 1.5 alpha leaves VS users in a rather sorry state.

I propose a dedicated GitHub project for the TypeScript Visual Studio plugin, with dedicated people to ensure a VS release is made available for every single TypeScript release, and also to ensure the VS plugin remains competitive in the current environment.

We are fast approaching a stage where we use VS for only TypeScript and switching to alternatives is probably viable for many in our position.

[DanielRosenwasser]

@NoelAbrahams, it sounds like you are mainly concerned with our frequency of releases alongside Visual Studio, though you mention

it is becoming increasingly incongruous to raise VS issues on the TypeScript GitHub project

Can you give any specific examples of this?

[NoelAbrahams]

@DanielRosenwasser,

When I say "incongruous" I meant that there are many users here who use other IDEs.

My post was prompted primarily by the failure to release 1.5 alpha for VS.

That just serves to reinforce the impression that VS is now less important. (I was surprised by the fanfare around something called "a sublime text plugin". I wonder how many companies are actually compelled to use that?)

For specific issues, I would say #11 should have been fixed a long time ago. There should have been NPM integration, TypeScript unit test projects etc.

[RyanCavanaugh]

With Roslyn and .NET being OSS now we've been thinking about whether it would be possible to put the Visual Studio component on GitHub. It's certainly incongruous to have the uninteresting 'glue' part of the VS TypeScript experience be closed-source when everything else is open. That said, we do work in a large company 🐌 where that requires lots of approval and red tape to make that happen, so it does need some kind of obvious pay-off to justify the work.

[mhegazy]

My post was prompted primarily by the failure to release 1.5 alpha for VS.

TypeScript ships in-box with Visual Studio, with dependencies on other VS components. That means it ships on VS scheduled; and the Typescript team has no control over that.

1.5 is our biggest release yet, and have packed it with new features. We had two options, wait until a VS release is out to get users to try it out, or get an alpha out on npm and incorporate feedback into the next VS release. and we chose the latter. So far we have got good bug reports and we are working on fixing them.

That just serves to reinforce the impression that VS is now less important.

Over the past year we have delivered a complete rewrite of the TypeScript plugin in Visual Studio with a whole release dedicated to VS experience. We have completely revamped the TypeScript authoring experience in VS. We still have a good portion of the TypeScript team fully dedicated to the TypeScript experience in Visual Studio.

We have also made sure that VS users can always update their language service to the latest TypeScript bits from master if they opt into the dev mode.

I was surprised by the fanfare around something called "a sublime text plugin".

Tooling has been an important part of the TypeScript value proposition. Our architecture has been based on allowing different tools to utilize Typescript. the sublime text plugin is just another demonstration of that. And so is our public API and tsserver, integration with web editors and our npm package.

For specific issues, I would say #11 should have been fixed a long time ago. There should have been NPM integration, TypeScript unit test projects etc.

I agree. Library projects (and P2P in general) is specifically something that we always talk about. Over the last year we have invested in a lot of infrastructure work, almost rewriting everything we have shipped in 1.0 while still delivering new features. it is just that these are large undertakings and you need to lay some ground work before tackling them.

I propose a dedicated GitHub project for the TypeScript Visual Studio plugin

As @RyanCavanaugh mentioned we have and still are considering this.

[NoelAbrahams]

TypeScript ships in-box with Visual Studio, with dependencies on other VS components. That means it ships on VS scheduled; and the Typescript team has no control over that

That is the problem. What's the point of a plugin if every release of the plugin requires a corresponding release of the host? The experience of installing the complete Visual Studio is not ideal; installing VS 2015 CTP5 took up two hours of my time. When other IDEs install in 5 minutes then there is a reason for people to start considering alternatives.

Over the past year we have delivered a complete rewrite of the TypeScript plugin in Visual Studio with a whole release dedicated to VS experience. We have completely revamped the TypeScript authoring experience in VS.

A piece of software is only as good as the last release. I am disappointed that I am not able to try out the new features from the 1.5 alpha.

We have also made sure that VS users can always update their language service to the latest TypeScript bits from master if they opt into the dev mode.

This is normally quoted as an alternative. But it's just not feasible to require everyone to fiddle with registry settings when one is working in a team.

I hope these comments are taken in the best possible light. I think VS is an outstanding product and would like to see these user experience issues (with installation and release management) addressed.

[CyrusNajmabadi]

@NoelAbrahams I'm not sure how moving any part of TypeScript to another github project solves any of the issues you are concerned about.

The experience of installing the complete Visual Studio is not ideal; installing VS 2015 CTP5 took up two hours of my time.

Moving TS VS support into another GitHub project will not change that in any way.

I am very disappointed that I am not able to try out the new features from the 1.5 alpha.

I understand your disappointment. But moving to another GitHub project will not have changed that.

This is normally quoted as an alternative. But it's just not feasible to require everyone to fiddle with registry settings when one is working in a team.

Could you expand on this. Why is it not feasible? It should take a minute for someone to do this. There is even a provided powershell script to do this in seconds. And now you can try out the latest bits.

[yahiko00]

It would be nice if in Visual Studio we could customize the TypeScript Language Services source code location like in Web Storm. This would have allowed VS users (I'm part of them) to try the 1.5 alpha...

[NoelAbrahams]

@CyrusNajmabadi,

I would look at the NTVS project on GitHub as an example. The TS plugin should be independent of the Visual Studio release cycle.

If we look at the issue list for NTVS, they are all (naturally) dedicated to Visual Studio. The suggestion is to have a similar team dedicated to VS-only issues.

Could you expand on this. Why [manual installation] is it not feasible?

We want to avoid situations of "A: This is not compiling" "B: Go check your registry, if that fails go fiddle with x, y, z".

[DanielRosenwasser]

@yahiko00 that is precisely what Dev Mode enables. See Using a custom language service file

[yahiko00]

@DanielRosenwasser Oh, thanks a lot! I didn't know this Dev Mode.
Let's just hope this would be a little bit more user friendly than editing the registry later.

[CyrusNajmabadi]

@NoelAbrahams I think an important part of my response was missed. Could you clarify how moving to another github project would actually solve the issues you're complaining about? Your post merely reiterates that this is what you would like to happen, but it fails to address how doing this will actually address the issues.

The TS plugin should be independent of the Visual Studio release cycle.

The TS plugin has components that are VS version neutral, and which can be updated independently of the VS release cycle. The parts have already been mentioned, and links have already been provided that enable you to update them if you want to. That functionality exists today and is available to you.

The TS plugin also has components that depend on parts of VS, and thus are tied to the VS release cycle. For example, unsurprisingly, we depend heavily on the VS extensibility SDK. We also depend heavily on the Roslyn project. Indeed, it's because of that dependency that we were able to 'light up' so many nice features as briefly outlined here: http://blogs.msdn.com/b/typescript/archive/2014/11/12/announcing-typescript-1-3.aspx

Because of this, we have concurrent development and release cycles. When VS ships it carries the appropriate TS components with VS dependencies with it. It also carries our latest stable components that are VS neutral.

Then, in the interim period between VS releases, you can still update the VS neutral components so you can try out some of our latest works, without needing to wait for VS to ship that version with it.

So, back to your request. Moving to a new github project won't address your complains because:

1. If all you want is the latest VS neutral components, you can already get that today with the main project, and another project wouldn't affect that.

2. If you want the VS specific components, then a new github project still won't be able to ship faster because it will fundamentally be gated on when VS releases. These components clearly can't ship faster than VS does, because they depend on VS functionality that won't be there until the next VS release.

[CyrusNajmabadi]

@NoelAbrahams

We want to avoid situations of "A: This is not compiling" "B: Go check your registry, if that fails go fiddle with x, y, z".

I don't see how moving to another github project changes that. The conversation will simply transition to:
"A: this is not compiling" "B: what version of the TS plugin do you have installed? Oh, go uninstall that one and go install this other one instead."

[NoelAbrahams]

@CyrusNajmabadi,

The point is your team is there to provide a service to users. And I as a user am not happy.

Let me put it this way: If I go to a nice hotel and the receptionist books me in, but then hands me some sheets and asks me to go make my own bed then I'm not going to be very happy. That is the effect your response has on me - I don't really care about the problems the hotel is having: I just want good service.

I am merely suggesting that having a dedicated GitHub project may ensure that VS users get better attention.

When I go to a nice hotel I expect good service. If I don't get that service I go to another hotel.

[mhegazy]

@NoelAbrahams, we have heard your feedback, and we will definitely keep it in mind as we are planning future releases. We are sorry for any frustration this release might have caused. Please do keep sending your feedback our way; we are always looking to making the TypeScript experience better.

[jbondc]

Have to agree with @NoelAbrahams, would be nice to see the Visual Studio plugin as its own github project. Just recently:

While dev mode is nice, where do I report errors as I mess with language service or discover bugs? Even better would be open sourcing the plugin or part of it to understand what's happening.

[jbondc]

And just now:

[DickvdBrink]

I understand @CyrusNajmabadi points and I'm glad he posted them here!
As a user I'm actually pretty happy and when I want to try new TypeScript language features I just enable them with the VSDevMode.ps1 script like someone already mentioned above. It might not be ideal but it works well (last time I tried).

While dev mode is nice, where do I report errors as I mess with language service or discover bugs? Even better would be open sourcing the plugin or part of it to understand what's happening.

You can call host.trace and check the output with for example DbgView which works pretty well for me. If you have issues I think you can post them on the issue tracker and the TypeScript team is pretty helpful in my opinion. If you have the above errors with latest master it might be that the API isn't fully compatible and then you are out of luck though. I did hack some stuff on the language service lately and when I had these errors you've shown above it was because I made some mistakes in my code, the tracing really helped me here.

[DanielRosenwasser]

While dev mode is nice, where do I report errors as I mess with language service or discover bugs?

On this repository; please report bugs here for anything that you catch - we have a Visual Studio label for issues.

If you're not familiar with @DickvdBrink's suggestion, you can Ctrl+C any dialog box that comes up and paste the relevant output into the issue along with repro steps. You can also check error events in the Event Viewer by going to Windows Logs > Applications.

[CyrusNajmabadi]

where do I report errors as I mess with language service or discover bugs?

In the Microsoft/TypeScript project.

Even better would be open sourcing the plugin or part of it to understand what's happening.

That would definitely be nice to have. It's something we're looking into.

[CyrusNajmabadi]

@jbondc Can you please file bugs on the asserts you're seeing. Ideally, please include the relevant Event Viewer information when this happens. There should usually be two items (back to back) in the even viewer. One giving information on the crash, and one giving information on the data submitted to MS about the crash. With that we can attempt to track down what happened.

[jbondc]

@CyrusNajmabadi @DanielRosenwasser thanks #2744

[voltcode]

Has this been considered lately? Currently VS2013 does not have TS 2.0 support, it would be great to let the community add it for the glory of TS.

[RyanCavanaugh]

We're transitioning toward Language Service Protocol in the long-term and hopefully the "VS" component of TS eventually vanishes into an uninteresting thin layer. This is still on our radar but not something we're going to be able to make a commitment on until some other things outside our control move.