gund / eslint-plugin-deprecation Goto Github PK

I read the README extensively and it was difficult for me to understand what this plugin does.

At the beginning it says that's a rule for deprecated code, but it's not easy to understand what's deprecated code.

The rest is about installation and set up.

I ended up looking at the tests.

Maybe before the installation header, the documentation should show an example of what the rule does.

see https://github.com/SonarSource/SonarJS/blob/3e3a662019d460bef8729f1e88ae82ff70ecf102/eslint-bridge/package.json#L43-L44

Usages of the chrome API, defined in this types - https://www.npmjs.com/package/@types/chrome, cause deprecation errors.

E.g. the following code

chrome.tabs.query({});

leads to this error:

deprecation_chrome/index.ts
  1:1  error  'chrome' is deprecated. Part of the deprecated Chrome Apps platform  deprecation/deprecation

whereas the API is not marked as deprecated

/**
 * Gets all tabs that have the specified properties, or all tabs if no properties are specified.
 * @since Chrome 16
 * @return The `query` method provides its result via callback or returned as a `Promise` (MV3 only).
 */

Message Part of the deprecated Chrome Apps platform is used a few times in the types, but has nothing to do with chrome.tabs.query.

Reproduction - https://github.com/WiseBird/deprecation_chrome

I've encountered a false positive while updating faker. The problem is that faker is using TypeScript's function overload to type the signature of some methods. Some overloads are valid, while others are deprecated. Something like this:

foo(value: number): void;
/**
 * @deprecated use numeric inputs instead
 */
foo(value: string): void;

In this case, foo(1) is valid while foo('1') is deprecated.

I believe ESLint can't correctly handle this use case. Imagine this code:

foo(value);

Is value a number or a string? We can only know if we're at runtime or if we start integrating heavily with TypeScript.

In cases like this, where there's a function overload, and only some of the declarations are deprecated, I suggest this plugin ignores the code altogether.

For an example of a real-world failing code see https://github.com/faker-js/faker/blob/293f12741acb188fd8c7d9d6b3dc2dd9b52d4214/src/modules/date/index.ts#L70-L190

Currently, using [email protected], eslint-plugin-deprecation fails with the following error:

An unexpected error occurred:
TypeError: context.getAncestors is not a function
Occurred while linting /Users/k/p/project/eslint.config.js:1
Rule: "deprecation/deprecation"
    at getParent (/Users/k/p/project/node_modules/eslint-plugin-deprecation/dist/rules/deprecation.js:86:31)
    at isDeclaration (/Users/k/p/project/node_modules/eslint-plugin-deprecation/dist/rules/deprecation.js:94:20)
    at identifierRule (/Users/k/p/project/node_modules/eslint-plugin-deprecation/dist/rules/deprecation.js:60:13)
    at ruleErrorHandler (/Users/k/p/project/node_modules/eslint/lib/linter/linter.js:1059:28)
    at /Users/k/p/project/node_modules/eslint/lib/linter/safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit (/Users/k/p/project/node_modules/eslint/lib/linter/safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (/Users/k/p/project/node_modules/eslint/lib/linter/node-event-generator.js:297:26)
    at NodeEventGenerator.applySelectors (/Users/k/p/project/node_modules/eslint/lib/linter/node-event-generator.js:326:22)
    at NodeEventGenerator.enterNode (/Users/k/p/project/node_modules/eslint/lib/linter/node-event-generator.js:340:14)

It looks like there's a blog post about preparing rules for ESLint v9 here:

• https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/

From a quick look, it appears that context.sourceCode.getAncestors(node) should be used instead.

I've made a minimal repro here

with ts: 4.1 - https://github.com/johnjesse/ts-dep-issue/tree/ts-4.1
and ts: 4.2 - https://github.com/johnjesse/ts-dep-issue/tree/ts-4.2

it's actually wrong in both cases - it doesn't cope with overloads well and incorrectly doesn't mark any of the overloads as deprecated with ts 4.1 - and all of them as deprecated with ts 4.2

I've opened this issue to track it - and for visibility - I'll take a look at fixing the rule and test it against my case

For example, this would not cause anything to be flagged:

/**
 * @deprecated
 */
function foo() {
  call_to_deprecated_function();
}

But if @deprecated is removed from foo, then call_to_deprecated_function is flagged.

If I get some free time I might look into making a PR for this.

In a rather large project, that unfortunately I'm not at liberty to share, performance of this plugin is a bit dissappointing.

The result of this is not only that it might take a very long time to lint the entire project, but more importantly, in VScode with lint-fixing on save enabled, it will take several seconds for each save action to complete.

I understand it's difficult to get this problem fixed in this particular repository, however, there just might just be a workaround 😎

Inspired on this more generic issue and this preceeding issue, the solution appears to be this piece of VScode configuration:

    "eslint.enable": true,
    "eslint.useESLintClass": true,
    "eslint.codeActionsOnSave.rules": [
        "!deprecation/deprecation",
        "*",
    ],
    "editor.codeActionsOnSave": {
        "source.fixAll": false,
        "source.fixAll.eslint": true
    },

Essentially skipping the deprecation/deprecation rule. This is fine, because the rule only checks code, but doesn't provide fixes, which is exactly the only thing linting on save is good for. The other bits of config are important to get the VScode extension to understand the rules setting in the first place.

Now, I realise that this only fixes it for VScode (well, it does on my machine), so if you enjoy a different editor, you might have to seek out a different solution. However, the above configuration might nudge that search in the right direction. I would not be surprised if eslint plugins for other editors have a similar rules setting to filter certain rules.

And perhaps it's a good idea to list those solutions below, when anyone finds one.

I have tried to use this lint rule for react deprecated props. But it does not work:

export type Alpha = {
  /** @deprecated */
  abc: string;
  def: string;
}
const alpha: Alpha = { abc: 'a', def: 'd' }; <-- does not display lint error
alpha.abc = 'b'; <-- display lint error

I will try to make a PR for this in the future.

Running this plugin results in out of memory error

<--- Last few GCs --->

[93771:0x110040000]    29282 ms: Scavenge 4043.7 (4125.2) -> 4040.7 (4126.4) MB, 13.2 / 0.0 ms  (average mu = 0.870, current mu = 0.542) allocation failure;
[93771:0x110040000]    29312 ms: Scavenge 4044.6 (4126.4) -> 4042.6 (4130.2) MB, 10.7 / 0.0 ms  (average mu = 0.870, current mu = 0.542) allocation failure;
[93771:0x110040000]    29651 ms: Scavenge 4048.6 (4130.6) -> 4046.6 (4148.1) MB, 316.4 / 0.0 ms  (average mu = 0.870, current mu = 0.542) allocation failure;


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

This issue tracks a support for Typescript v5.

Before the following steps are done Typescript v5 support will NOT land into latest release:

• Update Typescript to v5 in dev dependencies and make sure tests are passing
• Add backwards compatibility tests for Typescript v4
• Add stable Typescript v5 to peer dependencies
• Typescript v5 is released as stable

If you already would like to play around with Typescript v5 beta you can try @next NPM tag version of this package which includes Typescript v5 beta in it's peer dependencies.

If you find any issues with it you may report them in this issue or open a PR to next branch with a fix.
Any fixes merged into next branch will be automatically released under @next NPM release tag.

I noticed this more or less accidentally - if you e.g. have code like this:

interface MyInterface {
  /**
   * This is old!
   * @deprecated Do not use this anymore.
   */
   oldProp?: string;
}

class MyClass implements MyInterface {
  /** @inheritDoc /*
  oldProp?: string;
}

const obj = new MyClass();
obj.oldProp = 'xx'; // does not raise an eslint error :(

Honestly I am not sure how easy it is to fix this, but got bitten by this quite a bit because I expected this to work 😅

Hi, with the following setting

"deprecation/deprecation": "warn"

I get warnings from my barrel (index.ts)

Like this

~\Repos\akita\libs\akita\src\lib\index.ts
  4:10  warning  'arrayAdd' is deprecated.      deprecation/deprecation

But it's not using anything, it's exporting

export { arrayAdd } from './arrayAdd';

Another thing. It's warning about functions from my own source files that have been marked as @deprecated. Perhaps that could be an option if it should do that or not.

export function arrayAdd<Root extends any[], Entity = any>(keyOrRoot: Root, newEntity: OrArray<Root[0]>, options?: AddEntitiesOptions): Root[0][];
/**
 * @deprecated
 */
export function arrayAdd<Root, Entity = any>(keyOrRoot: ArrayProperties<Root>, newEntity: OrArray<Entity>, options?: AddEntitiesOptions): (state: Root) => Root;
export function arrayAdd<Root, Entity = any>(keyOrRoot: ArrayProperties<Root> | Root, newEntity: OrArray<Entity>, options: AddEntitiesOptions = {}) {
  ...
}

The plugin currently is reporting errors at the spot where deprecated interfaces and enums (but not variables or classes) are defined, which seems wrong.

These cases incorrectly show errors at the line where the thing is defined:

/** @deprecated */
interface Thing {}
/** @deprecated */
enum Color {}
/** @deprecated */
type OtherString = string;

These cases behave correctly (no error at definition):

/** @deprecated */
const a = 1;
/** @deprecated */
let b = 2;
/** @deprecated */
var c = 3;
/** @deprecated */
class Thing2 {}
/** @deprecated */
function foo() {}

I noticed that this plugin does not warn for usage of deprecated jsx props.
Since we needed this, I've written this plugin: https://github.com/sebakerckhof/eslint-plugin-deprecated-jsx-props

I originally started with bringing https://github.com/Drawbotics/eslint-plugin-deprecated-props up to date, but its approach is fundamentally flawed, so I ended up rewriting most of it.

Anyway, it seems to work well on our codebase, but I have no desire to maintain it and therefore I wanted to check if you're interested in adopting it as part of this plugin. I could make a PR for it if you're interested.

It has tests to ensure it works with:

• local types and interfaces
• external types and interfaces
• combined / extended types and interfaces
• spread arguments (for which we make the distinction between optional and required props)

After updating typescript-eslint 4.33.0 to 5.0.0, all deprecated class members are show an error in the definition.

Example:

class Dog {
  sprint();

  /**
   * @deprecated Use {@link sprint} instead
   */
  walk();
}

The method walk would be highlighted as deprecated in the class definition.

I'm using TypeScript 4 in a few projects and it triggers a warning that this plugin specifies TypeScript ^3.7 as a peerDependency.

Should the peerDependency be changed to include TS4?

I read the comment before creating the issue, but I have a small hope that somebody can help me :-)

I have the following behavior:

• VS Code correctly finds deprecations from the "sequelize" library (_attributes)
• eslint-plugin-deprecation correctly finds deprecations inside our own codebase.
• eslint-plugin-deprecation does not find the deprecation from "sequelize".

import { DataTypes, Model, ModelAttributeColumnOptions } from 'sequelize';

export class Dummy extends Model<IDummy, Partial<IDummy>> { ... }

// Model._attributes is deprecated.
export const dummyAttributes = (dataTypes: typeof DataTypes): ModelAttributes<Dummy, Dummy['_attributes']> => ({
    ...
});

tsconfig.json:

{
	"compilerOptions": {
		"target": "es2020",
		"module": "commonjs",
		"rootDir": "./",
		"outDir": "./build",
		"esModuleInterop": true,
		"strict": true,
		"allowSyntheticDefaultImports": true,
		"noImplicitAny": false,
		"resolveJsonModule": true,
		"experimentalDecorators": true,
		"emitDecoratorMetadata": true,
		"sourceMap": true
	}
}

The ESLint config is the same as your example in the README.

One feature this plugin is missing compared to the tslint deprecation rule is detecting usage of deprecated interface/type properties. For example:

interface Thing1 {
  /** @deprecated */
  foo?: string;
}
const a: Thing1 = { foo: 'b' }; // should be an error
a.foo = 'c'; // correctly detected as error

type Thing2 = {
  /** @deprecated */
  foo?: string;
}
const b: Thing2 = { foo: 'c' }; // should be an error
b.foo = 'd'; // correctly detected as error

Seems that the deprecation message is shown as [object Object], after upgrading TypeScript 4.3:

In the following scenario, when calling method() on an instance of the New class, the plugin should not report an error, but it does:

class Old {
  /** @deprecated */
  method(): void {
  }
}

class New extends Old {
  method(): void {
  }
}

new Old().method(); // should throw an error -> everything fine
new New().method(); // should not throw an error -> still throws an error

Updating ESLint to v8 leads to:

Oops! Something went wrong! :(

ESLint: 8.0.0

TypeError: Failed to load plugin 'deprecation' declared in '.eslintrc.js': Class extends value undefined is not a constructor or null
    at Object.<anonymous> (/home/boris/project/node_modules/eslint-plugin-deprecation/node_modules/@typescript-eslint/experimental-utils/dist/ts-eslint/CLIEngine.js:12:34)
    at Module._compile (/home/boris/project/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (/home/boris/project/node_modules/v8-compile-cache/v8-compile-cache.js:159:20)
    at Object.<anonymous> (/home/boris/project/node_modules/eslint-plugin-deprecation/node_modules/@typescript-eslint/experimental-utils/dist/ts-eslint/index.js:14:14)
    at Module._compile (/home/boris/project/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)

Describe usage, or point to original documentation.

What is considered deprecation? How do you define deprecations? Is some annotation like @deprecated used in docblocks?

The second required disable comment shouldn't be needed/the lint error is reported incorrectly.

function demo(
  options: {
    /**
     * @deprecated
     */
    deprecated?: boolean;
    replacement?: boolean;
  } = {}
): boolean {
  const {
    // eslint-disable-next-line deprecation/deprecation
    deprecated = false,
    // eslint-disable-next-line deprecation/deprecation
    replacement = deprecated,
  } = options;
  return replacement;
}

As you can see VSCode's code highlighting shows that the second line is not deprecated/striked-through:

Because it references a local variable instead of the deprecated property.

The first disable comment is expected/required as per #74.

Hello, and thanks for the plugin, which I use in my TypeScript projects.

Most ESLint plugins contain a recommended config, which simplifies usage of the plugin.

Since this plugin only provides one rule, a recommended can simply setup for end users. Such a config would automatically enable the plugin and automatically enable the rule.

In other words, this is currently the config that I have to have in order to use this plugin:

const config = {
  plugins: [
    "deprecation",
    // Other plugins enabled here.
  ],
  rules: {
    "deprecation/deprecation": "error",
    // Other rules enabled here.
  },
};

But this could/should be simplified to:

const config = {
  extends: [
    "plugin:deprecation/recommended",
  ],
};

If you agree that this is a good idea, I will submit a PR, as setting this up is relatively simple.

It would be nice to have an option to ignore own deprecated code.
(Own code = code imported from within the same project and not via dependency)

I would like to turn off deprecation warnings inside my tests, because deprecated code still needs tests, but I would like to know if other libraries that I use in the tests are getting deprecated.

Filing for tracking purposes; I may be able to contribute a PR.

Currently if I have a deprecated react component:

/** @deprecated */
class OldStuff extends React.Component {
  ...
}

and I use it:

ReactDOM.render(<OldStuff />, ...);

then I don't get a warning. I would like this to produce a lint failure.

Separately from #78: ESLint 8 already supports flat config, in advance of ESLint 9. Would a small PR that adds in flat config before the full #79 lands be of interest?

The following code should not report/require suppression comments for deprecation errors:

function demo(
  options: {
    /**
     * @deprecated
     */
    deprecated?: boolean;
    replacement?: boolean;
  } = {}
): boolean {
  const {
    // eslint-disable-next-line deprecation/deprecation
    deprecated = false,
    // eslint-disable-next-line deprecation/deprecation
    replacement = deprecated,
  } = options;
  return replacement;
}

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

type T = {
	new?: string;
	/** @deprecated */
	old?: string;
};
const myT: T = { 
	// I'd expcect an ESLint warning here, but there is none
	old: 'value'
};

console.info(myT.old); // I only get a warning here

How it looks in VSCode:

In fact VSCode doesn't warn (with a strike-through) about this either.

Hey folks!

I just wanted to address the maintenance issue that this plugin experienced and affected some (or many?) people.

I won't go into details of reasons but I would be happy to get a few more people in to help maintain this project so this situation does not happen again.

I would first extend my invite to some folks who have actively contributed PRs but you can also propose yourself in the comments.

So would any of you guys like to take up the maintenance role of this repo:

• @Delagen
• @gluxon
• @ecraig12345
• @kirkobyte

Please let me know if you are interested.
I'm looking for 2-3 people so there is always someone to merge a PR =)

Cheers!

When we try to use it in Angular 12, it never finds config and throws error as
"An unhandled exception occurred: Failed to load config "plugin:deprecation" to extend from.

Is there any thing different needs to be done to use it in Angular Please suggest?
We are already using below 3 plugins without any issue
"plugin:@angular-eslint/recommended",
"plugin:@typescript-eslint/recommended",
"plugin:@angular-eslint/template/process-inline-templates",

When installing this plugin on a TypeScript 4 project, I get the error described in #11 (and fixed in #12). However, since this plugin hasn't been published to NPM since #12 was merged, the fix isn't yet doing anything.

Would it be possible for an updated version to be published to NPM?