Create an --update command for rules changes

[IanVS]

Once #2382 lands, it will be easier to add ESLint to a project. Could something similar be done for users updating from one version to another? As mentioned in #2203 (comment), the process is not always the most straightforward, mostly because of rules and options being added/changed. It would be great if this process could be smoothed out.

I propose that an eslint --update command could be added which would use inquirer similarly to the --init command to upgrade ESLint to the latest version and let users know what rules have been added and then ask them whether they would like to enable them (in the .eslintrc in current directory, perhaps?). Additionally, once #2179 lands, new options in existing rules could also be presented to the user.

The final result could look something like:

$ ESLint --update

[?] Upgrade from ESLint 0.18.0 to 0.20.0: (Y/n) y

# npm update eslint

[?] 3 New rules available.  Examine: (Y/n) y

[?] "no-continue" [0.19.0] disallow use of the continue statement (off by default). Turn on: (y/N) n
[?] "operator-linebreak" [0.19.0] enforce operators to be placed before or after line breaks (off by default) Turn on: (y/N) n
[?] "object-shorthand" [0.20.0] require method and property shorthand syntax for object literals (off by default) Turn on: (y/N) y
[?] "object-shorthand" options:
    1) "always" (default) #default answer
    2) "methods"
    3) "properties"
    4) "never"
    Answer: 2

[?] 2 existing rules have had option changes.  Examine: (Y/n) y

[?] "quotes" options:
    1) "double" (current)  #default answer
    2) "single"
    3) "backtick" (new)
    Answer: 3

.
.
.

ESLint successfully upgraded from 0.18.0 to 0.20.0!

I've no idea if this is really possible or wise, but something like this sure would be nice to have (from a user's perspective)!

[gcochard]

This could get very complicated when you have multiple repositories each with different eslint configs. It would be nice to be made aware of new rules somehow, though. Maybe the --init option can write a version stamp (possibly as a comment) in the eslintrc, and then eslint could output a warning when it is run with an older version of the config file.

$ eslint -v
v0.18.0
$ eslint .
some/file.js
  62:12  warning  Unexpected todo comment  no-warning-comments

✖ 1 problem
$ echo $?
0
$ npm -g install eslint
.
.
.
$ eslint -v
v0.20.0
$ eslint .
some/file.js
  62:12  warning  Unexpected todo comment  no-warning-comments

general warning
  ESLint version mismatch. Current version 0.20.0 while config version 0.18.0

✖ 2 problems
$ echo $?
0

[nzakas]

I fear this is one of those things that sounds great in theory and explodes in exponential complexity in practice. We'd basically be bound to create mapping of each incremental change for every version going forward.

If we instead just don't remove rules in the future (which is the plan), I think it eliminates some of the angst.

Maybe we can start by having you list out various individual pain points in upgrading?

[ilyavolodin]

Adding version to .eslintrc has been discussed before here: #452

[IanVS]

I just wanted to be lazy and not read the excellent changelogs / blog posts detailing the changes between versions. Honestly those are more than sufficient, so closing this issue.