This issue is for discussion of a new feature which would generate a configuration file based on the code styles and conventions already in use in a project.

Background: When new users are adding ESLint to an existing project, the first step is often to sift through the many ESLint rules to find the ones which are applicable to the project. While it might be easy to simply enable all of the Possible Errors and Best Practices rules, Stylistic Issues are much more subjective and need to be carefully examined, one-by-one.

What is being proposed here is to allow the code style already in use in the project to guide the creation of an .eslintrc configuration file.

The most likely way this can be accomplished is by repeatedly linting the code with rules set with different options, and comparing the number of linting errors that result from each option. Now that ea1871f has landed, it should only be necessary to parse the code once, thereby improving performance.

What still needs some thought and discussion, is the criteria for deciding which rules to enable in the generated config. Some ideas:

• Only enable rules which result in zero errors.
  • Advantage: Up-and-running right away, build does not break, nothing to fix.
  • Downside: If linting was not previously being done in the project, it's possible the code is mostly-consistent but has a few problems here and there which should be fixed.
• Set rules to warn if results < a threshold (configurable at runtime?)
  • Advantage: Can catch some problems in the code right away.
  • Downside: Requires some action on user's part if configurable. If not, a threshold has to be determined a priori
• When testing options like "always" vs. "never", if there are errors for both options, set to warn if one option has < X% of the errors when set to the other option. For example, if "always" gives 5 errors, and "never" gives 100, it's likely the style in the project is "always", and those 5 errors are just errors. However, if both options give 50 errors each, the project probably doesn't want to enforce that rule at all.
  • Advantage: Able to set rules with more complicated options, while allowing for some degree of imperfection in the project.
  • Disadvantage: A threshold would need to either be hard-coded or configurable at runtime.

A secondary goal of this is to be runnable against a project already using ESLint, to pick up new rules or make rules more strict if they are not erroring (see #3436).