add rule no-deprecated

[abhirathore2006]

Adding support no-deprecated rule to make migration to newer version easier

[ganimomer]

Hey, and thanks for contributing!
This rule could help a lot with migration once Lodash v5 comes out, but I think it's a bit too specific.
Since the plugin already contains a curated list of Lodash functions (or close enough that changing them is a feasible goal), I think a better rule would be something like no-deprecated, that reports for every method that doesn't exist in a specified version.
(e.g. your declared version in the plugin could be version 4, but you could set the rule to version 5)

[abhirathore2006]

@ganimomer thanks for advice, i will make appropriate changes

[abhirathore2006]

@ganimomer i updated the rule to no-deprecated

[ganimomer]

Great work!
I made some comments about the spec and implementation, which I think should be changed a bit.

[ganimomer]

In all other rules, we don't count severity as an argument.

[ganimomer]

You have a typo in deprecated.

[ganimomer]

I'm not sure why this is an array.
Whoever uses this rule probably wants to migrate to a specific version, so they can probably input their destination version, and the rule can figure out which deprecations to include by itself.
e.g. If a user uses v3 (which we can get by the version global config, usually supplied by using a config), and they want to upgrade to v5, they can just write 5 and the rule can figure out to include both 4 and 5 as deprecations.

[ganimomer]

The plugin already has a methodDataByVersion files. Maybe there's a way to introduce this data there, so all the information is in the same place?
Most of the information is already there - any method that exists in 3 and doesn't exist in 4 is deprecated.
This means we'd have to add a 5.js already, but assuming you can run the master version of Lodash in Node, you can probably use a script to generate a file for it automatically. You don't even need to add all the information yet (that's subject to change until v5 is released probably). You can just use empty object for each method.
This might not include the recommendation part, but it's neater, I think.

[jdalton]

rest/spread are built-in syntax (not functions)

[abhirathore2006]

@jdalton i will update it, i didn't miss any deperecation right ?

[jdalton]

I think it's a good start. It can always be added to as v5 develops.

[abhirathore2006]

@ganimomer i am thinking to add deprecations list in methodDataByVersion files .

{
 _deprecations:{
    key:"message"
  }
}

[ganimomer]

@abhirathore2006 Sounds good, but why the _?

[abhirathore2006]

@ganimomer to distinguish it from other properties, which are the names of actual functions