All 38 comments
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.
w0rp
on 3 Oct 2016
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?
prashcr
on 3 Oct 2016
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
on 3 Oct 2016
I just remembered that I actually already wrote such a Bash wrapper script. I forgot that I did that.
w0rp
on 3 Oct 2016
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)
prashcr
on 4 Oct 2016
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.
w0rp
on 4 Oct 2016
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
on 4 Oct 2016
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 .
prashcr
on 4 Oct 2016
Let me know how you get on. Sounds good to me. :+1:
w0rp
on 4 Oct 2016
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.
neersighted
on 14 Oct 2016
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.
w0rp
on 14 Oct 2016
@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.
prashcr
on 18 Oct 2016
Sounds good to me!
neersighted
on 18 Oct 2016
the problem with tsuquomy that it sends requests to tsserver synchronously: https://github.com/Quramy/tsuquyomi/blob/master/autoload/tsuquyomi/tsClient.vim#L335
mkusher
on 1 Nov 2016
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.
w0rp
on 1 Nov 2016
@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
mkusher
on 1 Nov 2016
If NeoVim doesn't support socket connections, then we'll have to make it a Vim 8 only feature.
w0rp
on 1 Nov 2016
mkusher
on 1 Nov 2016
@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...
mkusher
on 2 Nov 2016
Can't we have just a simple wrapping of tsc right now? As a first step, I mean...
pinver
on 9 Nov 2016
Yeah, we could do. Feel free to give it a go.
w0rp
on 9 Nov 2016
@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 :(
mkusher
on 9 Nov 2016
Look at Neomakes implementation for tsc if it is applicable, runs fast on both Windows and OSX.
Handles tsconfig just fine.
JohanBjoerklund
on 9 Nov 2016
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
kyrisu
on 4 Dec 2016
See https://github.com/neomake/neomake/blob/master/autoload/neomake/makers/ft/typescript.vim for a "simple" tsc config.
blueyed
on 15 Dec 2016
@blueyed it doesn't work right, because tsc doesn't look for tsconfig.json, when file is specified...
mkusher
on 15 Dec 2016
@mkusher
There is no file specified in this case (append_file).
blueyed
on 15 Dec 2016
@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
mkusher
on 17 Dec 2016
Not compiling the whole project breaks the tsc checkers because the compiler can't resolve imports, know about type definitions etc without any context.
JohanBjoerklund
on 17 Dec 2016
@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
mkusher
on 17 Dec 2016
But you'll loose the context given by the tsconfig file. Those settings are crucial.
JohanBjoerklund
on 17 Dec 2016
@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
mkusher
on 17 Dec 2016
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
on 3 May 2017
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 (https://github.com/Microsoft/TypeScript/issues/11274).
jason0x43
on 31 May 2017
For future reference: To use the new direct interface to tsserver and get similar functionality to tsuquyomi, use
let g:ale_linters = {
\ 'typescript': ['tsserver'],
\}
ghost
on 18 Sep 2017
That isn't necessary. tsserver support is enabled by default for typescript files.
w0rp
on 18 Sep 2017
I didn't see tsserver output, since the eslint output was on top. tsserver is better, though.
ghost
on 18 Sep 2017
There is also https://github.com/autozimu/LanguageClient-neovim which also supports tsserver, but also other features (like multilanguage refactorings)
Industrial
on 2 Feb 2018
Related issues
glepnir
路
3Comments
garand
路
4Comments
lervag
路
3Comments
trevordmiller
路
3Comments
sublee
路
3Comments
Most helpful comment
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.