Skip to content
This repository has been archived by the owner on Aug 18, 2021. It is now read-only.

FlowType "declare" bug: 'isSequenceExpression' of undefined #132

Closed
klvnptr opened this issue Jun 16, 2015 · 14 comments
Closed

FlowType "declare" bug: 'isSequenceExpression' of undefined #132

klvnptr opened this issue Jun 16, 2015 · 14 comments

Comments

@klvnptr
Copy link

klvnptr commented Jun 16, 2015

How to reproduce it.
Create an empty node package with the following package.json

{
  "name": "babel-core-bug",
  "version": "1.0.0",
  "description": "Bug report",
  "main": "index.js",
  "devDependencies": {
    "babel": "^5.5.8",
    "babel-eslint": "^3.1.15",
    "eslint": "^0.23.0"
  }
}

Run in the console:

npm install

Create an .eslintrc file with the following:

{
  "parser": "babel-eslint"
}

Create a index.js file with the following:

"use strict";

declare class Native {
  open():Response;
  close():Response;
}

Finally run eslint:

node_modules/eslint/bin/eslint.js index.js

And you will get the following:

main.js
  0:0  error  Cannot read property 'isSequenceExpression' of undefined

✖ 1 problem (1 error, 0 warnings)

Which is kind of odd. Am I missing something?

@hzoo hzoo added the bug label Jun 16, 2015
@hzoo
Copy link
Member

hzoo commented Jun 16, 2015

No, I don't think you are. I need to look into this; I don't think I did the declare stuff right.

@klvnptr
Copy link
Author

klvnptr commented Jun 16, 2015

Thanks @hzoo

@hzoo
Copy link
Member

hzoo commented Jun 17, 2015

Oh this is that isSequenceExpression thing again with parent is undefined (because of this.dangerouslyRemove)

If I remove

if (this.isDeclareModule() ||
        this.isDeclareClass() ||
        this.isDeclareFunction() ||
        this.isDeclareVariable()) {
      return this.dangerouslyRemove();
    }

then the error "A" is not defined no-undef will occur until I add all the declare's as scope variables as well (didn't do it last time with the flow PR) which I can do

@klvnptr
Copy link
Author

klvnptr commented Jun 17, 2015

Awesome. Thank you. I'm looking forward to this in the next version released.

@hzoo hzoo closed this as completed in fcd22f5 Jun 17, 2015
hzoo added a commit that referenced this issue Jun 17, 2015
support flow declarations correctly, lint - fixes #132
@hzoo
Copy link
Member

hzoo commented Jun 17, 2015

Ok should be fixed in 3.1.16

@klvnptr
Copy link
Author

klvnptr commented Jun 17, 2015

Thanks @hzoo. But there are still some issues. Paste the following in index.js:

declare class Native {
  open():Response;
  close():Response;
}

var test:Native;
test = test;

You gonna get this error:

index.js
  6:9  error  "Native" is not defined  no-undef

✖ 1 problem (1 error, 0 warnings)

Which is not true, since it was already declared.

@hzoo
Copy link
Member

hzoo commented Jun 17, 2015

Ok I did the wrong thing - will fix soon.

@hzoo hzoo reopened this Jun 17, 2015
@hzoo
Copy link
Member

hzoo commented Jun 17, 2015

@mcz Can you test again on master?

I'm only adding a check for the top level identifier (Native in your case) and not doing anything for open():Response;, although thinking about it now I probably should for classes/modules.

@klvnptr
Copy link
Author

klvnptr commented Jun 17, 2015

If you only put this into the index.js file:

declare class Native {
  open():Response;
  close():Response;
}

Than it will be complaining:

declare.js
  1:14  error  Native is defined but never used  no-unused-vars

Which is not good, since declarations can be used standalone in Flowtype:
http://flowtype.org/docs/declarations.html

On Wed, Jun 17, 2015 at 3:20 PM, Henry Zhu notifications@github.com wrote:

@mcz https://github.com/mcz Can you test again on master?

I'm only adding a check for the top level identifier (Native in your case)
and not doing anything for open():Response;, although thinking about it
now I probably should for classes/modules.


Reply to this email directly or view it on GitHub
#132 (comment).

@hzoo
Copy link
Member

hzoo commented Jun 17, 2015

Well it's kind of an issue @mcz - no-undef and no-unused-vars are related - you basically get either error at this point.

I think that's why I ignored the flow declarations in the first place.

If I create a variable for it - then it will complain it's not used.
If I don't, it will complain it wasn't a variable when you use it.

Unless somehow we check if there's only declarations

@klvnptr
Copy link
Author

klvnptr commented Jun 17, 2015

Okay @hzoo. The point is it doesn't throw compiler error anymore. We ignore these declaration files in .eslintignore file.

@hzoo
Copy link
Member

hzoo commented Jun 17, 2015

Ok should I do a new release for the change in master? I think we want to have the no-unused-vars error rather than the no-undef one. That way you can declare stuff and use it in the same file - so the only files that will error are files that only contain flow declarations (which can be ignored like you said?)

@hzoo hzoo closed this as completed Jun 18, 2015
ghost pushed a commit to facebook/relay that referenced this issue Sep 9, 2015
Summary: As @​zpao suggested (reference #58) here is the new PR with the rules from [facebook/fbjs#49](facebook/fbjs#49).

I'll still need some guidance on what should be Relay specific.

At the moment with the current fbjs rules there is a lot of errors on [no-undef](http://eslint.org/docs/rules/no-undef.html) (example: $FlowIssue, $FixMe, $Enum and also when defining Flow types, this is related to [babel-eslint/known-issues](https://github.com/babel/babel-eslint#known-issues) - [babel-eslint#130](babel/babel-eslint#130) and [babel-eslint#132](babel/babel-eslint#132))

@​josephsavona @​zpao what are your thoughts?
Closes #202

Reviewed By: @josephsavona

Differential Revision: D2417828
steveluscher pushed a commit to facebook/relay that referenced this issue Sep 18, 2015
Summary: As @​zpao suggested (reference #58) here is the new PR with the rules from [facebook/fbjs#49](facebook/fbjs#49).

I'll still need some guidance on what should be Relay specific.

At the moment with the current fbjs rules there is a lot of errors on [no-undef](http://eslint.org/docs/rules/no-undef.html) (example: $FlowIssue, $FixMe, $Enum and also when defining Flow types, this is related to [babel-eslint/known-issues](https://github.com/babel/babel-eslint#known-issues) - [babel-eslint#130](babel/babel-eslint#130) and [babel-eslint#132](babel/babel-eslint#132))

@​josephsavona @​zpao what are your thoughts?
Closes #202

Reviewed By: @josephsavona

Differential Revision: D2417828
@zertosh
Copy link
Member

zertosh commented Nov 15, 2015

I made eslint-plugin-flow-vars to deal with this.

An eslint plugin that makes flow type annotations global variables and marks declarations as used. Solves the problem of false positives with no-undef and no-unused-vars when using babel-eslint.

@hzoo
Copy link
Member

hzoo commented Nov 16, 2015

@zertosh cool! added it to the readme

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants