5 Reasons `no-unsafe-call` Fails in Monorepos (2025 Fix)

// .eslintrc.js
module.exports = {
  // ... other configs
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: [
      './tsconfig.json',
      'packages/*/tsconfig.json',
      'apps/*/tsconfig.json',
    ],
    tsconfigRootDir: __dirname,
  },
  // ... rules
};

If you use pnpm, you can use the overrides feature to enforce this strictly:

// root package.json
{
  "pnpm": {
    "overrides": {
      "typescript": "^5.4.0"
    }
  }
}

For Yarn or npm, you can use `resolutions`. This ensures every package in your workspace uses the exact same TypeScript compiler, eliminating declaration file conflicts.

3. An Incomplete `tsconfig` for Linting

Many projects use a dedicated tsconfig.eslint.json file to avoid linting build artifacts or test files. But a misconfigured file can easily starve the linter of necessary context.

The Problem: Missing Files

Your primary tsconfig.json might have a tight "include" array for optimal build performance. Your `tsconfig.eslint.json` needs to be more expansive. If it doesn't include global type definition files (`.d.ts`), configuration files, or other relevant sources, ESLint won't have the full picture. When it encounters an import it can't trace back to an included file, that import becomes any.

The Fix: Extend and Include Everything

Create a robust tsconfig.eslint.json in your project root that extends your base config and explicitly includes all files the linter should be aware of.

// tsconfig.eslint.json
{
  "extends": "./tsconfig.json", // Start with the base config
  "include": [
    "src/**/*.ts",
    "apps/**/*.ts",
    "packages/**/*.ts",
    "test/**/*.ts",
    "*.js", // Include root config files
    "*.ts"
  ],
  "exclude": [
    "node_modules",
    "dist"
  ]
}

Then, update your .eslintrc.js to point its project option to this single, comprehensive file. This is an alternative to the glob pattern shown in the first point and can be simpler for some setups.

4. Module Resolution Madness

Monorepos use symlinks to connect internal packages. For example, apps/webapp/node_modules/@my-company/ui is often a symbolic link to packages/ui. This can confuse tools that don't use TypeScript's own module resolution logic.

The Problem: ESLint Gets Lost in Symlinks

If your ESLint setup isn’t configured to use TypeScript's resolver, it might try to resolve modules using a more basic Node.js-style lookup. When it hits a symlink, it can get confused about the file's real location and fail to find the corresponding .d.ts or source files. The result? The module is typed as any.

The Fix: Trust TypeScript's Resolver

The good news is that if you've correctly set parserOptions.project as shown in our first point, @typescript-eslint/parser will automatically use TypeScript's own, superior module resolution logic. This is the intended and most robust way to configure the plugin. You generally don't need extra resolver plugins like `eslint-import-resolver-typescript` anymore, as long as your `tsconfig.json` files are correctly referenced.

5. Aggressive Caching Gone Wrong

Modern monorepo tools like Turborepo and Nx are incredibly fast because they cache everything, including build artifacts (like .d.ts files) and task results (like lint reports).

The Problem: Linting Against Stale Types

Here’s a common scenario: You change a function signature in your ui package, but your monorepo tool's cache invalidation isn't configured perfectly. You run the linter on your webapp. The tool sees that `webapp`'s source files haven't changed and uses a cached lint result. Alternatively, it might re-lint `webapp` but run it against a stale, cached version of the ui package's declaration files. In either case, the linter is working with outdated information, leading to incorrect no-unsafe-call errors (or a lack thereof).

The Fix: Define Correct Cache Dependencies

This is less about ESLint config and more about your monorepo tool config. Ensure your linting task depends on the build artifacts of its internal dependencies. In Turborepo, this means setting up your `turbo.json` pipeline correctly.

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "lint": {
      // This is the key!
      // Linting depends on the build artifacts of its workspace dependencies.
      "dependsOn": ["^build"]
    }
  }
}

This tells Turborepo, "Before you lint a package, make sure all of its dependencies have been successfully built." This ensures your linter is always running against the latest type definitions.

The Holistic 2025 Fix: A Unified Configuration

The real fix isn't just one of these things; it's a combination of all of them. A modern, robust, type-aware linting setup in a monorepo for 2025 looks like this:

1. Single Source of Truth: Use your root package.json to enforce a single version of TypeScript and @typescript-eslint/* packages across all workspaces.
2. Project-Aware ESLint: Your root .eslintrc.js is configured with parserOptions.project using globs to find every tsconfig.json in your project.
3. Smart Task Orchestration: Your monorepo tool (Turborepo, Nx) is configured so that `lint` tasks explicitly depend on the `build` tasks of their dependencies.
4. Clean State: When in doubt, run a full clean and rebuild. (e.g., turbo clean && turbo build). If that fixes the problem, it’s a strong sign your cache dependency graph is wrong.

Here's a final look at the cornerstone of the fix, your root .eslintrc.js:

// .eslintrc.js in monorepo root

module.exports = {
  root: true, // Important!
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    // This enables type-aware rules
    'plugin:@typescript-eslint/recommended-requiring-type-checking',
  ],
  parserOptions: {
    // The magic for monorepos
    project: ['./tsconfig.json', './packages/*/tsconfig.json', './apps/*/tsconfig.json'],
    tsconfigRootDir: __dirname,
  },
  rules: {
    // Now this rule will work reliably!
    '@typescript-eslint/no-unsafe-call': 'error',
    // ... and other unsafe rules
    '@typescript-eslint/no-unsafe-member-access': 'error',
    '@typescript-eslint/no-unsafe-assignment': 'error',
  },
  ignorePatterns: ['node_modules', 'dist', 'build', '.turbo'],
};

Conclusion

Seeing no-unsafe-call errors on seemingly safe code in a monorepo is a classic rite of passage. But it's not a bug in ESLint; it's a signpost pointing to a misconfiguration in your complex development environment. By ensuring consistent TypeScript versions, correctly configuring project references for ESLint, and defining a logical build pipeline for your monorepo tool, you can eliminate these phantom errors for good.

Get your setup right, and you'll unlock the true power of type-aware linting: catching real bugs before they hit production, backed by the scalable architecture of a monorepo.