Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positives when importing from flow-typed module declarations #708

Closed
dlindenkreuz opened this issue Jan 3, 2017 · 7 comments · Fixed by #881
Closed

False positives when importing from flow-typed module declarations #708

dlindenkreuz opened this issue Jan 3, 2017 · 7 comments · Fixed by #881

Comments

@dlindenkreuz
Copy link

dlindenkreuz commented Jan 3, 2017

Explicit imports from flow-typed module declarations seem to yield false positives.

Example:

import type { ActionCreators } from "redux"
// error  ActionCreators not found in 'redux'  import/named

The error should not appear because flow can attach declared types to named modules via flow-typed or other library files, even if the modules themselves do not export those types. In the example above, redux does not export any types. Instead, a flow-typed library handles the type declarations.

@skovhus
Copy link

skovhus commented Mar 30, 2017

Seeing the same error. Not sure exactly how to solve it.

@mjomble
Copy link

mjomble commented Apr 5, 2017

I guess there are two main different ways to solve this problem:

  1. Try to replicate all of Flow's import logic in this rule and keep it in sync with any future changes.
  2. Ignore all import type declarations in this rule.

I'm leaning towards option 2.

If the user is already using Flow, there's a good chance Flow itself will catch any invalid imports like this.

In most cases, there should be no need for two different tools reporting the same problem, one would be enough. Often even preferred.

If you want, you can apply a temporary local hack for the second solution by editing node_modules/eslint-plugin-import/lib/rules/named.js and adding

if (node.importKind === 'type') return;

to the start of checkSpecifiers.
This will be gone and require reapplying after each eslint-plugin-import update, though.

@petegleeson
Copy link

I feel as though option 2 would be a good solution to this problem. @mjomble you are right that flow will catch any invalid imports. Is anyone working on this? Otherwise I might see if I can add this as a rule to the plugin.

@athomann
Copy link

Experiencing the same thing. Anyone working on a PR for this? I may be able to help.

@mjomble
Copy link

mjomble commented May 23, 2017

I'm not working on a PR

@SpainTrain
Copy link

From our experience and comments/reactions in #881, it seems like this issue may still be open. Possible to reopen, or should I open a new issue? Thanks!

@ljharb
Copy link
Member

ljharb commented Sep 15, 2017

Please open a new issue; it's been many months, so it's possible your problem is different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

7 participants