amilajack / eslint-plugin-flowtype-errors Goto Github PK

View Code? Open in Web Editor NEW

402.0 3.0 32.0 5.46 MB

Run Flow as an ESLint plugin

License: MIT License

JavaScript 99.39% Vue 0.61%

eslint plug flow

eslint-plugin-flowtype-errors's Introduction

eslint-plugin-flowtype-errors

Demo

Why?

Lower barrier: Any editor that has ESLint support now supports Flow 🎉
Less editor configuration: No need to change your entire workflow to incorporate flow. No multiple-linters-per-file nonsense.
Simple: It's literally just an ESLint rule! Just install the dependency, add a flowconfig, and you're good to go!

Getting Started

This guide assumes that you have installed eslint, babel, babel-plugin-transform-flow-strip-types and configured flow. Check out the from-scratch guide for the full guide on getting started.

⚠️ Make sure the 64-bit version of your text editor or IDE. For atom, see this comment

1. Install

npm install --save-dev eslint-plugin-flowtype-errors

2. Configure

Extend the recommended config:

{
  "extends": ["plugin:flowtype-errors/recommended"]
}

Support

If this project is saving you (or your team) time, please consider supporting it on Patreon 👍 thank you!

CI Configuration

Flow is supported on all OS's except Windows 32bit. Add this line to appveyor to make tests run properly.

eslint-plugin-flowtype-errors's People

Contributors

Stargazers

Watchers

eslint-plugin-flowtype-errors's Issues

How to disable enforce-min-coverage for a file

I have file for which I don't need to enforce minimal coverage. Unfortunately, this doesn't seem to work:

/* eslint-disable flowtype-errors/enforce-min-coverage */

windows support?

I'm using latest version of the plugin with up-to-date Atom, linter-eslint and linter. My machine is running Windows 8.1 64-bit. When i trigger eslint from cli errors show up correctly, however i'm not able to see them in Atom ui. Errors from the plugin are somehow swallowed, while all the other rules validate just fine. Has anyone managed to get Atom linting working on windows?

32-bit error message is sometimes misleading

The changes in #46 makes the plugin fail when Flow doesn't run. That is clearly an improvement. But the error message is not always accurate: it complains about 32 bit even when the cause is something else — for example, the glibc version being too low (Flow issue #49), or the FLOW_BIN variable pointing to a binary that doesn't exist.

As a solution I would propose changing the error message to say simply that the plugin was unable to run Flow. If the 32-bit error is very common it might still be mentioned as a possible cause.

If you agree I could try to prepare a PR for this change.

PR: Drop CI support for node 4

plugin throws errors when flow detects no errors

on collect.js line 114

  return output.length
    ? filter(output)
    : true;

Because the stdout of collect.js is parsed by index.js, which then immediately runs it through JSON.parse, and then filter, which does not exist on booleans.

Suggest changing the false clause of the ternary to [] to correct this.

`Required module not found` when symlinking module via `npm link <module_name>`

Rule to guarantee coverage and conf to display warns for not covered

Hi @amilajack,

Before moving forward I want to say thank you, I'm using your package since the first day I dug into flowtype and it works great!

I don't know if you have ever tried Nuclide, well, the point is that it has a nice feature that lets you see which parts of a given file is not covered by flow. I was wondering since this can also be grouped into linting issues, if it would be a good thing to add a rule called for example enforce-min-coverage (I believe given its name, it should be clear what it does 🙂), and also add support due a configuration value (could be named display-not-covered) to display the sections (eslint warning) of the code that are not currently being covered by flow.

What do you think?

PR: Enable `flowtype-errors/show-errors` rule by default

Feature request: Report flow warnings as eslint warnings

This is a feature request.

Flow's linter now supports warnings as well as errors. However, this plugin still reports warnings as errors in eslint. Can it be adjusted to forward the correct message types to eslint?

`flowtype-errors/show-errors` doesn't work when linting from parent directory

Repro repo: https://github.com/Hypnosphi/flowtype-errors-nonroot

npm install

// outputs only no-undef error
npm lint

// outputs all the errors
npm lint-flow

Fail explicitly on 32-bit machines

Currently, the plugin returns true when running on an 32-bit machine. I think explicit failure will allow for better diagnostics of why the plugin may not be working correctly

Use files rather than .npmignore

Follows the work in #28.
When I install the plugin, I'm downloading the following:

(minus the gifs when the next release occurs)

I'd recommend using the index field of package.json instead of using .npmignore, like here. It's a whitelist system rather than blacklist, and it accepts specifying dirs or globs too.

By doing this, you'd be less likely to publish irrelevant files like your appveyor or eslint configurations.
Let me know if you want me to do the PR, the files field would probably look like

{
  files: [
    "index.js",
    "dist"
  ]
}

You then do not have to worry about updating your .npmignore file every time you add a new file.
Let me know what you think :)

Broader flow-bin peer dependency range?

It feels like I always happen to use a non-compatible flow-bin version in my projects, so npm and yarn always warn me about this. Everything still works fine though.

It feels like the interface of the parts of flow-bin that eslint-plugin-flowtype-errors actually use has been stable for a long time, and does not seem to change soon.

Could we change the peer dependency to something like this to avoid unnecessary warnings from npm and yarn?

"flow-bin": ">=0.50.0"

(Where 0.50.0 is some known compatible version reasonably far back in the past.)

Cannot read property 'filter' of undefined

Using versions: - "eslint-plugin-flowtype": "2.37.0",
"eslint-plugin-flowtype-errors": "3.3.2",

Getting the following errors, when I run lint:-

yarn lint v0.27.5
$ eslint ./app//.js
Cannot read property 'filter' of undefined
TypeError: Cannot read property 'filter' of undefined
at collect (/Users/stefanwalker/Projects/Influence/Frontend2/node_modules/eslint-plugin-flowtype-errors/dist/collect.js:178:3)
at Program (/Users/stefanwalker/Projects/Influence/Frontend2/node_modules/eslint-plugin-flowtype-errors/dist/index.js:94:48)

can I config it to show errors in all js files within project? like with option all=true?

Certain Flow errors are ignored

Some of our errors are being ignored. It only seems to occur when the error concerns two different files, e.g. when incorrect props are passed to a React component that was imported from another file.

After some debugging, it seems to be filtered by this filepath equality conditional:

eslint-plugin-flowtype-errors/src/collect.js

Line 140 in 06138df

pathModule.resolve(root, message[0].path) === fullFilepath &&

Here is the flow status output of an error that is be swallowed by the plugin. Note that each message array includes differing filenames, hence the issue.

src/components/conversation-wrap.js:14
 14:     ? <ReassignmentPage {...props} />
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ React element `ReassignmentPage`
 17: class ReassignmentPage extends React.Component<void, PropsT, StateT> {
                                                          ^^^^^^ property `isLoading`. Property not found in. See: src/handlers/reassignment-page.js:17
 14:     ? <ReassignmentPage {...props} />
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ props of React element `ReassignmentPage`

src/handlers/reassignment-page.js:17
 17: class ReassignmentPage extends React.Component<void, PropsT, StateT> {
                                                          ^^^^^^ property `isLoading`. Property not found in
 12: const ConversationWrap = (props: PropsT): React.Element<ConversationWrap> =>
                                                             ^^^^^^^^^^^^^^^^ prototype. See: src/components/conversation-wrap.js:12

Happy to provide more debugging info if needed.

Duplicate error messages

This code

// @flow

function increment(x: number) {
    return x + 1
}

increment()

produces 3 duplicate errors for the last line:

  7:2  error   'undefined (too few arguments, expected default/rest parameters)' This type is incompatible with 'number'   flowtype-errors/show-errors
  7:2  error   'undefined (too few arguments, expected default/rest parameters)' This type is incompatible with 'number'   flowtype-errors/show-errors
  7:2  error   'undefined (too few arguments, expected default/rest parameters)' This type is incompatible with 'number'   flowtype-errors/show-errors

A typo in a wiki page.

Thank you for your good eslint plugin.

I found a typo in a wiki page.

https://github.com/amilajack/eslint-plugin-flowtype-errors/wiki/Getting-Started
Create a .flowconfig with: -> Crate a .eslintrc with: ?

Make it work on the fly

Using flow check-contents you can pass the current contents of a file to be listed by flow. So you can catch your errors before you save the file. Adding that would be a big improvement.

See linter-flow for an example

Migrate to eslint's RuleTester

Allow Flow to be installed as peerDependency

'error Unexpected token' then combined with 'vue-eslint-parser'

Please look at this comment:
vuejs/vue-eslint-parser#10 (comment)

Problems with spaces in paths on Windows

1: If my project is located at a path with a space above the project folder:

C:\Users\me\project folders\project

this plugin fails to start the Flow server and ESLint outputs exec: internal error ~~whenever Flow encounters a type error~~ several times (I can't find a correlation between the number of times that it is output and either the number of Flow errors or the number of files with the @flow flag).

2: If I have a file inside a folder with a space inside my project:

C:\Users\me\projectFolders\project\js\space folder\fileWithTypeErrors.js

this plugin fails to start the Flow server if run with the grunt-eslint task or SublimeLinter-contrib-eslint. It does start the Flow server if run directly with the command node_modules/.bin/eslint ., but in all cases, it doesn't report any Flow errors.

eslint-plugin-flowtype-errors: v3.2.0
flow-bin: v0.45.0
Windows 10

Files without @flow comment are throwing errors

I am seeing eslint throw this error (a lot):

23:17 error Type annotations require valid Flow declaration flowtype/no-types-missing-file-annotation

For files that don't have /@flow/ anywhere in the file.

eslint:

In package.json:

"babel-eslint": "^7.1.1",
"eslint": "^3.16.1",

"eslint-plugin-flowtype": "^2.30.0",

Any ideas would be helpful.

.flowconfig:

[include]
src/client

So not sure if that's causing problems since I am effectively running:

eslint src/client

Thanks

Report error which Flow does not report

This use case is where, in C/C++, a forward declaration would be needed.

A.js:

// @flow

import B from './B';

export default class A {
  a() { return new B(this); }
}

B.js:

// @flow

import type A from './A';

export default class B {
  a: A;

  constructor(a: A) {
    this.a = a;
  }
}

Flow says No errors! but flowtype-errors/show-errors reports the following in A.js:

6:23  A:  This type is incompatible with the expected param type of A. See ./B.js:8

Add flow-runtime link to README

EPERM: operation not permitted, write

This is an error that happens on windows when running this plugin with atom's linter and atom-eslint.

There seem to be a number of related issues:

AtomLinter/linter-eslint#418
AtomLinter/linter-eslint#579
AtomLinter/linter-eslint#650
electron/electron#2033
AtomLinter/linter-eslint#706

This seems to be an atom specific issue. Running eslint through the command line and other methods of running eslint should work fine.

enforce-min-coverage linter error

I get this linter error in my file: definition for rule enforce-min-coverage was not found in flowtype-errors/enforce-min-coverage.
I am using current plugin version 3.2.1 and eslint 3.19.0
Thanks

Join efforts with eslint-plugin-flowtype

I recently published eslint-plugin-flow-check (link) which basically has the same functionality as your plugin.

I am rather unhappy with crowding the eslint + flowtype naming space further but had to move quickly for a private project.

I wonder if you'd be interested in joining efforts with @gajus and me over at gajus/eslint-plugin-flowtype?

gajus/eslint-plugin-flowtype#206

PR: Add support for recommended config settings

Plugin does not report error, but flow-bin does (for npm imported types)

This plugin seems to have issues detecting/reporting on flow errors when they span across multiple files/npm projects.

For example:

import { GraphQLObjectType } from 'graphql'
import type { GraphQLOutputType } from 'graphql'

// [...]

// The following line (12) is detected as a flow error by the plugin and flow cli
const x: number = "lol"

// The following line (15) is detected as a flow error by the flow CLI, but not the plugin
const y: GraphQLOutputType = new GraphQLObjectType({
  name: 'foo'
  // fields: (missing, flow should complain)
})

Output of flow-bin (detecting both errors):

src/index.js:12
 12: const x: number = "lol"
                       ^^^^^ string. This type is incompatible with
 12: const x: number = "lol"
              ^^^^^^ number

src/index.js:15
 15: const y: GraphQLOutputType = new GraphQLObjectType({
                                  ^ constructor call
383:   constructor(config: GraphQLObjectTypeConfig<*, *>) {
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ property `fields`. Property not found in. See: node_modules/graphql/type/definition.js.flow:383
 15: const y: GraphQLOutputType = new GraphQLObjectType({
                                                        ^ object literal


Found 2 errors

Output of eslint (not detecting the 2nd error):

/Users/jbuchanan/dev/tb/foo/src/index.js
  12:20  error  string:  This type is incompatible with 'number'. See line 12  flowtype-errors/show-errors

✖ 1 problem (1 error, 0 warnings)

Perhaps the hint from flow to "see node_modules/graphql...:383" might be throwing us off?

I have a reproduction case here, if it helps (fairly simple repo created with create-react-app), this commit has all you need).

jbinto/flowtype-errors-plugin-issue-npm@3dcbcd4

update flow-bin peer dependency

Hi and thanks for your (awesome) works on this package

I've run into a

unmeet peer dependency eslint-plugin-flowtype-erros needs [email protected], [email protected] installed.

According to this website, this package only allow flow-bin version >=0.57.3 <0.58.0. Do you have technical reasons for this ? If so can you create a 'beta' version with newer version of Flow ? (0.59.0 would be awesome).

You can also take a look at this PR i made => #108

Thx

Problems in IntelliJ when node_modules folder is not on top level

I tried out the plugin and it works great as a webpack loader, but I can not make it run in Webstorm / IntelliJ. The problem is that it does not seem to find the plugin as the directory it looks in is not right (should be ...src/main/js/...):

Error: Cannot find module '/Users/olli/Development/floreysoft/floreysoft-status/node_modules/eslint-plugin-flowtype-errors/dist/collect.js'
at Function.Module._resolveFilename (module.js:455:15)
at Function.Module._load (module.js:403:25)
at Module.runMain (module.js:590:10)
at run (bootstrap_node.js:394:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:509:3

at checkExecSyncError (child_process.js:483:13)
at execSync (child_process.js:523:13)
at showErrors (/Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint-plugin-flowtype-errors/index.js:36:25)
at /Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint/lib/eslint.js:824:25
at Array.forEach (native)
at EventEmitter.module.exports.api.verify (/Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint/lib/eslint.js:796:16)
at processText (/Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint/lib/cli-engine.js:262:31)
at CLIEngine.executeOnText (/Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint/lib/cli-engine.js:751:26)
at Object.execute (/Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint/lib/cli.js:181:36)
at /Users/olli/Development/floreysoft/floreysoft-status/src/main/js/node_modules/eslint/bin/eslint.js:57:36

node node_modules/eslint-plugin-flowtype-errors/dist/collect.js

Looking at the code:

const collected = execSync(
  `node ${path.normalize('./node_modules/eslint-plugin-flowtype-errors/dist/collect.js')}`
);

it becomes clear why there is this error: my node_modules are simply somewhere else.

Any ideas? Add a configuration path pointing to the location of the node_modules?

This might simply be because of my messed up set up, but without the plugin it works well and it can also load other plugins without a problem.

Unexpected token error caused by different versions of flow

If I have the following type defined inside of a react component. This is using covariant properties in an exact object type:

state : {|
    +loading : boolean,
|}

I get an error from this plugin:

Unexpected token +: [flowtype-errors/show-errors]

However, this is valid syntax (see here).

And flow does not throw any errors.

I'm assuming this is because this plugin has a dependency on flow-bin@^0.33.0 whereas my project is using flow-bin@^0.35.0.

Can this plugin be configured to use my flow-bin? Or can the restraints on the dependency somehow be loosened?

Support latest version of Flow (0.66)

Flow error messages got an overhaul in Flow 0.66. Using this latest release with eslint-plugin-flowtype-errors produces linting errors that just look like this:

Initial Tests

E2E Project Testing

To ensure that this project is very well tested, I'm thinking of forking an example react repo, making some intentional errors, capturing the flow --json response, and testing that flow reports exactly those issues on every test. These kinds of tests should be run on Travis and Appveyor.

Appveyor fails on 32 bit Architecture

Flow seems to only be supported on 32 bit Windows OS's.

See flow/flow-bin#41

Plugin is spawning multiple flow server processes in different projects

When I run eslint configuration with this plugin in different projects there are multiple flow processes running as a result.

Only way to get rid of these processes is to stop them manually.

This is screenshot when I run linting in 2 projects.

Is there a mechanism to stop them automatically? I know that it is hard because you start server on first run and then use flow check-contents to keep this plugin performant.

Columns are reported incorrectly

All columns are reported one column to the left.

Waiting for facebook/flow#1451 (comment) to be resolved.

Doesn't respect `[ignore]` in project's .flowconfig

Hi there, I have a .flowconfig file in the root of my project that looks something like this:

[include]
src

[ignore]
.*/node_modules/.*\.flow
.*/node_modules/.*/src/.*
.*/node_modules/.*/es/.*
.*/node_modules/.*/example/.*
.*/node_modules/babel-plugin-flow-runtime/.*
.*/node_modules/fbjs/.*
.*/node_modules/flow-runtime/.*
.*/foo/.*

[libs]
interfaces

[version]
>=0.40.0

[options]
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src
unsafe.enable_getters_and_setters=true

When I try running eslint though I get all of the flow errors from files in the .*/foo/.* directory even though it's ignored.

My guess is the issue may have something to do with this function:

eslint-plugin-flowtype-errors/src/collect.js

Line 78 in a907115

function executeFlow(stdin, root, filepath) {

At first glance it looks like it's looping through every single file and executing flow directly on the file. Let me know if I'm crazy.

`Property not found in...` errors not reported

If I have a function

function foo(bar: {baz: string}) {...}

And I call it with

foo(1234);

An error is reported as expected (due to the mismatched type). But if I call it with

foo({xyz: 'abc'});

An error is reported by Flow but not by this plug-in. Seems that the code filtering out issues is incorrect: https://github.com/amilajack/eslint-plugin-flowtype-errors/blob/master/src/collect.js#L76 as filepath and message[0].path don't match in this case.

Running eslint on multiple files causes flow to be run mutliple times

in the dist source on collect.js, the filepath for flow to evaluate is not passed in, flow is always run with flow --json

This means when eslinting multiple files, flow parses the entire project. This is a huge performance cost.

React prop validation not supported

This code:

// @flow

import React, { Component } from 'react'

class Foo extends Component {
    props: {
        firstName: string,
        lastName: string,
    }

    render() {
        return (
            <div>
                <h1>Hello {this.props.firstName} {this.props.lastName}</h1>
            </div>
        )
    }
}

class Bar extends Component {
    render() {
        return <Foo firstName="John" />
    }
}

rightly fails typechecking with flow because Bar is not supplying all required props to Foo:

  6:     props: {
                ^ property `lastName`. Property not found in
 22:         return <Foo firstName="John" />
                    ^^^^^^^^^^^^^^^^^^^^^^^^ props of React element `Foo`

however eslint-plugin-flowtype-errors doesn't notice the problem.

Insufficient error information

I am setting up Vue environment with webpack, flow and eslint and testing out how it works.

Apparently, it didn't take much time to hit an interesting case.

Code:

// @flow
type DataFactory = () => { msg: string, bingo?: number }

type ModuleType = {
  +name: string,
  data: DataFactory
}

export default ({
  name: 'HelloWorld',
  data () {
    return {
      msg: 'Welcome to Your Vue.js App',
      bingo: 'string'
    }
  }
} : ModuleType)

Interactive version @ flow.org

The type DataFactory requires that if bingo is provided, it should be a number. As can be seen in the export, it's a string.

On flow.org, that results in quite an expressive error:

9: export default ({                   
                   ^ object literal. This type is incompatible with
17: } : ModuleType)
        ^ object type
   Property `data` is incompatible:
      11:   data () {
                 ^ function. This type is incompatible with
      6:   data: DataFactory           
                 ^ function type
         This parameter is incompatible:
            12:     return {               
                           ^ object literal. This type is incompatible with
            2: type DataFactory = () => { msg: string, bingo?: number }                            
                                        ^ object type
               Property `bingo` is incompatible:
                  14:       bingo: 'string'                 
                                   ^ string. This type is incompatible with
                  2: type DataFactory = () => { msg: string, bingo?: number }
                                                                     ^ number

Where as with eslint, I get:

> yarn lint --no-color --format codeframe
yarn run v1.3.2
$ eslint --ext .js,.vue src --no-color --format codeframe
error: object literal:  This type is incompatible with 'object type'. See line 17 (flowtype-errors/show-errors) at src\components\HelloWorld.vue:33:17:
  31 | }
  32 |
> 33 | export default ({
     |                 ^
  34 |   name: 'HelloWorld',
  35 |   data () {
  36 |     return {


1 error found.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Which appears to be the first message reported (matches the one on flow.org), though, the least descriptive one.

Is it a configuration error or a bug or missing feature or...?

Plugin not working with Bitbucket Pipelines or TravisCI

I'm not sure if there's anything that can be done on the side of this plugin, but I wanted to at least report that I got lots of "Required module not found" flow errors when running a private Bitbucket Pipeline CI test. The errors were related to packages installed in node_modules as well as requiring other files without using a .js file extension (i.e. require('../lib/routes')).

However, the flow test would pass with no issues locally. I was able to fix the issue by switching to using flow-bin directly for CI tests and using this module for only local development.

Allow to disable some of the errors

If material-ui is used

import { createMuiTheme } from 'material-ui/styles';

Error:

material-ui/styles. Required module not found

Will be thrown
Is there any way of going around this, instead of adding $FlowIgnore comment everywhere?

master ❯ npm install                                   
npm WARN package.json [email protected] No license field.
npm ERR! Linux 3.13.0-88-generic
npm ERR! argv "/nix/store/ajr6i77s89gjfjm59aazc16b5rvb39n7-nodejs-4.3.1/bin/node" "/home/adjective/.nix-profile/bin/npm" "install"
npm ERR! node v4.3.1
npm ERR! npm  v2.14.12
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants eslint-plugin-import@^1.16.0

npm ERR! Please include the following file with any support request:
npm ERR!     /home/adjective/Projects/eslint-plugin-flowtype-errors/npm-debug.log

npm install is broken due to invalid peer dependencies.

Suggest downgrading eslint-plugin-import to ^1.16.0, or specifying a project .eslintrc instead of depending on airbnb's