This repository has been archived by the owner on Aug 18, 2021. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 209
Circular flow type definitions trigger no-use-before-define #485
Comments
I worked around this by disabling the check inline: /* eslint-disable no-use-before-define */
export type GetState = () => State;
export type ThunkAction = (dispatch: Dispatch, getState: GetState) => any;
export type PromiseAction = Promise<Action>;
export type Dispatch = (action: Action | ThunkAction | PromiseAction) => any;
/* eslint-enable no-use-before-define */ |
joa
added a commit
to joa/babel-eslint
that referenced
this issue
Jan 21, 2018
A type alias shouldn't trigger a no-use-before-define warning just like a function declaration. Cyclic type dependencies are common when using flow. For instance: type Node<T> = { head: T; tail: Node<T> } Fixes babel#485
mwiencek
added a commit
to metabrainz/musicbrainz-server
that referenced
this issue
Feb 10, 2018
It currently conflicts with Flow, see babel/babel-eslint#485
hzoo
pushed a commit
that referenced
this issue
Sep 25, 2018
A type alias shouldn't trigger a no-use-before-define warning just like a function declaration. Cyclic type dependencies are common when using flow. For instance: type Node<T> = { head: T; tail: Node<T> } Fixes #485
Merged
Had to revert this because this was causing many issues in other rules due to the AST change in #697, https://github.com/babel/babel-eslint/releases/tag/v10.0.1 |
Tip for folks putting types in a
|
Maybe add another option in config to allow type be ignored by this rule? Both flow and typescript. |
Thank you for the issue. Now that |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Brought here from eslint/eslint#8703, by @soda0289 request:
When using core rule
no-use-before-define
, default for example instandard
, it is applied to type definitions.This could be a good thing, but the current implementation gives an unavoidable error on circular definitions:
produces
OR
produces
respectively.
Currently, disabling
no-use-before-define
in the files that have flow enabled (all for me) is a fix when actual flow is checked, since that catches undefined.However, it is still probably a bug, since:
The text was updated successfully, but these errors were encountered: