flow / flow-for-vscode

Flow for Visual Studio Code
Other
994 stars 111 forks source link

Auto Import #181

Open rattrayalex-stripe opened 6 years ago

rattrayalex-stripe commented 6 years ago

VSCode just shipped Auto Import for JavaScript and TypeScript, but it only works when javascript.validate.enable is true, which is not possible with Flow-typed files.

Judging by comments like this one from the Flow team, there is no interest in support Flow natively.

This is a great feature and it'd be lovely if flow-for-vscode could support it.

Based on the comment in https://github.com/flowtype/flow-for-vscode/issues/160, I assume that this will be blocked on https://github.com/flowtype/flow-for-vscode/pull/150.

pronebird commented 6 years ago

It's insanely buggy and I came here by looking how to disable this madness. It even works with "javascript.validate.enable": false

feafarot commented 6 years ago

+1 For this feature, it would be very handy!

karlhorky commented 6 years ago

Ah, just found this one after opening #223, oops.

Looks like @orta merged #150 🎉 Is this feature complex to implement?

Would be really nice to get auto import support with Flow code. With the built-in auto import on .js Flow files with type imports, it ends up with messes like these:

Before auto-importing Entry:

import { TAccount } from './TAccount'
import type { SimilarTransactionJson, TAccountJson } from '../../types/BankingTypes'

After importing Entry:

import { TAccount } from './TAccount'
import typeimport { Entry } from './Entry';
 { SimilarTransactionJson, TAccountJson } from '../../types/BankingTypes'
rvion commented 6 years ago

as a temporary solution / source of inspiration, https://github.com/wangtao0101/vscode-js-import works decently and suport monorepos. it works by parsing files looking for exports. It's very fast, and IMO better than the default feature

example config:

    "js-import.filesToScan": "*/src/**/*.js",
    "js-import.alias": {
         "@foo/shared": "shared/src/" // only transformed when imported from outside of shared/src/
     },
     "js-import.[...]"

it is a big buggy when adding a new import line if the previous import is an import type and it don't support auto-importing/auto-completing exported types;

orta commented 6 years ago

I think the vscode auto-import is built into typescript itself, but I bet it probably happens over the LSP so should be feasible to build something like that if flow also has a way to do queries for a symbol inside the global scope

mindriven commented 6 years ago

any updates on this one?

orta commented 6 years ago

No updates, why not take a look yourself?

mindriven commented 6 years ago

Sure, only time is the problem :-(

coxom commented 6 years ago

@karlhorky also experiencing the import bug issue. Very painful to live with. This is the biggest issue I have with VSCode atm.

cellis commented 6 years ago

One workaround I've found is by setting eslint-plugin-flowtype's type-import-style to identifier flow-type imports, as in the following:

// texteditor.js
import {
  type SlateDocument,
  type SlateChange,
  type SlateEditor,
} from './types';

import { type Style } from '../../../types';
import Toolbar from './Toolbar';
// .eslintrc.js
module.exports = {
  parser: 'babel-eslint',
  //...
  rules: {
    //...
    'flowtype/type-import-style': 'identifier',
    //...
  }
}

It seems that using the identifier type import style instead of declaration, while more verbose, doesn't confuse VSCode's parser.

The other work around is to place types at the top, though that will conflict with eslint's import/first rule. Hope this helps @coxom

pieplu commented 5 years ago

Maybe it's linked, but since 2 or 3 vscode version, auto-importing a flow type is completly broken with a function import.

import('path/to/model').ModelType
jamesisaac commented 5 years ago

@cellis I like your second workaround, of just grouping the import type statements together at the top.

Trying to find a way to get that applied automatically, I've submitted a PR to the import-sort package (which I believe is more powerful than eslint anyway in how much it can do to automatically reorganise the imports):

https://github.com/renke/import-sort/pull/76

Once the issue is fixed in VS Code, the user styling rule could just be updated to automatically shift all the type imports to the bottom (if that feels more natural).

vincenzovitale commented 5 years ago

Any news on this, as @pieplu already mentioned you get a completely broken import of the middle of the code. So time consuming and it's making me consider moving (again :( ) to another IDE.

Any workaround for it?

laplacesdemon commented 5 years ago

One workaround I've found is by setting eslint-plugin-flowtype's type-import-style to identifier flow-type imports, as in the following:

// texteditor.js
import {
  type SlateDocument,
  type SlateChange,
  type SlateEditor,
} from './types';

import { type Style } from '../../../types';
import Toolbar from './Toolbar';
// .eslintrc.js
module.exports = {
  parser: 'babel-eslint',
  //...
  rules: {
    //...
    'flowtype/type-import-style': 'identifier',
    //...
  }
}

It seems that using the identifier type import style instead of declaration, while more verbose, doesn't confuse VSCode's parser.

The other work around is to place types at the top, though that will conflict with eslint's import/first rule. Hope this helps @coxom

I like this workaround but mind that babel compiles import type { X } from 'y' differently than import {type X} from 'y'. It might not be a problem for many but it's good to keep in mind: https://github.com/babel/babel/issues/6300

cellis commented 5 years ago

@laplacesdemon, l leave that problem for webpack and dead-code-elimination plugins to sort out. ;) But yes, good to note!

rattrayalex-stripe commented 5 years ago

If anyone is interested in taking a crack at this, and would find sponsorship helpful to be able to allocate time towards it, shoot me an email. No promises but I'll see what I can do...

vicapow commented 5 years ago

Something I’d encourage you to implement in flow itself. This is where the LSP server code lives. I was considering adding this myself but haven’t had time. I did recently add function parameter completion which is a lot of the same code

rattrayalex-stripe commented 5 years ago

Thanks @vicapow ! opened https://github.com/facebook/flow/issues/7662

jedwards1211 commented 5 years ago

Hi everyone, I just released dude-wheres-my-module, a standalone suggested import server that supports JavaScript and Flow type imports. At the moment I use a cobbled-together atom-morpher plugin to use it in Atom. Maybe someone wants to take a crack at VSCode plugin that uses it?

curiousdustin commented 4 years ago

Maybe it's linked, but since 2 or 3 vscode version, auto-importing a flow type is completly broken with a function import.

import('path/to/model').ModelType

Is there any solution for this?

Is there a way to make auto imports for Flow types be inserted at the top of the file instead of inline in the code?

orta commented 4 years ago

While I'm thinking about it: Now that TypeScript supports import type (TS 3.8) - you might get quite far with the default vscode toolsts tooling also

jedwards1211 commented 4 years ago

I forgot to mention here, I made a VSCode Extension. It still has a few rough edges (renamed files and identifiers sometimes don't get cleaned out) and the main limitation is atm it only suggests imports/exports it sees elsewhere in your code; I still need to make it scan node_modules and flow-typed. That said, I use it every day.

You may have better mileage with it than the toolsts tooling, esp if you're using babel plugins for language features that are not valid TS.

jedwards1211 commented 4 years ago

@curiousdustin @pieplu I'm confused how this would even work, I thought import() always returns a Promise?

import('path/to/model').ModelType