alexmost/eslint-plugin-deprecate

simple eslint rules for deprecation

eslint-plugin-deprecate's Issues

Multi-level member-expression rules support ?

"deprecate/member-expression": ["error",
    {"name": "history.go", "use": "newFunc from this package"}
]

// Normal case, Expected
history.go(); // ERROR

// Case 1, Not expected
window.history.go(); // PASSED
// Case 2, Not expected
const history = {};
history.go(); // ERROR
// Case 3, Not expected
const h = history;
h.go(); // PASSED

Case 3 is complicated for Lint, but Case 1 and 2 are so fragile, Is there any idea to solve this ?

support different error levels

'deprecate/import': [
'warn',
{ nameRegExp: 'legacy-module1', use: 'new-module1 instead', level: 'error' },
{ nameRegExp: 'legacy-module2', use: 'new-module1 instead', level: 'warn' },
],

After last upgrade error in rule deprecate/import

After plugin upgrade to "eslint-plugin-deprecate": "^0.8.0" the following error appears:

Oops! Something went wrong! :(

ESLint: 8.44.0

TypeError: Cannot read properties of undefined (reading 'name')
Occurred while linting D:\Projects\VUEIdeaIgniterEnvironment\client\src\services\AddFullDocumentView.ts:24
Rule: "deprecate/import"
    at MemberExpression (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint-plugin-deprecate\dist\rules\import.js:45:41)
    at ruleErrorHandler (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\linter.js:1050:28)
    at D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\node-event-generator.js:297:26)
    at NodeEventGenerator.applySelectors (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\node-event-generator.js:326:22)
    at NodeEventGenerator.enterNode (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\node-event-generator.js:340:14)
    at CodePathAnalyzer.enterNode (D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\code-path-analysis\code-path-analyzer.js:795:23)
    at D:\Projects\VUEIdeaIgniterEnvironment\client\node_modules\eslint\lib\linter\linter.js:1085:32

Putting off the deprecated/import rule solved the problem. BTW, this problem was absent in the previous version of the plugin.

OS: Windows 11
node: v19.8.1
npm: 9.7.2
eslint: v8.44.0

Thanks for looking!
mario

Peer dependency requirement failing when used with latest eslint ([email protected])

Command npm install eslint-plugin-deprecate --save-dev failing with installation error when attempted with latest eslint release

npm ERR! Darwin 17.3.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "eslint-plugin-deprecate" "--save-dev"
npm ERR! node v4.4.3
npm ERR! npm v2.15.1
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants eslint@^2.0.0 || ^3.0.0

Provide "plugin:deprecate/recommended"

Hi there, thanks for your work with this!

It would be great to have a recommended setting, like other eslint plugins.

So for the simplest use case, we would do:

{
  "extends": ["plugin:deprecate/recommended"]
}

Instead of:

{
    "plugins": ["deprecate"],
    "rules": {
        "deprecate/function": 2,
        "deprecate/member-expression": 2,
        "deprecate/import": 2
    }
}

The second version is always possible for users that want to customize the rules.
But for most, recommended settings are awesome!

Let me know if you're open to a PR!

deprecate/function always deprecates toString function name

This plugin incorrectly (I believe) always deprecates usage of the toString() function. Looking at the code in lib/rules/function.js, this is because funcs is initialized to the empty object {}, which has a toString method.

Deprecate named imports

Many times specific named exports are deprecated in a module, while other named exports are not deprecated. That means we can't use the existing 'deprecate/import' rule because its only parts of the module that are deprecated, not the entire module.

If we create a new eslint rule that allows us to name specific named exports to deprecate in a specific module, that would be super useful

If the eslint ruleset looked like this:

    'deprecate/import-name': [
      'error',
      { module: 'gatsby', name: 'navigate', use: 'utils/navigate' },
    ],

Then this javascript code would produce the following errors:

// Produces the error: 
// navigate from module gatsby is deprecated. Use utils/navigate instead
import { navigate } from 'gatsby';

// Produces the error:
// navigate from module gatsby is deprecated. Use utils/navigate instead
import { gql, navigate, Link } from 'gatsby';

// Produces no error
import { gql } from 'gatsby';

While this feature request is similar to #3, this rule would be linting the import of a method, not the usage of a method. Since it has become best practice to import specific names instead of the entire module, I feel this rule would be more useful than #3.

Versioning of this package is off

Hi @AlexMost,

I just wanted to use the latest version if eslint-plugin-deprecate with the fix you released yesterday. However, I am currently relying on version 0.5.1, which is published on npm (click on "Versions"). There is also a tag 0.5.0 in this repository, but no tag 0.5.1 and it seems that version was never merged to master.

Would it be possible to re-release as version 0.5.2?

deprecate some lib method

ability to deprecate some member expressions like forbidding map method from the lodash:

import l from 'lodash'
l.map()

Intended? Bug in import rule

Hi and thanks for the plugin.

We've faced a following issue:
Say we have a rule:

    "deprecate/import": [
      "error",
      { "name": "app/elements/deprecated", "use": "a new fancy element" }
    ]

But due to indexing, we've got many imports like this:

import {OkayElement1, OkayElement2 } from 'app/elements'

which also triggers an error.

This happens because of the line 69 in import.js:

filter(([importString]) => importString.includes(importPath))

which should be vice versa,

importPath.includes(importString))

I've forked the repo and fixed it for us, but I noticed that you have tests for that behaviour. E.g.:

        {
            code: 'import a from "Legacy"',
            parser: 'babel-eslint',
            options: [{ name: 'path/to/Legacy', use: 'New' }],
            errors: [{
                message: 'Module path/to/Legacy is deprecated. Use New instead.'
            }]
        },

you consider Legacy module to be deprecated, even though in the rule only specific module is stated, namely the one located in /path/to/.
From my perspective this is not right and causes issues like ours (partly paths overlapping) or conflicting module names.

If you agree I can provide a PR to fix the behaviour.

detect outdated imports

require('LegacyModule');
import some from 'LegacyModule';