Basic TypeScript support #259

Closed
wants to merge 4 commits into
from

Projects

None yet

7 participants

@FunkMonkey

I added basic typescript support.

It is probably still a little buggy, but I wanted to post it, so others can start hacking on it ...

It uses the TypeScript BatchCompiler, as I thought it would be easer for parsing the config options later.

This example should trigger two errors:

class Greeter {
   constructor(public greeting: stringd) { }
   greet() {
       return "<h1>" + this.greeting + "</h1>";
   }
};sdfsdf
var greeter = new Greeter("Hello, world!");
var str = greeter.greet();
document.body.innerHTML = str;

Have fun ...

@FunkMonkey FunkMonkey closed this Oct 7, 2012
@FunkMonkey

Note to myself and interested: this way of doing it is too painful.

Instead of using BatchCompiler, we should just use "typescript.js", but get the correct IOHost (IO.getNodeIO) and OutputParser [edit: don't really need it] from "tsc.js". Also using setErrorCallback is a much better idea. should have done it like that in the first place.

I will pursue this task this week, but i dunno how much time i'll have ...

@jswartwood
Member

Have you looked at how we do node linters (currently)? If not, checkout jslint, jshint, and csslint.

@FunkMonkey

Yes I did. I based my work on csslint.

One problem though: It seems linter.js is reparsed and run by node every time linting should happen. This will become a problem for TypeScript as one TS file may depend on a lot of other files that won't change most of the time. Completely reparsing the whole TypeScript "project" every time seems like a bad idea. I guess we will have to find a custom solution where some state is preserved per Sublime-Project for the whole session ...

@FunkMonkey FunkMonkey reopened this Oct 9, 2012
@FunkMonkey

Okay. I have completely rewritten it and it should work much better now. Dependencies are parsed as well. This will be a problem for huge projects, because everything is reparsed on every lint. So we have to find a way of storing state per project.

Weirdly enough, only the "save-linting" appears to update the errors. "edit-linting" shows the same errors - even when corrected - , although everything is done in the lint function. Any ideas on this one?

One last thing: config options are totally missing now (for example the option for switching between es3 and es5 mode).

[edit] I just found out that the TypeScript source code also contains "services", which may be better suited for the task. The biggest downside at the moment, that the parser errors have to be parsed from strings, whereas the typecheck-errors are handled via an errorcallback. seems to be a bug in typescript ...

@jswartwood
Member

I would definitely love to see this pull in soon, but unfortunately due to its complex nature, it will not be in the next release. Perhaps v1.6.10. We will definitely need to have a fairly solid setup for parsing entire projects; a cache strategy may be worth pursuing. Erlang will also have to manage dependencies. Perhaps we should align these approaches (despite their differences).

As an aside... I had a rough proposal to setup a beta/edge branch in Package Control. Another channel would give us the ability to provide and test pulls like this earlier without as much risk of crashes or high cpu/memory usage for the larger community.

@FunkMonkey

I totally agree.

I am not entirely sure yet, but I will probably start developing a code-intel plugin for TypeScript. Obviously there is some code that should be shared between the TypeScript plugin and the SublimeLinter TypeScript linting and maybe even some connection between the two (at least when they are both installed, if only SublimeLinter is installed it would use a cut-down version of the code that only provides linting), so that the same work isn't being done twice.

Though I will probably wait a little to see if the Playground gets open-sourced so I can get a better understanding of how the code-intel works.

@rse
rse commented Dec 1, 2012

This TypeScript support for SublimeLinter is very useful. Please pull the changes into at least the BETA channel of SublimeLinter as soon as possible so people can more easily leverage from it. Thanks!

@rictic
rictic commented Jan 7, 2013

Adding my voice of support for this functionality.

@seanhess

I'd like to use this too!

@FunkMonkey

Not sure if it makes sense anymore to integrate this into SublimeLinter. Maybe you should use Sublime-Typescript, which also provides autocomplete-support...

@seanhess

Yes, I agree. Just trying to find a project that works though :)

On Fri, Feb 22, 2013 at 10:48 AM, FunkMonkey notifications@github.comwrote:

Not sure if it makes sense anymore to integrate this into SublimeLinter.
Maybe you should use Sublime-Typescripthttps://github.com/raph-amiard/sublime-typescript,
which also provides autocomplete-support...


Reply to this email directly or view it on GitHubhttps://github.com/SublimeLinter/SublimeLinter/pull/259#issuecomment-13957982.

@maxbrunsfeld

I think this functionality belongs in SublimeLinter despite the existence of Sublime-Typescript. I'd like to have the same linting experience for typescript as for other languages, rather than using a different plugin just for typescript.

@FunkMonkey FunkMonkey referenced this pull request in stoffera/sublimetext2-typescript-plugin Nov 12, 2012
Open

Offering help #2

@aparajita

Any chance you could implement this for SublimeLinter 3?

@FunkMonkey

As I see it, TS and SublimeLinter don't really fit as SublimeLinter is more focused on linting single files. If you want typescript support for Sublime, you should probably take a look at a more complete solution like T3S.

@FunkMonkey FunkMonkey closed this Dec 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment