Show unused public properties and methods

[jabacchetta]

It would be nice to have unused detection expanded, capable of detecting unused methods, exports, etc.

Code Example

Shape.js

class Shape {
    constructor() {
        this.color = 'red';
    }

    colorLog() {
        console.log(this.color);
    }
}

export default Shape;

Circle.js

import Shape from "./Shape";

class Circle extends Shape {
  constructor() {
    super();

    // FIXME: description should show as unused in VSCode, as it does in WebStorm.
    this.description = 'A circle shape';
  }

  // FIXME: circleLog should show as unused in VSCode, as it does in WebStorm.
  circleLog() {
    // NOTE: both VSCode and WebStorm have detected an unused variable.
    const num = 2;

    // NOTE: colorLog is being used, so no unused code errors in Shape.js file.
    super.colorLog();
  }
}

// FIXME: export should show as unused in VSCode, as it does in WebStorm.
export default Circle;

VSCode Screen

WebStorm Screen

[mjbvz]

We currently assume that exported members form a public API and therefore are always used. We could try to detect that a certain set of files are an API entrypoints, and then mark unused internal exports. Not sure if there are any issue already tracking this

[auchenberg]

Customer demand for this feature mentioned in https://dev.to/mokkapps/why-i-switched-from-visual-studio-code-to-jetbrains-webstorm-939.

[zpdDG4gta8XKpMCd]

what about exported but unused

• modules
• classes
• types
• interfaces/props
• members (enum | union)
• functions
• constants/variables?

[fatihturgut]

is there any news about this issue?

[jp7837]

Update: much faster after adding dummy getProjectVersion implementation assuming the project doesn't change during execution.

My naive solution below. It's pretty slow even though it should only run a full compilation once. I'll post updates if I improve it.

const fs = require("fs");
const ts = require("typescript");
const path = require("path");

// Copied from https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API#incremental-build-support-using-the-language-services
function getLanguageService(rootFileNames, options) {
	const files = {};

	// initialize the list of files
	rootFileNames.forEach(fileName => {
		files[fileName] = { version: 0 };
	});

	// Create the language service host to allow the LS to communicate with the host
	const servicesHost = {
		getScriptFileNames: () => rootFileNames,
		getScriptVersion: fileName => files[fileName] && files[fileName].version.toString(),
		getScriptSnapshot: fileName => {
			if (!fs.existsSync(fileName)) {
				return undefined;
			}

			return ts.ScriptSnapshot.fromString(fs.readFileSync(fileName).toString());
		},
		getCurrentDirectory: () => process.cwd(),
		getCompilationSettings: () => options,
		getDefaultLibFileName: options => ts.getDefaultLibFilePath(options),
		getProjectVersion: () => 1,
		fileExists: ts.sys.fileExists,
		readFile: ts.sys.readFile,
		readDirectory: ts.sys.readDirectory,
	};

	// Create the language service files
	const services = ts.createLanguageService(servicesHost, ts.createDocumentRegistry());

	return services;
}

const tsconfigPath = "tsconfig.gen.json";
const basePath = path.resolve(path.dirname(tsconfigPath));
const parseJsonResult = ts.parseConfigFileTextToJson(tsconfigPath, fs.readFileSync(tsconfigPath, { encoding: "utf8" }));
const tsConfig = ts.parseJsonConfigFileContent(parseJsonResult.config, ts.sys, basePath);
const services = getLanguageService(tsConfig.fileNames, tsConfig.options);

// For each non-typings file
tsConfig.fileNames
	.filter(f => !f.endsWith(".d.ts"))
	.forEach(file => {
		const source = ts.createSourceFile(file, fs.readFileSync(file, { encoding: "utf8" }));
		ts.forEachChild(source, node => {
			if (ts.isClassDeclaration(node)) {
				// For each class member
				node.members.forEach(member => {
					// If member is marked as public or protected and not a constructor
					if (
						(ts.getCombinedModifierFlags(member) & ts.ModifierFlags.Public ||
							ts.getCombinedModifierFlags(member) & ts.ModifierFlags.Protected) &&
						member.kind !== ts.SyntaxKind.Constructor
					) {
						const references = services.findReferences(file, member.name.pos + 1);
						// Fail if every reference is a definition and not in a typings file
						if (
							references.every(
								reference =>
									reference.references.length === 1 &&
									reference.references[0].isDefinition &&
									!reference.definition.fileName.endsWith(".d.ts")
							)
						) {
							console.error(`File: ${file} , Member: ${member.name.text}`);
						}
					}
				});
			}
		});
	});

[alanhe421]

I was wondering if we could use custom rules to detect and fix this kind of problem

[Bogidon]

I would like this because using top-level exports, and destructuring imports can clutter your files quite a lot. E.g. I would like to make a Util class I can use the default import on, without worrying about forgetting to delete unused functions a year down the road.

Or would namespaces be a solution to this problem? (does unused code detection work on namespaces?)

[iulianraduat]

I am also interested to remove the kind of dead code mentioned by zpdDG4gta8XKpMCd .

Maybe Patricio Zavolinsky (pzavolinsky), creator of https://www.npmjs.com/package/ts-unused-exports, can help the Visual Code team to implement it?

[SigmaOutdoors]

Another vote for this feature, first priority IMO would be some kind of indication for unused variables - grey/red squiggles, don't care much.

[delucca]

No updates about this feature yet? This is present is most modern IDEs. It is a shame that VSCode doesn't support it.

[bencun]

This would be tremendously useful. Detecting and eliminating unused public methods, exports, etc. is something I feel Code is really missing at this point. Any updates on this feature?
I do understand it's a difficult task to undertake at this point, though.

[iulianraduat]

Until there is an official version, I created my own extension to find unused exports.
If you want to give it a try please install it from https://marketplace.visualstudio.com/items?itemName=iulian-radu-at.find-unused-exports
There are already requests to extend its functionality so if you feel the same, any help in this direction is much appreciated.

[ivan-myronov-windmill]

Update: much faster after adding dummy getProjectVersion implementation assuming the project doesn't change during execution.

My naive solution below. It's pretty slow even though it should only run a full compilation once. I'll post updates if I improve it.

const fs = require("fs");
const ts = require("typescript");
const path = require("path");

// Copied from https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API#incremental-build-support-using-the-language-services
function getLanguageService(rootFileNames, options) {
	const files = {};

	// initialize the list of files
	rootFileNames.forEach(fileName => {
		files[fileName] = { version: 0 };
	});

	// Create the language service host to allow the LS to communicate with the host
	const servicesHost = {
		getScriptFileNames: () => rootFileNames,
		getScriptVersion: fileName => files[fileName] && files[fileName].version.toString(),
		getScriptSnapshot: fileName => {
			if (!fs.existsSync(fileName)) {
				return undefined;
			}

			return ts.ScriptSnapshot.fromString(fs.readFileSync(fileName).toString());
		},
		getCurrentDirectory: () => process.cwd(),
		getCompilationSettings: () => options,
		getDefaultLibFileName: options => ts.getDefaultLibFilePath(options),
		getProjectVersion: () => 1,
		fileExists: ts.sys.fileExists,
		readFile: ts.sys.readFile,
		readDirectory: ts.sys.readDirectory,
	};

	// Create the language service files
	const services = ts.createLanguageService(servicesHost, ts.createDocumentRegistry());

	return services;
}

const tsconfigPath = "tsconfig.gen.json";
const basePath = path.resolve(path.dirname(tsconfigPath));
const parseJsonResult = ts.parseConfigFileTextToJson(tsconfigPath, fs.readFileSync(tsconfigPath, { encoding: "utf8" }));
const tsConfig = ts.parseJsonConfigFileContent(parseJsonResult.config, ts.sys, basePath);
const services = getLanguageService(tsConfig.fileNames, tsConfig.options);

// For each non-typings file
tsConfig.fileNames
	.filter(f => !f.endsWith(".d.ts"))
	.forEach(file => {
		const source = ts.createSourceFile(file, fs.readFileSync(file, { encoding: "utf8" }));
		ts.forEachChild(source, node => {
			if (ts.isClassDeclaration(node)) {
				// For each class member
				node.members.forEach(member => {
					// If member is marked as public or protected and not a constructor
					if (
						(ts.getCombinedModifierFlags(member) & ts.ModifierFlags.Public ||
							ts.getCombinedModifierFlags(member) & ts.ModifierFlags.Protected) &&
						member.kind !== ts.SyntaxKind.Constructor
					) {
						const references = services.findReferences(file, member.name.pos + 1);
						// Fail if every reference is a definition and not in a typings file
						if (
							references.every(
								reference =>
									reference.references.length === 1 &&
									reference.references[0].isDefinition &&
									!reference.definition.fileName.endsWith(".d.ts")
							)
						) {
							console.error(`File: ${file} , Member: ${member.name.text}`);
						}
					}
				});
			}
		});
	});

Any ideas how do the same for composed types transformed with Pick?

For example:

export type SessionStreamConfigurationFragment = (
  { __typename?: 'Session' }
  & Pick<Session, 'showRecording'>
  & { oneWayStreamConfiguration?: Maybe<(
    { __typename?: 'OneWayStreamConfiguration' }
    & OneWayStreamConfigurationFragment
  )> }
);

[jasonwilliams]

I had a similar query about unused exports which ive raised here: #30517

[jpike88]

this would be huge. I have an angular project with loads of classes with static methods that are probably not used anymore. It's too much to audit method by method.

[douglas-pires]

It would be very interesting to see this feature. I'm currently working on NestJS projects that would benefit from something like this.

[jpike88]

We have lots of dead public properties on our shared classes, it's painstaking to audit them, I have to use 'find all references' for each property in vscode.

[RyanCavanaugh]

knip is a pretty good solution to this.

Please refrain from posting low-value comments in this thread.

[jpike88]

Would knip find an unused public function on a component though? Those kinds of things are what I'm really looking to root out.

[RyanCavanaugh]

I'm not sure, but it's not even clear that TypeScript could do a good job of that. If you have something like

export class Foo {
  bar() { }
  baz() { }
}

interface HasBarAndBaz {
  bar(): void;
  baz(): void;
}

const p: HasBarAndBaz = new Foo();
p.baz();

It's not clear how you really figure out that Foo#baz is called while not mistakenly thinking Foo#bar isn't unused. Detecting unused properties vs detecting unused exports is really two different things.

[Papooch]

It's not clear how you really figure out [...]

In my opinion it is very clear that the desired behavior is to do what webstorm already does.

I'm torn between whether this should be a feature of the language itself or a feature of a separate tool, but in the end, all I really care about is that VSCode can tell me which public methods are unused by the rest of the code (for library code that's not consumed within the same codebase, it is also a good indicator of spotting untested methods)

[RyanCavanaugh]

I don't know what Webstorm's algorithm is or what its false positives/negatives are. Can you go into more detail on it?

[sixtyfive]

So it's 2024 and I had to touch Typescript for the first time today and within a few minutes wished for there to be a visual indicator for an unused method and landed here, in this Issue from 2019. Am I understanding correctly that even after 5 years this is still not possible and people are still being recommended Webstorm instead?

[dave0688]

You are absolutely correct. This is a shame!
VS Code is such a nice IDE, but there are some features which are just better in Webstorm...
I'm thinking of switching, since in quite some issues there is no movement.

[ShacharHarshuv]

Lol I just switched from Webstorm to VSCode because of issues in Webstorm... I guess the neighbor's grass is always greener.

I noticed that vscode has a setting named "typescript.referencesCodeLens.enabled" that is able to detect number of "references" for public methods as well (I assume this feature is provided by typescript). I wonder if it's possible to enable to configure a rule like "if this is 0, it should show as unused"
I'm not sure if this "algorithm" addresses concerns for false negative/positive pointed out by @RyanCavanaugh, but I assume that many users (including myself) will prefer to use it nontheless, and perhaps it would be a good enough reason to stay in VS Code rather than moving to Webstorm.

For now I'm trying to use this feature as a workaround, so at least I have some visual indication when something is not used (=not referenced)

[webpro]

Author of Knip here. Apart from the discussion what should be built-in to TS or what IDE is better, I just wanted to give a little heads up as to what Knip currently does (not), which might be of relief today:

• Knip finds unused files, exports and dependencies.
• From the OP code sample: it should find unused (default) export and it finds unused class members as well
• Knip is not a generic dead code finder, but built around a module and dependency graph to link up imports and exports. So it does a lot around that, and is less concerned about unused variables/members within a file. So when it comes to public APIs and exports and members of those exports, Knip might be able to help, also with settings such as includeEntryExports and a production mode.
• It's complementary to e.g. ESLint, tsc and tree-shaking.
• There are no IDE plugins, there's only a CLI atm. Various reporters, and running the default one has clickable links to files with issues including position. But not the red squigglies yet afaic.

By the way, recently I've been looking into Unused exported type & interface members. Unfortunately this will likely not be generally released, mostly for being too limited in scope, potential maintenance hell, etc. That said, if a codebase has similar structures as the examples in the provisional docs, it might be interesting to try it out. Who knows.

Happy to discuss any of this, but please file such feedback and issues specific to Knip in that repo or Discord.