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

Highlight unused symbols #15710

Closed
mindplay-dk opened this issue Nov 18, 2016 · 27 comments · Fixed by #49646
Closed

Highlight unused symbols #15710

mindplay-dk opened this issue Nov 18, 2016 · 27 comments · Fixed by #49646
Assignees
Labels
feature-request Request for new features or functionality javascript JavaScript support issues on-testplan typescript Typescript support issues
Milestone

Comments

@mindplay-dk
Copy link

I'd like to request an improvement to Typescript support: highlighting of unused symbols.

Refactoring and moving things around between files often leads to a lot of manual analysis, for example to find imports that are no longer in use.

This doesn't need to be a big, complex feature - I don't expect this to trawl through the entire codebase and figure out what is or isn't in use.

I'd be happy with just file-local highlighting - e.g. gray out variable and constant declarations if they aren't exported or used in any expression or statement anywhere in the file.

@mindplay-dk
Copy link
Author

If possible, in addition, a right-click option to clean up unused symbols would be useful :-)

@ramya-rao-a ramya-rao-a added the typescript Typescript support issues label Nov 18, 2016
@waderyan
Copy link

Thank you for your feature request! We have discussed this internally and have considered adding it soon.

@waderyan waderyan added the feature-request Request for new features or functionality label Nov 22, 2016
@waderyan waderyan changed the title Typescript, feature: highlight unused symbols Highlight unused symbols Nov 22, 2016
@mjbvz mjbvz self-assigned this Jan 26, 2017
@jschlieber
Copy link

Webstorm has it and it is really really handy! Would love to have it in VSCode for TypeScript and JavaScript.

@mjbvz
Copy link
Collaborator

mjbvz commented Feb 11, 2017

Related API request #20219

@mjbvz
Copy link
Collaborator

mjbvz commented Apr 3, 2017

#23805 Notes that we could also investigating graying out unreachable code

@PDS42
Copy link

PDS42 commented Jun 22, 2017

Sorry if that's not the right place to ask this, but is this being implemented anytime soon (local unused variables)? It would be a huge improvement IMO. This is the only reason that makes me consider switching to WebStorm, though I really enjoy VS!

@mindplay-dk
Copy link
Author

Storm is generally awful at Typescript, but yes, I occasionally find myself opening Storm just to check for unused symbols. Would be great to have this.

@cute-angelia
Copy link

today one unused variables make me error, i hope vs can support it

@justnewbee
Copy link

i'm reading through this issue for i want this too, please make it happen.
and also, highlighting exports that are not referenced anywhere in the project would be much better

@WeiGrand
Copy link

WeiGrand commented Nov 5, 2017

I think i could get rid of Storm with this feature~

@mjbvz mjbvz added the javascript JavaScript support issues label Nov 15, 2017
@demisx
Copy link

demisx commented Dec 8, 2017

Would love this feature as well. A major hiccup in refactoring that forces me to switch to WebStorm to run these checks. I'd rather stay in VS Code the entire time. Please, please, make this happen.

@adrienharnay
Copy link

I am also using Webstorm just for this feature. Would make switching a breeze! Thanks for the work put into VSCode

@Ccz-Chen
Copy link

Two of our projects in JavaScript. I am interested in the feature. Thanks,

@kubante
Copy link

kubante commented Feb 1, 2018

+1

2 similar comments
@sshmyg
Copy link

sshmyg commented Feb 8, 2018

👍

@janakact
Copy link

+1

@PDS42
Copy link

PDS42 commented Feb 14, 2018

If you guys could just use thumbs up emojis instead of flooding issues with +1, my inbox and I
would be super grateful.

@jcezarms
Copy link

Would like to add my support to this feature. To some developers, it is not particularly a personal preference, but a requirement coming from the enterprise Quality Gates, that may detect and reject code containing unused variables (my current scenario).

@gharibi
Copy link

gharibi commented Feb 16, 2018

I will surely get rid of WebStorm as soon as this gets implemented!

@vlodko
Copy link

vlodko commented Feb 21, 2018

@here to everyone who is using VS Code for TypeScript development.
Put this two properties totsconfig.json in compilerOptions section:

{
  "compilerOptions": {
    "noUnusedLocals": true,
    "noUnusedParameters": true,
....

It will highlight the variable or class member with green curly line (at least it looks like that with my color theme):
image

Also in Problems panel you will see a warning:
image

Read more about compiler options here

@erezLieberman
Copy link

+1

@dominique-mueller
Copy link

Hey to all, look what I've found a few days ago: This awesome extension not only allows to remove unused imports, but - following my feature request - now also highlights them: TypeScript / JavaScript Deporter.

The visuals could use some improvements, but overall it it works like a charm in my projects!

@dominique-mueller
Copy link

@mjbvz
Copy link
Collaborator

mjbvz commented Mar 23, 2018

Depends on microsoft/TypeScript#22361

As already noted, you can already enable this using settings in your jsconfig / tsconfig. This issue specifically is now tracking:

  • Allowing this you to see unused symbols even when you don't have a jsconfig or tsconfig and have not configured these settings

  • Possibly presenting unused symbols in a different way. Graying out these symbols is one idea

@ghost
Copy link

ghost commented May 9, 2018

There's now a ... under unused symbols. Graying out might be a good idea though.
@mjbvz I notice that some unused diagnostics are red and others are green. (This is with --noUnusedLocals enabled, so they're errors and not suggestions.) The diagnostics should all have reportsUnnecessary, so if you are still matching against a list of error codes, I would change to using that property instead.

green_red

mjbvz added a commit that referenced this issue May 10, 2018
Gated behind undocumented setting. Requires proper vscode API

Part of #15710
@mjbvz mjbvz modified the milestones: Backlog, May 2018 May 10, 2018
mjbvz added a commit that referenced this issue May 10, 2018
Fixes #15710

Adds a new `DiagnosticTag` class that provide additional information about a diagnostic. Introduce `DiagnosticTag.Unnecessary` to mark when a diagnostic is for unused / unnecessary code

The design comes from Rosyln's diagnostic object and allows us to modify how a diagnostic is rendered without changing its serverity.

Hooks up JS and TS to use this new tag. This is controlled by the `javascript.showUnused.enabled` setting which is enabled by default

- Introduce a new diagnostic severity for unused.

    However, using this approach, if a user sets `noUnusedLocals` in their `tsconfig.json`, the resulting diagnostic could only show the squiggly OR be grayed out. Using `customTags` allows us to support both graying out and showing the squiggly

- Custom JS/TS implementation using decorators

    Not themable. We want a standard experience across languages.
mjbvz added a commit that referenced this issue May 17, 2018
Fixes #15710

Adds a new `DiagnosticTag` class that provide additional information about a diagnostic. Introduce `DiagnosticTag.Unnecessary` to mark when a diagnostic is for unused / unnecessary code

The design comes from Rosyln's diagnostic object and allows us to modify how a diagnostic is rendered without changing its serverity.

Hooks up JS and TS to use this new tag. This is controlled by the `javascript.showUnused.enabled` setting which is enabled by default

- Introduce a new diagnostic severity for unused.

    However, using this approach, if a user sets `noUnusedLocals` in their `tsconfig.json`, the resulting diagnostic could only show the squiggly OR be grayed out. Using `customTags` allows us to support both graying out and showing the squiggly

- Custom JS/TS implementation using decorators

    Not themable. We want a standard experience across languages.
mjbvz added a commit that referenced this issue May 17, 2018
* Add unused diagnostic subtype

Fixes #15710

Adds a new `DiagnosticTag` class that provide additional information about a diagnostic. Introduce `DiagnosticTag.Unnecessary` to mark when a diagnostic is for unused / unnecessary code

The design comes from Rosyln's diagnostic object and allows us to modify how a diagnostic is rendered without changing its serverity.

Hooks up JS and TS to use this new tag. This is controlled by the `javascript.showUnused.enabled` setting which is enabled by default

- Introduce a new diagnostic severity for unused.

    However, using this approach, if a user sets `noUnusedLocals` in their `tsconfig.json`, the resulting diagnostic could only show the squiggly OR be grayed out. Using `customTags` allows us to support both graying out and showing the squiggly

- Custom JS/TS implementation using decorators

    Not themable. We want a standard experience across languages.

* - Move to proposed
- Use numeric enum
@carpet92
Copy link

Is this works only for JavaScript and TypeScript?

@ghost
Copy link

ghost commented Jun 25, 2018

@Zx-EvM Just JS/TS, maybe you should open an issue with a language plugin that you think should support this too. But it would be a lot of work if that language doesn't support unused variables yet; for this issue TypeScript already supported detecting unused variables and all we had to do was send that info to the editor.

@vscodebot vscodebot bot locked and limited conversation to collaborators Jul 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality javascript JavaScript support issues on-testplan typescript Typescript support issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.