Expose the rules list

The version of ESLint you are using. 3.4.0

The problem you want to solve. Since ESLint adds new rules from time to time and I want to make sure I make a decision about every core rule if I want to enable it or not, I’ve been reading the lib/rules/ contents and fail if any of the rule names is not present in the config. This turned out to be a popular feature so it got extracted into a separate package and then into a more general one. All of them apply the same hack of reading the lib/rules/ contents.

It would be good to have it available in the API and not require hacking into ESLint in such a way.

Your take on the correct solution to problem. I want to have a list of all rule names available via the public API. Perhaps via something like:

const rules= require('eslint').getRulesList();

(not sure if that’s the best place but it doesn’t fit for me to any of the current sub-APIs at http://eslint.org/docs/developer-guide/nodejs-api)

I’d expect the rules to be an array of rule definitions where rule definition is more or less what’s in the meta object exported by the rule (+ its name), e.g.:

{
    name: 'comma-dangle',

    docs: {
        description: "require or disallow trailing commas",
        category: "Stylistic Issues",
        recommended: false
    },

    fixable: "code",

    schema: [
        {
            enum: ["always", "always-multiline", "only-multiline", "never"]
        }
    ]
},

Returning the whole object instead of just rule names would allow to do more analysis for the API, e.g. it’d allow to not require specifying deprecated rules: https://github.com/sarbbottam/eslint-find-rules/issues/172

If you’re afraid the whole meta objects is too much information, at least the following would help a lot:

[
    {
        name: 'comma-dangle',
        deprecated: false,
    },
    {
        name: 'no-native-reassign',
        deprecated: true,
    },
]

[mgol]

@vitorbal Yes, that looks good! Somehow I haven’t found this one when I was searching for similar issues. 😄

Should we close this one as a duplicate then?

[jfmengels]

Sounds like it to me, thanks @vitorbal