[Summary] Flowtype / VSCode pain points and potential improvements

[vicapow]

Flowtype VSCode pain points and potential improvements

A lot of engineers have started using VSCode for day to day development. A good portion of these engineers are coming from a background of TypeScript which has very good built in support within VSCode. This is the case for a few reasons:

• VSCode comes with a TypeScript extension built into and bundled with the editor. Users do not have to configure or update this plugin. It “just works”.
• TypeScript’s VSCode editor support is implemented with tsserver and the TypeScript built in extension instead of using the open Language Server Protocol developed by Microsoft. This means some features TypeScript supports today just aren’t possible without also updating the Language Server Protocol.
  • vscode should send textDocument/signatureHelp after autocomplete result microsoft/vscode#70239
  • Define behavior around parameter hints so LSP clients can support the same completion + hints functionality as TypeScript microsoft/vscode-languageserver-node#471
• TypeScript’s API is more stable than Flow’s. Flow is still a minor version (0.x) and the project has historically not been shy about that fact.
• Facebook (as far as I know) mostly only supports the Nuclide IDE internally through the Language Server Protocol. This may mean in some cases Flow + VSCode issues might not always be high priority or visible to the Flow team, especially if they're unique LSP + VSCode behavior.
• It’s not always easy or straightforward to configure Flow in VSCode. For example, it may be that the local node_modules Flow server (flow-bin) isn’t found and the VSCode plugin falls back to using its own version of Flow. We've had one issue in the past for example were a project was not configured to point to the local flow-bin server. When the Flow-for-vscode plugin auto updated, the user started to get errors in VSCode they weren't seeing from the command line. This is easily fixed when you know the cause but otherwise, you loose confidence in the tooling.

Collecting ideas for IDE improvements (will continue to update this)

• Auto import of dependencies. TypeScript currently supports “auto importing” dependencies but Flow does not.

  • Add Auto Import functionality to LSP #7662

• Work upstream with LSP team to add needed features to the spec to match TypeScripts support.

  • Define behavior around parameter hints so LSP clients can support the same completion + hints functionality as TypeScript microsoft/vscode-languageserver-node#471

- [] Add “codelens” support #7890

• Decided against this for now. The output ended up being too verbose to be helpful. Could consider adding this behind a config flag?

• Support for WorkspaceSymbol in LSP Support WorkspaceSymbol in Flow Language Server #7743

• Support documentation tooltip in LSP Support documentation in LSP #7725

• Explore ways to configure and Bundle vscode with Flow

• Autocompletion/suggestions on imported or inherited types Autocompletion/suggestions on imported or inherited types not happening #7722

• Hints / suggestions / autocomplete are missing Hints / suggestions / autocomplete are missing #7723

[Xiot]

A couple more improvements

Better syntax highlighting when using generics (currently using the Babel JavaScript "language")

Cmd + clicking on the import path, should jump to the file. Currently only cmd + click on the imported names works

[mroch]

Awesome, thanks for starting this list! This is an area that we're going to be investing in over the next couple of months, so the list of issues (please tag them with LSP!) and their relative priority will help me out a lot.

We don't use flow-for-vscode internally but vscode is still very important to us. You are correct that we've made Nuclide communicate with Flow solely over the LSP. All of our other editor integration is deprecated in favor of the LSP, and I hope we remove the legacy stuff ASAP so that we can focus (what were you saying about an unstable api? 😂).

Accurately implementing the LSP is our priority. In my experience so far, there aren't many LSP + vscode bugs as it's the reference LSP implementation. So it's a matter of us returning poor LSP responses, which so far have impacted Nuclide and VSCode equally -- e.g. returning bad ranges made them both filter out autocomplete results.

[goodmind]

@mroch maybe also check autocomplete and type-at-pos labels

[goodmind]

@mroch do you have any news about this?