no-deprecated
UnreleasedConfiguration
Reports imports and uses of exported names marked with a JSDoc @deprecated tag.
It also checks namespace members, including namespaces re-exported by other modules.
A block with both @module and @deprecated marks the entire module deprecated,
so even an import with no specifiers is reported.
Rule Details
Given answer.js:
Examples of incorrect code:
Examples of correct code:
Deprecated named and default imports are reported on the import specifier and again when used. Namespace imports are reported on deprecated member names. Local shadowing prevents reports for the shadowed binding. Computed namespace access and destructuring are not checked, matching upstream behavior.
Options
This rule has no options. JSDoc is enabled by default. Enable TomDoc comments
with the shared import/docstyle setting:
TomDoc marks an export with a leading // Deprecated: reason comment. Its first
paragraph supplies the reason. Module-level JSDoc is checked independently of
this setting.
Autofix
This rule has no autofix or suggestions.
Differences from upstream
- Dependency parser errors are handled by Rslint's compiler rather than emitted
as
import/no-deprecatedrule reports. Upstream's malformed-dependency test is retained as an explained skip. - A malformed unrelated documentation tag does not suppress a later
@deprecated. For example,@param {brokenbefore@deprecated use newAPIstops upstream's documentation parser before it sees the deprecation; Rslint still reports the deprecated export. Correct the malformed tag to obtain the same result in both tools. - Each identifier is checked against its own binding. Upstream decides from the
first same-name reference in the current scope, so it also reports a local
that shadows the import, uses of that local, and object property keys such
as
{ old: 1 }whenever that scope references the import elsewhere. Rslint reports only references that resolve to the deprecated import.