Upgrade to Typescript 1.4

[unintelligible]

The project still seems to reference Typescript 0.9.1.

Are there any plans to upgrade to Typescript 1.3? (Would be happy to help, but it looks like the TS API has changed quite a bit since 0.9.1, and wasn't clear to me which areas would need changing from looking at the code)

[clausreinke]

Actually, the TS version used is somewhere around 1.x (just need to change the reporting). That was roughly the last useable version before they rewrote their whole codebase (the new github variant of TS). 1.3 is indeed the first of those new TS versions that claims to support language services again, so I'm going to target that at some point - just haven't got round to it yet.

There has never been any useful documentation - actually, TS 1.3 is the first time that they made their language services official. So it has always been: look at the sources, especially test harness and batch compiler, to figure out how the services are meant to be used, and all too often, new versions broke the API (as it was considered internal).

Since this was a rewrite, I doubt a simple "compile and fix bugs/API changes" will do. Which is why I haven't allocated the time (yet). Of course, I do want the new features (mostly ES6 stuff, but some of the type system extensions are also interesting), so it is likely going to happen at some point;-)

[HerringtonDarkholme]

One good new is for TS1.4, the doc is available now (sadly not as useful as expectation, though):
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

[Phaiax]

If you need help, contact me :)

[clausreinke]

Just a quick update:
I finally got started this week, first trying to get rid of compilation errors and now slowly moving into semantic changes ("where has this feature gone, what is it called now, how do I invoke it now, and how do the new results/interfaces relate to the old ones, .."). It is frustrating work (especially since I've had to do it again and again since this project started, and because documentation is still not optimal) but I don't think you can help (yet).
I expect to continue in a couple of days, and hope to reach the testing phase at the weekend. Then you may be able to help figuring out whether the test failures indicate real issues or just minor API changes, so I will publish a branch for testing then. Target is to get the whole thing done by the end of January.

[IlanFrumer]

+1

[pocesar]

👍

[clausreinke]

As far as I can tell, the remaining test output differences in this second commit no longer indicate bugs, merely changes in details or undocumented fields. Have a look yourself. So I expect to accept the new test outputs, unless someone here finds any issues I missed. Remaining tasks: code and docs cleanup, then off to real-world testing, I hope.

[HerringtonDarkholme]

Pardon me, but how can I install it? npm install -g gives me an invalid version error.

[clausreinke]

@HerringtonDarkholme seems semver didn't like the '_'. I've also changed the typescript git dependency to something that works for me, but seems terribly wasteful (npm install clones the whole typescript repo). See also microsoft/TypeScript#1818.

[Phaiax]

Hey.
I just looked at the last example here:
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

The LanguageService Object has a function called getEmitOutput. One could use the already parsed code tree to compile (hopefully) faster.

This would need a new command for tss.js and the ability to configure the CompilerOptions via tss.js. (settings source maps, ecma target, ...).

I've looked at the TypeScript source and at your changes and I think I could even implement it by myself, if you think this is a good idea and you do not want to do the work.

What do you think?

[clausreinke]

@Phaiax this isn't related to TSv1.4 support, so I've move it to a separate issue #43.

[clausreinke]

Since typescript now has an ES6 default target, and complains about external modules unless a --module option is set, configuration support (#44) had become urgent. tss now accepts the same commandline flags and tsconfig.json as tsc does (only the language service-related options have any effect). That means we depend on typescript 1.5 now (the current github version).

I think this testing_ts1.4 branch is in good enough shape now that the plugin authors can and should start to give it a try (I'll start on the vim plugin next). If you've stuck to documented non-experimental features, you might not even have to change much at all...

Once I've got the vim plugin going, and the typescript 1.5 package reaches the npm registry, I'll probably publish a new version, too. So, please file separate issues if you find more issues in testing.

[clausreinke]

Still waiting for 1.5 to stabilize and to reach npm registry.

Until then, any fixes/updates go into this branch.

Plugin authors, note these changes in commands marked as experimental:

• structure is gone (as is the supporting LS API method)
• navigationBarItems is new
• navigateToItems is new

The former gives you a structural outline of a file (classes, interfaces, methods, ..), the latter can support generalized jump-to functionality (it interprets the item to jump to modulo case, prefix, substring, and even camelCase initial letters), so both should be interesting to your users.

Both are now also supported in the Vim plugin as well as I could embed them using menus and commandline completion (:TSSnavigate, TSSnavigateTo item).

Support for these is still experimental, but I'd like to keep them around while they are in the LS API.

[danihodovic]

And here I was thinking "yet another outdated ts plugin". Keep up the good work @clausreinke . I'll start testing the 1.4 branch right away

[jomifo]

I tried installing testing_ts1.4, but ran into an issue because the Microsoft/TypeScript repo is listed as a dependency using git+ssh protocol in package.json. Changed to just the git protocol and all worked.

[clausreinke]

@jomifo yes, the github dependency is awkward (apparently, the kinds of bugs change with npm version, changes can result in needless and unnecessarily deep re-clones, and a final fix depends on some ongoing npm feature rewrite). Does

  "dependencies": {
    "typescript": "Microsoft/TypeScript"
  }

work for everyone (should leave npm the choice of protocol)?

[adidahiya]

git+ssh protocol for the TypeScript dependency worked fine for me.

[danihodovic]

Worked for me