Thank you for your contribution!

I don't think this is the correct way to do things.
Doing so will make it very hard for people to adjust the recommended config.

Consider the following case:

{
  "extends": ["plugin:@typescript-eslint/recommended"],
  "rules": {
    // disable recommended rule
    "@typescript-eslint/ban-types": "off"
  }
}

The user's disabling of the ban-types rule will do nothing, because the override within the recommended config takes precedence, because it is more specific.

This means that instead a user has to know that the recommended config uses overrides, and use overrides themselves:

{
  "extends": ["plugin:@typescript-eslint/recommended"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", ".*.ts", ".*.tsx"],
      "rules": {
        // disable recommended rule
        "@typescript-eslint/ban-types": "off"
      }
    }
  ]
}

This is obviously a sub-optimal experience, especially for those that have pure TS codebases.

I think that this is better fixed in user-land.
You can handle your mixed codebase within your config file, by only applying our recommended config to your \.ts(x)? files (as per #109 (comment), eslint6 now supports this)

{
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", ".*.ts", ".*.tsx"],
      "extends": ["plugin:@typescript-eslint/recommended"],
    }
  ]
}

Thanks for the quick response! Also, I didn't see the previous discussion until after I submitted he PR.

I think it is unexpected behavior that the recommended rules run on .js, including changing the parser and sourceType for .js files.

Your concern about how an end user has to override has been fixed in v6.

I propose I modify this PR to use overrides for eslint >= v6 and the use previous behavior for older versions. I think that would solve everyone's concerns and work as expected moving forward.

@bradzacher What are your thoughts about what I proposed? If this isn't wanted, no problem at all, please close as I've solved it already for myself...just wanted to help others.

I'm not sure if it's right?
But TBH my experience with recommended configs is limited.
It'd be worth getting comments from some of the eslint peeps

cc @typescript-eslint/eslint-team

I don't see any reason why somebody would want to disable typescript rules for js files. They might be not as useful, but they're still beneficial.

Hey there - sorry it's been so long.
I've had a think about this, and I think it's best if we don't do this, because it would affect many of our userbase.

As mentioned - the rules all work fine on JS code (there are only a v small list of exceptions, like explicit-function-return-type).
Additionally, there are many users that use these rules on things like markdown files, and vue files, which means they wouldn't be able to use the recommended sets.

None the less, thanks for the contribution!