wincent
commented
5 years ago When I directly interact with tsserver it agrees with tsc that there are no errors:
$ tsserver
Content-Length: 76
{"seq":0,"type":"event","event":"typingsInstallerPid","body":{"pid":91220}}
{"seq":1,"type":"quickinfo","command":"open","arguments":{"file":"/Users/glh/code/corpus/src/renderer/util/FrozenSet.ts"}}
Content-Length: 231
{"seq":0,"type":"event","event":"projectLoadingStart","body":{"projectName":"/Users/glh/code/corpus/tsconfig.json","reason":"Creating possible configured project for /Users/glh/code/corpus/src/renderer/util/FrozenSet.ts to open"}}
Content-Length: 118
{"seq":0,"type":"event","event":"projectLoadingFinish","body":{"projectName":"/Users/glh/code/corpus/tsconfig.json"}}
Content-Length: 717
{"seq":0,"type":"event","event":"telemetry","body":{"telemetryEventName":"projectInfo","payload":{"projectId":"689c12ab1bb1c95839aea14bce157cb3832179faeccd444e614b260d104bf81f","fileStats":{"js":0,"jsSize":0,"jsx":0,"jsxSize":0,"ts":5,"tsSize":7088,"tsx":12,"tsxSize":12539,"dts":99,"dtsSize":3906414,"deferred":0,"deferredSize":0},"compilerOptions":{"jsx":"react","module":"commonjs","moduleResolution":"node","outDir":"","strict":true,"target":"es2017"},"typeAcquisition":{"enable":false,"include":false,"exclude":false},"extends":false,"files":false,"include":true,"exclude":false,"compileOnSave":false,"configFileName":"tsconfig.json","projectType":"configured","languageServiceEnabled":true,"version":"3.5.3"}}}
Content-Length: 198
{"seq":0,"type":"event","event":"configFileDiag","body":{"triggerFile":"/Users/glh/code/corpus/src/renderer/util/FrozenSet.ts","configFile":"/Users/glh/code/corpus/tsconfig.json","diagnostics":[]}}
{"seq":2,"type":"request","command":"semanticDiagnosticsSync","arguments":{"file":"/Users/glh/code/corpus/src/renderer/util/FrozenSet.ts"}}
Content-Length: 105
{"seq":0,"type":"response","command":"semanticDiagnosticsSync","request_seq":2,"success":true,"body":[]}
^C
zsh: interrupt tsserverBut looking at the process hierarchy, I see that javascript-typescript-stdio isn't actually interacting with tsserver in any obvious way, but by some other mechanism...
-+= 00001 root /sbin/launchd
\-+= 70559 glh tmux new-session -d -s dot -n vim -x 179 -y 52
\-+= 87237 glh -zsh
\-+= 87678 glh zsh
\-+= 90449 glh nvim src/renderer/util/FrozenSet.ts
|-+= 90451 glh /Users/glh/code/wincent/roles/dotfiles/files/.vim/pack/bundle/opt/LanguageClient-neovim/bin/languageclient
| \--- 90452 glh node /Users/glh/n/bin/javascript-typescript-stdio
\--= 90454 glh /usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python -c import sys; sys.path.remove(""); import neovim; neovim.start_host() /Users/glh/code/wincent/roles/dotfiles/files/.vim/pack/bundle/opt/deoplete/rplugin/python3/deoplete
In this project I see some puzzling differences between the diagnostics reported by:
tsc(from typescript 3.5.3)tscwill report a clean build, but javascript-typescript-langserver complains in this file thatArgument of type 'Iterable<T> | null | undefined' is not assignable to parameter of type 'ReadonlyArray<T> | null....There are two
SetConstructoroverloads:Evidently,
tscalone is picking the former, but in the context of javascript-typescript-langserver, it's picking the latter, leading to the diagnostic.If I turn debug logging on in LanguageClient-neovim, I get this.
And logging with
--trace --logfil some-filetojavascript-typescript-stdioI get this.I don't know if this is related to https://github.com/sourcegraph/javascript-typescript-langserver/issues/618 — perhaps it is not picking up my tsconfig.json. But I don't know if this is a bug in my own code, in TypeScript, in javascript-typescript-langserver, in LanguageClient-neovim, or maybe something else I am overlooking. One thing I did notice was that when I tried to repro in VSCode, it had the same problem, but when I updated it, the problem resolved; the release notes said: