Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

noUnusedLocals should be reported as a warning, not an error #40058

Closed
5 tasks done
octogonz opened this issue Aug 14, 2020 · 2 comments
Closed
5 tasks done

noUnusedLocals should be reported as a warning, not an error #40058

octogonz opened this issue Aug 14, 2020 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@octogonz
Copy link

Search Terms

TS6133 6133 noUnusedLocals

This is related but more general: #13408

Suggestion

This ts.Diagnostic message is classified as an Error not a warning:

    "'{0}' is declared but its value is never read.": {
        "category": "Error",
        "code": 6133,
        "reportsUnnecessary": true
    },

Examples

Suppose someone is writing new code and not quite finished yet.

const x: number = 123;
const y: number = 321;
const product: number = x*y;

// TODO: Do something with "product"

They have not used x yet, but they certainly plan to use it when they are done writing their code. When you run tsc the output looks like this:

src/index.ts:9:5 - error TS6133: 'x' is declared but its value is never read.

With a professional build orchestrator, this "compiler error" will:

  • be printed in bright red, distracting attention from legitimate errors (e.g. calling a function that is not defined)
  • prevent downstream dependency projects from building
  • possibly also prevent other tasks (e.g. Jest) from running for the current project (we don't run tests if the code doesn't compile)

Proposal: Make it a warning instead:

    "'{0}' is declared but its value is never read.": {
        "category": "Warning",
        "code": 6133,
        "reportsUnnecessary": true
    },

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Aug 17, 2020
@RyanCavanaugh
Copy link
Member

This is entirely predicated on #13408, so should just be tracked there.

@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants