Documenting configuration hierarchy for CLIEngine options and 'useEslintrc: true'

Hi! Many thanks for a great tool 😃

I was trying to work out from the docs, which options take precedence in the following example:

// Some tool
var CLIEngine = require("eslint").CLIEngine;

var cli = new CLIEngine({
    // ...
    useEslintrc: true,
    rules: {
        semi: "error"
    }
});

// .eslintrc
{
    "rules": {
        "semi": "off"
    }
}

The CLIEngine docs just say:

useEslintrc - Set to false to disable use of .eslintrc files (default: true). Corresponds to --no-eslintrc.

And the docs on configuration hierarchy/precedence don’t mention CLIEngine at all:

The complete configuration hierarchy, from highest precedence to lowest precedence, is as follows:

1. Inline configuration
   1. /*eslint-disable*/ and /*eslint-enable*/
   2. /*global*/
   3. /*eslint*/
   4. /*eslint-env*/
2. Command line options:
   1. --global
   2. --rule
   3. --env
   4. -c, --config
3. Project-level configuration:
   1. .eslintrc.* or package.json file in same directory as linted file
   2. Continue searching for .eslintrc and package.json files in ancestor directories (parent has highest precedence, then grandparent, etc.), up to and including the root directory or until a config with "root": true is found.
   3. In the absence of any configuration from (1) thru (3), fall back to a personal default configuration in ~/.eslintrc.

From experimentation, I’ve found that the options passed to CLIEngine take priority over the ones in .eslintrc, however I think it would be good to document this.

I’m happy to open a PR to do so, but it would be useful to know whether I should do so on the configuration page, the API page, or both?

Many thanks!

[PiIsFour]

Hi, I’m new to this. But would like to give it a try, if that’s ok with you all.

[platinumazure]

@PiIsFour The change looks good to me. Don’t worry, our Travis Continuous Integration service will check for issues when you create the pull request.

I think npm run docs has been broken for some time. I don’t use it at all. We have a separate script which will copy the documentation from ESLint to eslint.github.io as part of our release.