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

nicolo-ribaudo pushed a commit to babel/babel that referenced this issue Nov 14, 2019
support flow declarations correctly, lint - fixes babel/babel-eslint#132
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