An equivalent rule for unused imported `@typedef` similar to `no-unused-vars`

[leekahung]

Motivation

Hey everyone, been digging around the issues with regards to rules that relates to @typedef, but I don't see one so far or I might have missed it. If there is an issue already resolved or closed, would be happy to be linked to that. For now, I would like to open a feature request for the following.

At the moment, there's no way to check if an imported @typedef is no longer in use from existing rules in the plugin that's similar to an unused declared variable or unused library/package. ESLint does not produces no warnings or errors for @typedefs. Thus it up to the developer to manually spot and remove code that's no longer in use.

Current behavior

Currently, there are no warnings/errors for unused @typedefs from ESLint.

Desired behavior

With this new feature, it'll produce a warning or error for unused @typedefs from ESLint.

Alternatives considered

Creating a custom rule (no-unused-typedefs) specifically for @typedef

[leekahung]

Oh, never mind. Looks like it's possible to import JSDoc typedefs now.

Sorry for the inconvinence, I'll close this issue.

[leekahung]

Actually, it would seem like the problem would still persist if I were to import it instead with JavaScript since importing just JSDoc types wouldn't be supported.

For example, if I were to have:

// typedefs.js
/**
 * @exports foo
 * @typedef {object} foo
 * @property {string} bar
 */

exports.unused = {};

And import { foo } from "typedefs.js" in a different file to use it, the editor would pick it up, but would the browser would complain when starting a dev/production server since it's not exactly a "module" and you're not really importing "foo". The original idea from the description might still be better.

[stwlam]

Perhaps this issue is more actionable with the @import tag now in play. Equivalents to both no-used-vars and no-undef are theoretically possible with both @typedefs and also "real" variables.

[brettz9]

ESLint does not provide to plugins information on one's whole project, so we cannot report on whether @import, import or import() (the latter is also usable within JSDoc tags like @param) are being used in external files. I do think we could, however, in theory be open to an optional, non-default rule which checks whether typedefs are used within the same file for those projects which, for whatever reason, want the typedefs to be at least used within the same file (because it could be a sign of being unused, because they consider it good practice to have it actually used where it is placed, etc.). This would not be for projects which placed their data in typedefs files (unless they had ESLint exclude their typedefs files).

[github-actions]

🎉 This issue has been resolved in version 60.3.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀