Autocreate configuration from existing project code

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 https://github.com/eslint/eslint/commit/ea1871f19bfd54f36c5d080e9052dedd32ac1d7d 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 https://github.com/eslint/eslint/issues/3436).

[ilyavolodin]

Just as a reference there’s a tool out there that does some of this: https://github.com/willklein/dryer

[IanVS]

Thanks, those are great ideas. Some other pieces I haven’t had time to implement so far:

1. Allow ES7+ features with option for using babel-eslint. For now, such code is not autoconfigurable (parser is always set to espree).
2. Enable autoconfig of rules with schemas containing nested objects and oneOf or anyOf schemas.
3. Add a mode for projects which are already using ESLint to check if they can easily enable more rules than they currently have in their config (either newly added rules, or the code has been refactored, etc.).

Metadata will be very useful for a number of reasons, as you’ve mentioned already. Right now the rules are being sorted alphabetically, which seemed to be the only logical order when we’re talking about 200 rules, since it makes them easier to find if you’re just scanning through. I thought about grouping on/off rules, but I think that’s less desirable in the long run, since configs are not static, and personally I don’t like to reorder my rules when I turn them on and off. But, maybe we can play with groupings that make sense.