[no-duplicate-imports] Detect duplicates when paths are different

[OliverJAsh]

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

Full reduced test case: https://github.com/OliverJAsh/no-duplicate-imports-test.git

.eslintrc.js:

const config = {
    parser: "@typescript-eslint/parser",
    parserOptions: {
        project: ["./tsconfig.json"],
    },
    plugins: ["@typescript-eslint"],
    rules: {
        "@typescript-eslint/no-duplicate-imports": 2
    },
};

module.exports = config;

tsconfig.json:

{
    "compilerOptions": {
        "baseUrl": "./app"
    },
}

app/helpers/foo.ts:

export const foo = 1;
export const bar = 1;

app/main.ts:

import { foo } from "helpers/foo";
// This should error but it doesn't ❌
import { bar } from "./helpers/foo";

foo;
bar;

Expected Result

@typescript-eslint/no-duplicate-imports should produce an error.

Actual Result

No error

Additional Info

I understand that the base rule no-duplicate-imports wouldn't be able to detect this duplicate because it doesn't have enough information about the dependency graph and the baseUrl to detect whether the duplicate, however I think @typescript-eslint/no-duplicate-imports does have the information necessary to detect this?

Versions

package.json:

{
  "dependencies": {
    "@typescript-eslint/eslint-plugin": "^5.4.0",
    "@typescript-eslint/parser": "^5.4.0",
    "eslint": "^8.3.0",
    "typescript": "^4.5.2"
  }
}

[bradzacher]

however I think @typescript-eslint/no-duplicate-imports does have the information necessary to detect this?

The extension rule just adds support for type-only imports. It does not use type information, meaning it cannot see your project config or interrogate / understand the mappings.

I'll be honest when I say that our version is bad - it really just exists to patch the gap so the rule so users don't get false positives.

A much, much better version of the rule is import/no-duplicates which can handle this by way of its "import resolvers".

We should probably update the docs to point at that rule and direct users away from our version.