TS type check is checking my lib incorrectly when added it to an App project.

[joel-daros]

Current Behavior

I’m have a NX monorepo with 1 app (my-app) and 1 lib (products).

The products lib has the noUncheckedIndexedAccess tsconfig property set to false in its libs/products/tsconfig.json file.
The my-app app has the noUncheckedIndexedAccess tsconfig property set to true in its apps/my-app/tsconfig.json file.

In the products lib I have this component being exported:

export function Products() {
  const myArr = [1, 2, 3];
  const index: number = 0;
  const value = myArr[index];
  return (
    <div>
      {/* I don't need the optional operator because this project has noUncheckedIndexedAccess = false */}
      <h1>{value.toString()}</h1>
    </div>
  );
}

And I importing it to my-app:

import { Products } from '@nx-test/products';

export function App() {
  return (
    <div>
      <Products />
    </div>
  );
}

When I run tsc command to type check my-app it’s throwing an error:

pnpm exec tsc --project ./apps/my-app/tsconfig.app.json --noemit
libs/products/src/lib/products.tsx:11:12 - error TS18048: 'value' is possibly 'undefined'.

11       <h1>{value.toString()}</h1>
              ~~~~~


Found 1 error in libs/products/src/lib/products.tsx:11

1. Why TS is type checking a file (libs/products/src/lib/products.tsx) that’s outside my-app?
2. Why is it not respecting the products lib tsconfig.json file?

Yes, I have the "skipLibCheck": true in my tsconfig.base.json file.

Expected Behavior

Type checking should be executed only for the files of my-app and not for its dependency libraries.

GitHub Repo

https://github.com/joel-daros/nx-tsconfig-issue

Steps to Reproduce

1. Clone the project
2. pnpm install
3. Run the tsc command for type checking: pnpm exec tsc --project ./apps/my-app/tsconfig.app.json --noemit

Nx Report

Report complete - copy this into the issue template

Node   : 20.11.1
OS     : darwin-x64
pnpm   : 9.1.0

nx (global)        : 18.1.2
nx                 : 18.3.4
@nx/js             : 18.3.4
@nx/eslint         : 18.3.4
@nx/workspace      : 18.3.4
@nx/eslint-plugin  : 18.3.4
@nx/react          : 18.3.4
@nx/vite           : 18.3.4
@nx/web            : 18.3.4
typescript         : 5.4.5
---------------------------------------
Registered Plugins:
@nx/vite/plugin
@nx/eslint/plugin

Failure Logs

libs/products/src/lib/products.tsx:11:12 - error TS18048: 'value' is possibly 'undefined'.

11       <h1>{value.toString()}</h1>
              ~~~~~


Found 1 error in libs/products/src/lib/products.tsx:11

Package Manager Version

pnpm 9.1.0

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[leosvelperez]

Thanks for reporting this!

This is the expected behavior for TypeScript with your setup. The my-app project depends on the source code of products and when you run tsc -p apps/my-app/tsconfig.app.json, the TS compiler creates a ts.Program for that configuration file. It doesn't use any other configuration file unless is extended or referenced. In this case, it extends the tsconfig.base.json and it doesn't reference any other configuration file. Therefore, every file included in the ts.Program will be processed with the apps/my-app/tsconfig.app.json configuration (plus the merged config from the extended tsconfig.base.json). The library source code is part of the ts.Program because:

• the ts.Program rootDir is the root of the workspace (specified in tsconfig.base.json)
• it's imported from the application using the path mapping @nx-test/products which is configured to resolve libs/products/src/index.ts (a file inside the rootDir)

So, that's why tsc is processing libs/products/src/lib/products.tsx when running for the apps/my-app/tsconfig.app.json project. Please note that, as mentioned, this is expected TypeScript behavior based on the configuration you shared in the reproduction.

TypeScript has a way to effectively split source code into multiple "projects", which is using project references and tsc -b. By configuring your whole TypeScript setup like a solution where each tsconfig.json file is considered and independent project, tsc can build them independently. An issue with it is that tsc -b is a "build"-only command. You'll always need to at least emit the declaration files.