4.18.2 - "Cannot read property 'type' of undefined" in no-unused-vars when checking flow type definitions
See original GitHub issueTell us about your environment
- ESLint Version: 4.18.2 (it works in 4.18.1)!
- Node Version: 9.8.0
- yarn Version: 1.5.1
What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint@8.2.2
Please show your full configuration:
Configuration
module.exports = {
parser: 'babel-eslint',
rules: {
'no-unused-vars': 'error'
}
};
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
The issue only occures for files where a result type is defined for an arrow function:
// @flow
type Type = null;
// Defining result type causes the crash
export const f = (): Type => null;
// This would work
export const f2 = () => null;
eslint source.js
What actually happened? Please include the actual, raw output from ESLint.
Cannot read property 'type' of undefined
TypeError: Cannot read property 'type' of undefined
at isForInRef (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/rules/no-unused-vars.js:406:24)
at variable.references.some.ref (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/rules/no-unused-vars.js:443:21)
at Array.some (<anonymous>)
at isUsedVariable (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/rules/no-unused-vars.js:442:40)
at collectUnusedVariables (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/rules/no-unused-vars.js:565:26)
at collectUnusedVariables (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/rules/no-unused-vars.js:572:17)
at Program:exit (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/rules/no-unused-vars.js:617:36)
at listeners.(anonymous function).forEach.listener (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/util/safe-emitter.js:47:58)
at Array.forEach (<anonymous>)
at Object.emit (/Users/tgs/projects/brainly/brainly-frontend/node_modules/eslint/lib/util/safe-emitter.js:47:38)
It works correctly in 4.18.1
!
Issue Analytics
- State:
- Created 6 years ago
- Comments:8 (7 by maintainers)
Top Results From Across the Web
ESLint - Configuring "no-unused-vars" for TypeScript
VS Code, using eslint, was giving me warnings about unused variables in my type declarations for function callbacks. These options, added to my ......
Read more >TMS320C6000 Optimizing Compiler v8.2.x - Texas Instruments
6.3.4 Specifying the Type of Global Variable Initialization . ... Defined to 1 if _ _TI_32BIT_LONG_ _ is not defined; otherwise, it is...
Read more >Interworking Datapoint Types - KNX Association
This Chapter specifies the KNX Datapoint Types for Interworking ... 4.18.2 Datapoint Type “4x set of DHWTemperature setpoints” .
Read more >Security Beta update for SUMA client tools | SUSE Support
#8761 * Remote Write: Send exemplars via remote write. ... cannot read property length of undefined (#31458) * Explore: Show ANSI colored ...
Read more >MPASM™ Assembler, MPLINK™ Object Linker, MPLIB ...
4.57 set – Define an Assembler Variable . ... language summary, MPASM assembler radix types supported, MPLINK object linker.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@platinumazure @not-an-aardvark Ugh, OK, I tried to reproduce that in an isolated setup and I found the issue - it’s not with eslint, it’s problem with yarn workspaces, false alarm.
In case some has the same thing: it seems when using yarn workspaces eslint binary might run against a different
babel-eslint
than the one defined in your package. Yuck.Sorry I wasted your time. 😦
Closing this issue since it turned out to not be a bug. Thanks for the report regardless – I think we have room for improvement in helping the user debug this type of issue.