hendrikniemann / atom-autoimport Goto Github PK

This way the imports would be formatted the way are supposed to be formatted in the target environment.
(Correct quotation mark type, line break if statement gets to long...)

The import algorithm fails to recognise multiline import statements to insert an import to the existing import.

Example:

import {
  GraphQLObjectType,
  GraphQLNonNull,
  GraphQLID,
  GraphQLList,
  GraphQLString,
} from 'graphql';

GraphQLBoolean;

Result:

import {
  GraphQLObjectType,
  GraphQLNonNull,
  GraphQLID,
  GraphQLList,
  GraphQLString,
} from 'graphql';
import { GraphQLBoolean } from 'graphql';

GraphQLBoolean;

Expected:

import {
  GraphQLObjectType,
  GraphQLNonNull,
  GraphQLID,
  GraphQLList,
  GraphQLString,
  GraphQLBoolean,
} from 'graphql';

GraphQLBoolean;

The projectFileDefaultImportPlugin should also consider folders with an indes.js file and return a match when the folder name matches the identifier name.

Example:

src/components/User/index.js should match User and result in:

import User from 'src/components/User';

Creating an import statement is relatively simple. Placing it in the right place at the file head is rather difficult. The current naive solution is to simple put the import after the last import statement. Normally you would want your imports sorted. The very basic sorting is to put the absolute imports first.

If the findUnresolvedIdentifiers function can be refactored into a provider interface comparable with the ImportPlugin interface the provider can be more easily be replaced by a different provider (e.g. ESlint).

Current:

function flowCheckContents(rootDir: RootDir, file: string, content: string): Promise<FlowReport> {}
function findUnresolvedIdentifiers(report: FlowReport): string[] {}

Proposal:

type Provider = (rootDir: RootDir, file: string, content: string) => Promise<string[]>;

Type imports need to be prefixed with type. The plugin should recognise the flow error that the import is actually a type import and use a type import to make the import instead.

When the project has defined some extra module folders defined in the .flowconfig import statements should favor these absolute imports under some circumstances.

Problem: It is not really clear when it should do that.

Example setup:

src/
  module/
    a.js
    b.js

# .flowconfig
module.system.node.resolve_dirname=src

Lets say we import b in a.js. Should this be

import b from './b';
// or
import b from 'module/b';

What you often want is self-contained modules (e.g. in a subfolder) that are referencing files within that module in relative paths but the modules would be referenced from outside of that module with an absolute path.