You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to enforce @typescript-eslint/no-use-before-define in our projects and before extending the config on our side, I was wondering why it was turned off by default and if it could be turned on in this package instead?
Type
New feature
Changes to existing features
Motivation
While TypeScript prevents most usage before the identifier is actually defined, there are cases that aren't caught and these lead to confusing code using identifiers and types before they're defined, like in the following:
// Uses `MyEnum` type and `myFunction` before they're defined.consttest: MyEnum=myFunction();// Function implementation hidden away, using hoisting.functionmyFunction(){// Uses an enum value before it is defined.returnMyEnum.Test;}// While TypeScript catches `const` and `let` usage, it doesn't catch type defs and enums by default.enumMyEnum{Test,}
I don't believe relying on hoisting is a good practice. I personally see hoisting as a side-effect of JS parsing engines, not an actual feature we should use in code meant for humans. There are edge-cases where hoisting is necessary, these exceptions should probably be highlighted by a eslint-disable-next-line comment.
I also see that the rule is enabled for JS (though with "nofunc" which doesn't limit using hoisting), it's then disabled when overriding rules for TS, but the actual TS rule is also explicitly off.
Overview
I'd like to enforce
@typescript-eslint/no-use-before-define
in our projects and before extending the config on our side, I was wondering why it was turned off by default and if it could be turned on in this package instead?Type
Motivation
While TypeScript prevents most usage before the identifier is actually defined, there are cases that aren't caught and these lead to confusing code using identifiers and types before they're defined, like in the following:
I don't believe relying on hoisting is a good practice. I personally see hoisting as a side-effect of JS parsing engines, not an actual feature we should use in code meant for humans. There are edge-cases where hoisting is necessary, these exceptions should probably be highlighted by a
eslint-disable-next-line
comment.With the following settings
...the reversed usage order is made clear.
The text was updated successfully, but these errors were encountered: