How to Fix ESLint import/no-unresolved with TypeScript Imports

By the end of this page, you will understand why ESLint can parse TypeScript but still fail to resolve TypeScript imports, and how to fix that by configuring the correct import resolver. You will also learn the difference between parsing, linting, and module resolution, plus common mistakes that cause import/no-unresolved errors in TypeScript projects.

ESLint and TypeScript solve different problems.

• TypeScript checks types and understands .ts files.
• ESLint checks code style and code-quality rules.
• The rule import/no-unresolved comes from eslint-plugin-import, and it needs its own way to find imported files.

This is the key idea: setting the TypeScript parser does not automatically teach ESLint how to resolve TypeScript imports.

When you write:

import app from './app';

TypeScript knows that ./app may refer to ./app.ts. But the import/no-unresolved rule may still use Node-style resolution that mainly expects JavaScript files unless you configure a TypeScript-aware resolver.

That is why the error disappears after compilation: once app.js exists, the default resolver can find it.

To make ESLint work properly with TypeScript source files, you usually need:

1. @typescript-eslint/parser to parse TypeScript syntax.
2. eslint-plugin-import for import rules.
3. eslint-import-resolver-typescript so import rules can resolve and files.

Think of ESLint as a building inspector.

• The parser tells the inspector how to read the blueprint.
• The rules tell the inspector what problems to look for.
• The resolver tells the inspector where rooms and doors actually are.

In this case:

• @typescript-eslint/parser helps ESLint read TypeScript.
• import/no-unresolved checks whether an import path points to a real module.
• eslint-import-resolver-typescript helps ESLint find .ts files.

If you only give ESLint the parser, it can read the file, but it may still not know where ./app points unless you also give it the right resolver.

The usual fix is to install and configure the TypeScript import resolver.

Install the needed packages

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-import eslint-import-resolver-typescript

ESLint configuration

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint", "import"],
  "parserOptions": {
    "project": "./tsconfig.json",
    "sourceType": "module"
  },
  "settings": {
    "import/resolver": {
      "typescript": {
        "project": "./tsconfig.json"
      
    
  
   
     
  

Consider this file structure:

src/
  app.ts
  app.spec.ts

And this code in app.spec.ts:

import app from './app';

What happens without the TypeScript resolver

1. ESLint opens app.spec.ts.
2. @typescript-eslint/parser successfully parses the TypeScript syntax.
3. The rule import/no-unresolved checks ./app.
4. The default import resolver looks for files using its normal resolution rules.
5. It may not treat ./app.ts as a valid target.
6. ESLint reports:

Unable to resolve path to module './app'

What happens after compiling

If app.js is generated:

1. ESLint checks ./app again.
2. The resolver now finds ./app.js.
3. The warning disappears.

What happens with

This configuration is useful in many real projects:

Backend APIs

A Node.js API written in TypeScript often has imports like:

import server from './server';
import routes from './routes';

You want linting to work before build output exists.

React and frontend apps

React projects often import components without extensions:

import Button from './Button';
import useAuth from './useAuth';

These may point to .tsx or .ts files.

Test files

Test files commonly import source modules directly:

import app from './app';

Linting should work even when tests run against source files rather than compiled files.

Path aliases

Many TypeScript projects use aliases such as:

In real codebases, developers usually combine TypeScript import resolution with a few common patterns.

1. Lint source code, not build output

Teams usually lint .ts and .tsx files directly and ignore generated dist/ or build/ folders.

{
  "ignorePatterns": ["dist", "build"]
}

2. Use extensionless imports consistently

Most TypeScript projects prefer:

import app from './app';

instead of:

import app from './app.ts';

This keeps imports cleaner and works better across build tools.

3. Align ESLint with tsconfig.json

If your TypeScript config defines base paths or aliases, the resolver should read the same so both tools agree.

Here are common reasons this error continues even after adding TypeScript support.

Mistake 1: Only setting the parser

Broken idea:

{
  "parser": "@typescript-eslint/parser"
}

Why it fails:

• This only helps ESLint parse TypeScript syntax.
• It does not configure import resolution.

Fix:

• Install and configure eslint-import-resolver-typescript.

Mistake 2: Forgetting eslint-plugin-import

Broken config:

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

Why it fails:

• The rule import/no-unresolved belongs to eslint-plugin-import.

Fix:

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint", "import"],
  "parserOptions": {
    "project": "./tsconfig.json",
    "sourceType": "module"
  },
  "settings": {
    "import/resolver": {
      "typescript": {
        "project": "./tsconfig.json"
      }
    }
  },
  "rules": {
    "import/no-unresolved": "error"
  }

Why does ESLint fail even though TypeScript can find the file?

Because TypeScript and ESLint use different systems. TypeScript understands .ts files, but ESLint's import rule needs a resolver configured separately.

Is @typescript-eslint/parser enough to fix import/no-unresolved?

No. It only parses TypeScript syntax. You also need a TypeScript-aware import resolver.

Which package usually fixes this problem?

eslint-import-resolver-typescript is the usual fix when using eslint-plugin-import with TypeScript.

Should I import ./app.ts explicitly?

Usually no. In most TypeScript projects, extensionless imports like ./app are preferred.

Do I still need eslint-plugin-import if I use TypeScript?

If you want rules like import/no-unresolved, yes. That rule comes from eslint-plugin-import.

Can this also fix path aliases from tsconfig.json?

Yes, in many cases. The TypeScript resolver can read path mappings from your tsconfig.json.

• TypeScript compiler (tsc) — Related because it handles type checking and native TypeScript module resolution.
• ESLint parser — Related because parsing TypeScript syntax is separate from resolving imports.
• eslint-plugin-import — Related because it provides the import/no-unresolved rule.
• Module resolution — Related because this error is fundamentally about how tools find imported files.
• Path aliases in TypeScript — Related because aliases often require resolver configuration too.
• CommonJS vs ES Modules — Related because module systems affect import behavior and tool configuration.
• TSConfig — Related because resolver settings often depend on the correct tsconfig.json.
• JavaScript build output — Related because generated .js files can hide resolver misconfiguration during linting.