no-deprecated
Forbid imported names marked with @deprecated documentation tag
š¼ This rule is enabled in the following configs: recommended, typescript.
š” This rule is manually fixable by editor suggestions.
Rule Details
Using an API whose declaration marks it deprecated is reported. The mark is a JSDoc @deprecated tag, a marker listed in deprecationMarkers (which adds to @deprecated, it does not replace it), or a @deprecated decorator.
- Imported:
import { old } from './api'(also renamed, or the default) depends on a deprecated export and is reported at the import. Through a namespace import, each read ofns.old/ns['old']is reported. The other module is read through TypeScript, so imports are only judged with type information (parserOptions.projectorprojectService); without it, the other module is unknown and the rule is silent about imports. - Declared in the same file: each use of the deprecated binding is reported (
old(),new Old(),Old.member,const v = old). The rule decides by binding: a parameter or an object key that shares the name is not the deprecated item, and a deprecated declaration nobody uses is not a finding.
allow lists names that are never reported (for a migration period). checkJSDoc: false ignores JSDoc marks and checkDecorators: false ignores decorator marks.
ā Incorrect
// ./api.ts
/** @deprecated Use fetchUser instead. */
export function getUser() {}
// app.ts
import { getUser } from './api';/** @deprecated Use NewClient instead. */
class OldClient {}
new OldClient();ā Correct
import { fetchUser } from './api';
/** @deprecated Use NewClient instead. */
class OldClient {}
const config = { OldClient: true };
const build = (OldClient: () => void) => OldClient();Options
[
{
"type": "object",
"properties": {
"allow": {
"type": "array",
"items": {
"type": "string"
},
"description": "List of deprecated items that are allowed (for migration periods)"
},
"deprecationMarkers": {
"type": "array",
"items": {
"type": "string"
},
"default": [
"@deprecated"
],
"description": "Custom deprecation markers to look for in comments"
},
"checkJSDoc": {
"type": "boolean",
"default": true,
"description": "Check for @deprecated in JSDoc comments"
},
"checkDecorators": {
"type": "boolean",
"default": true,
"description": "Check for @deprecated decorator in TypeScript"
}
},
"additionalProperties": false
}
]Implementation
OWASP Foundation
- Category: A09:2021 - Security Logging and Monitoring Failures
Use this rule
npm install -D oxlint-plugin-import-next{ "jsPlugins": ["oxlint-plugin-import-next"], "rules": { "import-next/no-deprecated": "error" }}import { defineConfig } from 'vite-plus';export default defineConfig({ lint: { jsPlugins: ['oxlint-plugin-import-next'], rules: { 'import-next/no-deprecated': 'error', }, },});oxlint-plugin-import-next re-exports eslint-plugin-import-next/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.
Did this rule catch something? Star the repo to get new CWE coverage as we ship it ā or follow the AI-code-security benchmarks behind these rules.