Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[no-unreachable] and [no-unused-label] are handled inconsistently #4819

Closed as not planned
Labels
accepting prsGo ahead, send a pull request that resolves this issuedocumentationDocumentation ("docs") that needs adding/updatinglocked due to agePlease open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing.package: eslint-pluginIssues related to @typescript-eslint/eslint-plugin
@amayer42

Description

@amayer42
  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.
  • I haveread the FAQ and my problem is not listed.

Repro

{"extends": ["eslint:recommended","plugin:@typescript-eslint/eslint-recommended","plugin:@typescript-eslint/recommended"  ]}
functiontest(){return'test';consta='a';}Label:{test();}

Expected Result

The unreachable code and the unused label should both be handled by either TypeScript or by theeslint:recommended rules.

Actual Result

With default settings, the unused label is flagged as invalid both by VSCode (dims the text and provides the reason: "Unused label.ts(7028)") and when linting ("'Label:' is defined but never used.eslint(no-unused-labels)"). The unreachable code is only flagged as invalid by VSCode (dims the text and provides the reason: "Unreachable code detected.ts(7027)").

Additional Info

Based upon my understanding of the eslint-recommended, any rule that is handled by the TypeScript compiler by default should be disabled by this config. I'm curious if this stance holds even for the rules above that are not considered errors in TypeScript by default.

It might be good to document that stance a bit better. That seems like the decision from#1041, though it seems that nothing was ever done to enhance the documentation.

Documentation aside, I think that it at least makes sense to be as consistent as possible with how the eslint-recommended config handles rules that overlap with TypeScript.

Versions

It's worth pointing out along with these versions that as ofv5.19.0, the rules in questionstill have the same settings as in my local versions

packageversion
@typescript-eslint/eslint-plugin4.3.0
@typescript-eslint/parser4.3.0
TypeScript4.0.5
ESLint7.31.0
node14.19.0

Metadata

Metadata

Assignees

No one assigned

    Labels

    accepting prsGo ahead, send a pull request that resolves this issuedocumentationDocumentation ("docs") that needs adding/updatinglocked due to agePlease open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing.package: eslint-pluginIssues related to @typescript-eslint/eslint-plugin

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp