requested plugin's rules not successfully being added to the linting config object

[cdaringe]

What version of standard?

12.0.1

What operating system, Node.js, and npm version?

node 11, osx, npm 6.x

What did you expect to happen?

by providing:

"standard": {
    ...
    "parser": "@typescript-eslint/parser",
    "plugins": [
      "@typescript-eslint"
    ]

i expect the eslint config to have many @typescript-eslint/<rule-name> in the config.rules set, however, all are missing when eslint actually tries to lint files.

all other rules from the other plugins, e.g. ['node', 'import', ..., 'standard'] show up. i'm setting breakpoints eslint's cli-engine.js, and seeing the completed config (after configHelper.plugins.loadAll(config.plugins);), but the @typescript-eslint/<rule-name> rules are all missing :(

What actually happened?

no @typescript-eslint/<rule-name> rules are present

discussion

i see that eslint is calling load on the plugin, and i see defineRule being called with @typescript-eslint/<rule-name> rules. however, the final config is missing these rules.

in a barebones eslint project, the following eslintrc does add these rules to the eslint config:

{
  "extends": ["plugin:@typescript-eslint/recommended"],
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"]
}

and the resultant config looks akin to:

{
  "globals": {},
  "env": {},
  "rules": {
    "@typescript-eslint/adjacent-overload-signatures": "error",
    ...
    "@typescript-eslint/no-triple-slash-reference": "error",
    "no-unused-vars": "off",
    "@typescript-eslint/type-annotation-spacing": "error"
  },
  "parserOptions": {
    "sourceType": "module"
  },
  "parser": "/Users/c0d01a5/node/eslint-ts-no-unused-issue/node_modules/@typescript-eslint/parser/dist/parser.js",
  "plugins": [
    "@typescript-eslint"
  ],
  "extends": [
    "plugin:@typescript-eslint/recommended"
  ]
}

the eslint code is highly stateful, and i'm not certain how a Linter's rulesMap is supposed to fold back into the config object that's passed to the linting context. either way, standard does not seem to be loading this rule as promised, wherein off-the-shelf does load the plugin (5.14.0***) no problem.

would love to see if anyone could successfully get standard to load that plugin full well!

[cdaringe]

it would be helpful if any of the standard developers who are well versed in eslint (even if you're not a typescript user), could pitch in and help diagnose why the `"@typescript-eslint" plugin's rules are discarded. I'd be happy to even pair on it some evening (I'm in PST)

[LinusU]

I don't think standard picks up any new rules at all, if you want to configure your rules you'll probably have to use standardx.

Maybe eslint-config-standard-with-typescript would suit your needs btw?

[cdaringe]

@LinusU, the docs claim first class compat with typescript, thus, this should work.

[despian]

I agree the docs state that there is ts support but the fact is it's just broken.

#1007 suggests merging the rules from eslint-config-standard-with-typescript into standard. I think this sounds like a great idea.

[feross]

Adding a plugin does not automatically enable rules. You need to add rules to the eslint config in order for them to be enabled. In the case of standard, since we don't bundle the typescript eslint plugin in standard, we cannot add any typescript rules or else the whole package would break for users without the typescript plugin.

We'll likely solve this properly in a future version of standard. In the meantime, I recommend following the instructions in this comment to switch to standardx which allows you to change rules to make things work better for typescript. See the comment here: https://github.com/standard/standard/issues/1283#issuecomment-520266170

[feross]

One thing I don't understand is why adding a plugin automatically enables rules when used with eslint directly but not when used with standard.

[cdaringe]

thanks @feross. i did indeed switch to standardx when using/detecting TS

[feross]

Can someone test this out in standard 16? We're using ESLint a bit more directly (with fewer layers in between) so there's a (slim) chance that this bug has fixed itself.