Auto Import

[rattrayalex-stripe]

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]

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

[feafarot]

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

[karlhorky]

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]

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]

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]

any updates on this one?

[orta]

No updates, why not take a look yourself?

[mindriven]

Sure, only time is the problem :-(

[coxom]

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

[cellis]

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]

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]

@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]

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]

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]

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

[rattrayalex-stripe]

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]

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]

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

[jedwards1211]

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]

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]

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]

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]

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

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