flow
flow copied to clipboard
facebook
[Summary] Flowtype / VSCode pain points and potential improvements
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.
- https://github.com/microsoft/vscode/issues/70239
- https://github.com/microsoft/vscode-languageserver-node/issues/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)
-
[x] Auto import of dependencies. TypeScript currently supports “auto importing” dependencies but Flow does not.
- https://github.com/facebook/flow/issues/7662
-
[ ] Work upstream with LSP team to add needed features to the spec to match TypeScripts support.
- https://github.com/microsoft/vscode-languageserver-node/issues/471
~~- [] Add “codelens” support https://github.com/facebook/flow/issues/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 https://github.com/facebook/flow/issues/7743
-
[x] Support
documentationtooltip in LSP https://github.com/facebook/flow/issues/7725 -
[ ] Explore ways to configure and Bundle vscode with Flow
-
[ ] Autocompletion/suggestions on imported or inherited types #7722
-
[x] Hints / suggestions / autocomplete are missing #7723
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
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.
