Fix `no-unsafe-call` on Generics in Monorepos: 2025

@typescript-eslint/no-unsafe-call: Unsafe call of an `any` typed value.

my-monorepo/
├── packages/
│   ├── utils/
│   │   ├── src/create-processor.ts
│   │   └── tsconfig.json
│   └── app/
│       ├── src/index.ts
│       └── tsconfig.json
├── .eslintrc.js
└── package.json

// packages/utils/src/create-processor.ts

export function createProcessor<T>(processorFn: (data: T) => void) {
  // Returns a function that will execute the provided processor
  return (data: T) => {
    console.log("Processing data...");
    processorFn(data);
  };
}

// packages/app/src/index.ts

import { createProcessor } from "@my-org/utils";

interface User {
  id: string;
  name: string;
}

const processUser = createProcessor<User>((user) => {
  console.log(`Handling user: ${user.name}`);
});

const myUser: User = { id: "1", name: "Alice" };

// ESLint screams here!
processUser(myUser); // <-- Error: Unsafe call of an `any` typed value.

Step 1: Supercharge Your `tsconfig.json`

Your TypeScript configuration is the foundation. The key is to provide as much information as possible across package boundaries. The secret weapon here is declarationMap.

In your shared package's tsconfig (e.g., packages/utils/tsconfig.json), ensure these settings are enabled:

// packages/utils/tsconfig.json
{
  "compilerOptions": {
    // ... your other options like target, module, etc.

    // Crucial for monorepo setups. Enables incremental builds.
    "composite": true,

    // Generates the .d.ts files so other packages know your types.
    "declaration": true,

    // THE HERO! Creates source maps for your .d.ts files.
    // This allows tools like ESLint to trace a type back to its
    // original .ts source, preserving the full generic context.
    "declarationMap": true
  },
  "include": ["src"]
}

Your consuming package (packages/app/tsconfig.json) should then reference the utility package to create the dependency link:

// packages/app/tsconfig.json
{
  "compilerOptions": {
    // ... your app-specific options
    "composite": true
  },
  "references": [
    { "path": "../utils" } // This tells TypeScript about the relationship
  ]
}

Step 2: Master Your Monorepo Build Order

A correct configuration is useless if your packages are built in the wrong order. Your app package's linting process can only succeed if the utils package has already been compiled, generating the necessary .js, .d.ts, and .d.ts.map files.

Modern monorepo tools like Turborepo, Nx, or Lerna are designed for this. You define a dependency graph and they handle the rest. A typical Turborepo setup in turbo.json might look like this:

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      // This tells Turborepo that a package's `build` script
      // depends on the `build` script of its dependencies.
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "lint": {
      // The `lint` script should also depend on the build step
      // to ensure types are available before linting.
      "dependsOn": ["^build"]
    }
  }
}

This configuration ensures that running turbo lint will automatically build all dependencies first.

Step 3: Align Your ESLint Configuration

This is the step that trips up most developers. ESLint needs to be explicitly told where to find all the tsconfig.json files in your project so it can build a complete picture of your codebase's types.

In your root .eslintrc.js, configure the parserOptions.project property. This tells @typescript-eslint to load the full type information.

// .eslintrc.js

module.exports = {
  root: true,
  // ... other configs like extends, plugins
  parser: "@typescript-eslint/parser",
  parserOptions: {
    // THIS IS THE KEY!
    // Provide a glob pattern that finds all tsconfig files.
    project: ["./packages/*/tsconfig.json", "./tsconfig.json"],
    tsconfigRootDir: __dirname,
  },
  rules: {
    // ... your rules
    "@typescript-eslint/no-unsafe-call": "error",
  },
};

By pointing to all project files, you empower ESLint to understand the cross-package references and correctly resolve your generic types from njihov source, thanks to the declarationMap you enabled in Step 1.

Step 4: The Last Resort - A Well-Placed Type Guard

If you've followed all the steps above and are still facing issues (perhaps due to a very complex third-party library or a limitation in the tooling), you can use a type guard as a targeted escape hatch. This is a manual assertion that tells TypeScript, "Trust me, I know what this is."

Use this sparingly, as it overrides the very safety you're trying to achieve.

// packages/app/src/index.ts (with a type guard)

import { createProcessor } from "@my-org/utils";

// ... User interface, etc.

const processUser = createProcessor<User>((user) => {
  console.log(`Handling user: ${user.name}`);
});

// Type Guard function
function isFunction(value: unknown): value is (...args: any[]) => any {
  return typeof value === 'function';
}

const myUser: User = { id: "1", name: "Alice" };

if (isFunction(processUser)) {
  // Inside this block, TypeScript knows `processUser` is a function.
  processUser(myUser); // No more ESLint error!
}

Again, this is a workaround, not a fix. The first three steps solve the underlying configuration problem. Reserve this for true edge cases.

Your Troubleshooting Checklist

Next time you hit this error, run through this list:

• 1. Check `tsconfig.json`: Does your shared package have composite: true, declaration: true, and declarationMap: true?
• 2. Verify Build Pipeline: Are you sure your dependencies are being built before the dependent package is linted? Check your monorepo tool's configuration.
• 3. Inspect `.eslintrc.js`: Is parserOptions.project correctly pointing to all relevant tsconfig.json files in your monorepo?
• 4. Restart the TS Server: The classic "turn it off and on again." In VS Code, open the command palette (Cmd+Shift+P) and run TypeScript: Restart TS Server. This forces it to re-evaluate your newly configured project.

Conclusion: From Frustration to Fluent Typing

The no-unsafe-call error in a monorepo isn't a bug; it's a symptom of a misaligned toolchain. It’s a sign that the flow of type information between your packages has a broken link. By methodically checking your TypeScript configuration, build process, and ESLint settings, you can repair that link.

Once everything is correctly configured, you'll find that types flow seamlessly across your entire monorepo. Your generics will be understood, your calls will be safe, and you can get back to writing robust, maintainable, and wonderfully type-safe code.