fix(rule/variable-name): Use ruleArguments property

[hyperupcall]

PR Checklist

• Addresses an existing issue: fixes variable-name generates naming-convention #1225
• That issue was marked as status: accepting prs

Hello again! 😄

Overview

As mentioned in the linked issue, one problem was that the arguments for "@typescript-eslint/naming-convention" weren't being passed to the ESLint rule properly, so it just said "error". From my understanding, this caused problems since this would also include lint errors for function names, etc. too

It seems the fix was just a typo in the plugin. I also added a test specifically for ban-keywords, so it is a little more clear what is going on. This code generates the following ESLint file (for the same tslint.json file in the linked issue):

.eslintrc

Hi! This file was autogenerated by tslint-to-eslint-config.
https://github.com/typescript-eslint/tslint-to-eslint-config

It represents the closest reasonable ESLint configuration to this
project's original TSLint configuration.

We recommend eventually switching this configuration to extend from
the recommended rulesets in typescript-eslint.
https://github.com/typescript-eslint/tslint-to-eslint-config/blob/master/docs/FAQs.md

Happy linting! M-pM-^_M-^RM-^V
*/
module.exports = {
    "env": {
        "browser": true,
        "es6": true
    },
    "extends": [
        "prettier"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "project": "tsconfig.json",
        "sourceType": "module"
    },
    "plugins": [
        "@typescript-eslint"
    ],
    "root": true,
    "rules": {
        "@typescript-eslint/naming-convention": [
            "error",
            {
                "selector": "variable",
                "format": [
                    "camelCase",
                    "UPPER_CASE"
                ],
                "leadingUnderscore": "forbid",
                "trailingUnderscore": "forbid"
            }
        ],
        "id-denylist": [
            "error",
            "any",
            "Number",
            "number",
            "String",
            "string",
            "Boolean",
            "boolean",
            "Undefined",
            "undefined"
        ],
        "id-match": "error",
        "no-underscore-dangle": "error"
    }
};

Also it was stated in the linked issue that the best thing would possibly be "only outputing the id-denylist" rule - this doesn't address that part specifically, but does fix the bug within the rule.

To make sure this issue doesn't exist for other plugins, maybe it might be a good idea to validate whatever a plugin returns against some schema, at least in testing? That way, a plugin won't accidentally set rules instead of ruleArguments without some alarms going off.

[JoshuaKGoldberg]

maybe it might be a good idea to validate whatever a plugin returns against some schema, at least in testing? That way, a plugin won't accidentally set rules instead of ruleArguments without some alarms going off.

Agreed, that'd be great. If you have an idea for how you'd like to do it, I'd love an issue!

[JoshuaKGoldberg]

Seems reasonable, thanks!