fix: Fix mapping typescript rules that extend the original ESLint rule.

[connorshea]

This fixes #410.

I have tested all three of these cases and confirmed that this works correctly for all three cases, it also does not print an unsupported warning for eslint/dot-notation anymore:

import tseslint from "typescript-eslint";

export default tseslint.config({
  plugins: {
    "@typescript-eslint": tseslint.plugin,
  },
  rules: {
    "dot-notation": "off",
    "@typescript-eslint/dot-notation": "error",
  },
});

import tseslint from "typescript-eslint";

export default tseslint.config({
  plugins: {
    "@typescript-eslint": tseslint.plugin,
  },
  rules: {
    "@typescript-eslint/dot-notation": "error",
  },
});

export default [
  {
    rules: {
      "dot-notation": "error",
    },
  },
];

typescript/consistent-return also has this same situation, and so is also fixed.

Generated with Claude Code, tested and reviewed by me.

[Sysix]

Should this not be fixed by oxlint with the typescript alias mapping? https://github.com/oxc-project/oxc/blob/8b89309f5740aeba5d7ef9b1389d41f915239bbb/crates/oxc_linter/src/utils/mod.rs#L86-L129

[connorshea]

Should this not be fixed by oxlint with the typescript alias mapping? https://github.com/oxc-project/oxc/blob/8b89309f5740aeba5d7ef9b1389d41f915239bbb/crates/oxc_linter/src/utils/mod.rs#L86-L129

The problem is that - if we do it that way - we need to move the rule into the ESLint namespace to avoid this bug that occurs when we mark a rule as a typescript extension rule: oxc-project/oxc#19437

Currently, the oxc config evaluation logic breaks if you have an extension rule that is in the typescript namespace instead of the eslint namespace (so after adding dot-notation to the list of extended rules, eslint/dot_notation.rs would be fine, but if you have typescript/dot_notation.rs we have problems).

Though, arguably we should figure out the root cause and fix that bug in oxc so we can do this aliasing properly in oxc, but 🤷

[Sysix]

Oh, these rules require type-aware flag, this change everything 🤔
Let me think how to resolve this at best. I wish that Oxlint has some solution for this. :')

[connorshea]

Oh, these rules require type-aware flag, this change everything 🤔 Let me think how to resolve this at best. I wish that Oxlint has some solution for this. :')

Any ideas? :D This would be nice to have fixed since it's hard to figure out which of my overrides in my complex ESLint config use these rules

[Sysix]

Sorry, I thought about it last day but could not find a good solution. I think the only way is to split the rules like I want to do it with jest/vitest in this stack: oxc-project/oxc#18603

In the meantime I would accept this fix in the migration script :) could you resolve the conflicts?