Missing file extension "ts" for [...] / passing through enhanced-resolve's options.

[Patryk-B]

I am trying to supply eslint-import-resolver-typescript with custom extensionAlias option. Is this the correct way:

{
  "plugins": ["import"],
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [".ts", ".tsx"]
    },
    "import/resolver": {
      "typescript": {
        "alwaysTryTypes": true,
        "project": "./tsconfig.json",
        
        "extensionAlias": {

          ".js": [ ".ts", ".d.ts", ".js" ],
          ".cjs": [ ".cts", ".d.cts", ".cjs" ],
          ".mjs": [ ".mts", ".d.mts", ".mjs" ],

          ".ts": [ ".js", ".d.ts", ".ts" ],
          ".cts": [ ".cjs", ".d.cts", ".cts" ],
          ".mts": [ ".mjs", ".d.mts", ".mts" ],
        }
      }
    }
  },
  "rules": {
    "import/extensions": [
      "error"
      "always",
      {
	    "ignorePackages": false
      }
    ]
  }
}

bc it doesn't seem to work...

What am i trying to achieve?

I am trying to fix Missing file extension "ts" for [...] linting error from import/extensions rule by trying to "teach" eslint-import-resolver-typescript resolver to treat ".js" as aliases for ".ts" extension.

[JounQin]

Seems related to import-js/eslint-plugin-import#2813

[phryneas]

@JounQin that PR needs your feedback - could you jump in over in import-js/eslint-plugin-import#2813 (review) please? :)

[Patryk-B]

Sorry to bother you @JounQin & @phryneas, obviously I am completely green. I don't know how both typescript resolver and import/extensions rule cooperate to lint the code. I am not trying to question anything. I am simply curious.

Why is it necessary to specialize the import/extensions rule for this single edge case?

Shouldn't the import/extensions rule ask the typescript resolver if path “@src/foo/foo.js” is valid (aka. resolves to “<root>/src/foo/foo.ts”) instead of validating the path/extension?

Why can't the typescript resolver do that job?

AFAIK typescript resolver heavily depends on the webpack's enhanced-resolve, why passing through relevant configuration (the extensionAlias option) doesn't produce the correct result?

[phryneas]

@Patryk-B in short, in the past:

• import/extensions looks at source code, sees import foo from "file"
• import/extensions asks eslint-import-resolver-typescript "hey, what's the real path for "file"?
• eslint-import-resolver-typescript responds with file.ts
• import/extensions complains because the user is not really importing the file name with the right extension that it has on disk

Now, with importing a .js file with a .ts extension on disk:

• import/extensions looks at source code, sees import foo from "file.js"
• import/extensions asks eslint-import-resolver-typescript "hey, what's the real path for "file.js"?
• eslint-import-resolver-typescript responds with file.ts
• import/extensions complains because the user is not really importing the file name with the right extension that it has on disk

=> eslint-import-resolver-typescript is aware that importing .js is actually correct for a .ts file on disk. import/extensions doesn't know that yet.

[Patryk-B]

@phryneas, understood. Thank you very much for your in-depth explanation. 🙇🙇🙇🙇

[fernandopasik]

Thank you @phryneas for the detailed explanation. Would you know a way to avoid the error from import/extensions without disabling the rule?

[phryneas]

@fernandopasik you've seen my other comment?