Add checkers for TypeScript

[dense-analysis]

Add checkers for TypeScript

[w0rp]

I'm going to forego the tsuquyomi integration in favour of implementing a Language Server Protocol client and a TypeScript linter which uses it, in the next milestone.

[w0rp]

For TypeScript, we need to connect to the server for checking TypeScript. The tsuquyomi) plugin somehow handles this. It might be best to submit pull requests to support using job control instead of vimproc in that plugin, and another pull request adding an ALE linter. We would need to support socket connections, in addition to commands. I'm not sure if NeoVim can handle that.

For future reference: To use the new direct interface to tsserver and get similar functionality to tsuquyomi, use

let g:ale_linters = {
\   'typescript': ['tsserver'],
\}```

[w0rp]

I'm totally in favour of this. I think I'm generally in favour of adding more support for linting everything. I'll probably start using TypeScript personally soon enough.

[prashcr]

Great!

tslint

Style checking
Just needs stdin wrapper, pretty straightforward.
Out of curiosity, what's the rationale behind requiring linters to accept stdin?

tsc

Syntax and type checking
tsc is the official typescript compiler, however it's really slow (takes 2 seconds for a hello world).

TypeScript also comes with a tool called TSServer which uses some caching magic to run the same checks extremely fast, at the cost of a few hundred ms at startup. Aside from checking, it also adds intellisense autocomplete. This is what's used in Sublime/VS Code/WebStorm.

tsuquyomi

This plugin wraps TSServer and makes it really easy to use.
However, this uses vimproc.vim, an async task runner, to populate the quickfix list.

Syntastic's approach to this problem was to add a syntastic checker in the tsuquyomi repo itself and add an option to disable tsuquyomi's use of the quickfix list.

I'm not sure how to approach this.
Do we just use tsuquyomi and accept that people need to install an async task runner when they're already using vim 8? And do we try and integrate changes into their repo so that we can feed its output directly into ALE?
On the other hand, directly wrapping TSServer also seems like too much work that shouldn't belong here.
Maybe we should fork tsuquyomi to use vim8 async?

[w0rp]

I suppose we'd need to rewrite what tsuquyomi does to use the new Vim 8 functionality. It probably used vimproc because the new async functions weren't available at the time.

The linters need to accept stdin input because we need to be able to send the text for files which are open without first saving the files back to disk. The linting is applied by sending the contents of the text buffer directly to a given program. I might write a Bash wrapper script will could be used for sending input to most programs. Then eventually I might add a Batch wrapper script for Windows, which will be... interesting.

[w0rp]

I just remembered that I actually already wrote such a Bash wrapper script. I forgot that I did that.

[prashcr]

I'd like to still keep track of this, because TSLint only handles style checks but not compile/type checks which are the main selling point of TypeScript.

For the latter one needs to still install vimproc,tsuquyomi then use :w to check. (Even though vimproc provides async, it just means that vim doesn't freeze when makeprg is run instead of lint-as-you-type)

[w0rp]

I'll re-open this one then. I wonder if TypeScript has something like switch for checking semantics without producing output. That's what I set up for D with the reference D compiler.

[prashcr]

Ah, that's a great idea. It does have a switch for that. I'll try using that and seeing if perf is acceptable

[prashcr]

Unfortunately disabling output had no effect on linting speed, still too slow.

On the bright side, I noticed that not many files in the Tsuquyomi project use vimproc, and they use it for job control. I'll try forking it and making it work with vim8 jobs intstead .

[w0rp]

Let me know how you get on. Sounds good to me. 👍

[neersighted]

You know, maybe my machine is just a lot faster than yours, but for me, the hello world takes 0.8 seconds (slow, but not ungodly), and a large TS project takes 3 seconds. I don't really see an issue with tsc as long as compile times are around a second for a file.

[prashcr]

@neersighted It is indeed. hello world with tsc takes 2.3 seconds for me. However on the same machine, Tsuquyomi runs and gives me the same errors in 0.2 seconds. I think an improvement of that scale is definitely worth shooting for.

Besides, from the experience of myself and a few others, nobody will use vim and TypeScript without Tsuquyomi as it provdes many other features including omnicomplete, refactoring, jump to definition, show usages, YouCompleteMe integration, Unite.vim integration, etc.

So the only real solution IMO would be to submit PRs or make a fork. I don't have the time currently, but I may give it a try in the coming few months.

[neersighted]

Sounds good to me!

[mkusher]

the problem with tsuquomy that it sends requests to tsserver synchronously: https://github.com/Quramy/tsuquyomi/blob/master/autoload/tsuquyomi/tsClient.vim#L335

[w0rp]

We might just have to connect to the TypeScript server ourselves. The only problem is, I find it hard to find any documentation describing 1. How to start the TypeScript server. 2. Which ports to connect on. 3. What the message format is.

[mkusher]

@w0rp this info we can get from tsuquyomi, but does neovim have same api for async sockets as vim8? And what format will be used for tsc linter? I think we need to specify viml function that accepts callback

[w0rp]

If NeoVim doesn't support socket connections, then we'll have to make it a Vim 8 only feature.

[mkusher]

@w0rp neovim/neovim#4479

[mkusher]

@w0rp https://github.com/Microsoft/TypeScript/wiki/Standalone-Server-%28tsserver%29#message-format
so, no need to use http, but implementing whole protocol might be too difficult just for type checking...

[pinver]

Can't we have just a simple wrapping of tsc right now? As a first step, I mean...

[w0rp]

Yeah, we could do. Feel free to give it a go.

[mkusher]

@pinver I've made simple ts script that runs compiler check instead of using tsc, because tsc ignores tsconfig if the file passed to it. The problem is that it may take 5 seconds for script to finish :(

[JohanBjoerklund]

Look at Neomakes implementation for tsc if it is applicable, runs fast on both Windows and OSX.
Handles tsconfig just fine.

[kyrisu]

I've added a quick change to the tslint linter so it looks for the nearest tslint.json config. Let me know what you think.

Full request for the change: #198

[blueyed]

See https://github.com/neomake/neomake/blob/master/autoload/neomake/makers/ft/typescript.vim for a "simple" tsc config.

[mkusher]

@blueyed it doesn't work right, because tsc doesn't look for tsconfig.json, when file is specified...

[blueyed]

@mkusher
There is no file specified in this case (append_file).

[mkusher]

@blueyed oh, I see. Yeah, it should work, but it might be very slow to compile and type check whole project instead of one file

[JohanBjoerklund]

Not compiling the whole project breaks the tsc checkers because the compiler can't resolve imports, know about type definitions etc without any context.

[mkusher]

@JohanBjoerklund compiler doesn't need whole project, it can just compile file and all it's deps, like it would do if you just specify file

[JohanBjoerklund]

But you'll loose the context given by the tsconfig file. Those settings are crucial.

[mkusher]

@JohanBjoerklund yep, I've created simple package that would do the trick https://github.com/mkusher/ts-checker
but it's still slow comparing with tsserver

[jason0x43]

I'm a bit late to the game, but...

I have a plugin similar to tsuquyomi called vim-tss that uses the native neovim job API for async. That might be worth looking at.

Also note that tsserver doesn't itself implement the Language Server Protocol (microsoft/TypeScript#11274).

[w0rp]

That isn't necessary. tsserver support is enabled by default for typescript files.

I didn't see tsserver output, since the eslint output was on top. tsserver is better, though.

[Industrial]

There is also https://github.com/autozimu/LanguageClient-neovim which also supports tsserver, but also other features (like multilanguage refactorings)