Flow type triggers space-infix-ops error
See original GitHub issueI know that eslint is not supporting flow types, but it seems that the space-infix-ops rule is assuming that between left
and right
side of an ExpressionPattern
, there is only on Punctation
which in the case of flow type is not true.
(https://github.com/eslint/eslint/blob/master/lib/rules/space-infix-ops.js#L32)
example:
(foo: string = 'test') => {};
triggers:
1:5 error Infix operators must be spaced space-infix-ops
What would be a proper way to fix this? I think this is something in the rule itself should be accounted for and it should ignore anything which belongs to left or right side instead of treating it as “something between left and right”.
refs babel/babel-eslint#226
eslint version: 1.10.3
Issue Analytics
- State:
- Created 8 years ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
Developers - Flow type triggers space-infix-ops error - - Bountysource
Coming soon: A brand new website interface for an even better experience!
Read more >space-infix-ops - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >Error Suppressions - JavaScript. Flow
A suppression is a special kind of comment that you can place on the line before a type error. It tells Flow not...
Read more >infix (fixed format) — Read text data in fixed format - Stata
infix reads into memory from a disk dataset that is not in Stata format. infix requires that the data be in fixed-column format....
Read more >Expressions - Erlang/OTP
An argument of the wrong type causes a badarg runtime error. 9.2 Terms. The simplest form of expression is a term, that is...
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
I would work on creating a PR for this now, but I’m not sure how to test it, as espree doesn’t support any typeannotation when parsing. Is there a way to workaround this? Or should i create the test in babel-eslint or include babel-eslint as devDependency?
There’s some standardization now. The
Identifier
node now has atypeAnnotation
property that indicates a type annotation is present (it’snull
or undefined if there’s no type annotation). Using that, we should be able to make this rule skip the:
that’s part of the type annotation.