`typecheck` dependsOn `build` and this doubles the typechecking time

[fregante]

Current Behavior

nx typecheck my-lib will trigger both build and typecheck. This happens on a fresh workspace, I just run the 2 commands suggested by the docs

According to https://nx.dev/blog/nx-update-20-5#typescript-project-references-improvements, these tasks are redundant and I think it says typecheck should not have been inferred at all.

nx typecheck my-lib

> nx run @my-org/my-lib:build  [local cache]

> tsc --build tsconfig.lib.json


> nx run @my-org/my-lib:typecheck  [local cache]

> tsc --build --emitDeclarationOnly

Expected Behavior

No build step should be executed:

nx typecheck my-lib

> nx run @my-org/my-lib:typecheck  [local cache]

> tsc --build --emitDeclarationOnly

Steps to Reproduce

npx create-nx-workspace my-org --preset=ts
cd my-org
nx g @nx/js:lib libs/my-lib # choose tsc as the builder
nx typecheck my-lib

Nx Report

NX   Report complete - copy this into the issue template

Node           : 22.14.0
OS             : darwin-arm64
Native Target  : aarch64-macos
npm            : 10.9.2

nx             : 21.2.2
@nx/js         : 21.2.2
@nx/workspace  : 21.2.2
@nx/devkit     : 21.2.2
typescript     : 5.8.3
---------------------------------------
Registered Plugins:
@nx/js/typescript
---------------------------------------

[fregante]

Re "this causes bad data to be cached"

I can't prove this, but I regularly get into a state where my build steps fail due to bad/missing dist contents in certain libs. Here's how I fix it yesterday, I don't have any other explanation for it:

nx typecheck my-lib # fails
rm -rf libs/my-lib/dist
nx typecheck my-lib --excludeTaskDependencies --skip-nx-cache --parallel=1

[leosvelperez]

Thanks for reporting this!

At some point, we did stop inferring a typecheck task but that was incorrect. The typecheck task not only typechecks runtime code, but also any other code include by other tsconfig files referenced by the project tsconfig.json (e.g. test files included by tsconfig.spec.json). So, when we stopped inferring it, we lost the ability to typecheck those extra files not part of the build task.

You can see at #30549 a detailed explanation about why we made typecheck depend on build. With this setup, there's no duplicated type checking, because the typecheck task actually reuses the output of the build task.

I can't prove this, but I regularly get into a state where my build steps fail due to bad/missing dist contents in certain libs. Here's how I fix it yesterday, I don't have any other explanation for it:

nx typecheck my-lib # fails
rm -rf libs/my-lib/dist
nx typecheck my-lib --excludeTaskDependencies --skip-nx-cache --parallel=1

Could you provide a reproduction so we can troubleshoot this? It sounds like it only happens with certain libraries, so we'd need a proper reproduction to troubleshoot it.

[fregante]

You can see at #30549 a detailed explanation

I think those benchmarks are ignoring the substantial overhead introduced by Nx' dist caching/cleaning because it doesn't match my experience unfortunately.

I ran these commands on a clean repo (clear dist folders + nx reset + nx sync) and I get wildly different performance:

$ nx run-many -t typecheck --skip-nx-cache
 NX   Successfully ran target typecheck for 59 projects and 51 tasks they depend on (3m)

$ nx run-many -t typecheck --skip-nx-cache --excludeTaskDependencies
 NX   Successfully ran target typecheck for 59 projects (1m)

Here's a chunk of the output for both:

# typecheck
   ✔  nx run @pixiebrix/util-eslint-plugin:typecheck (709ms)
   ✔  nx run @pixiebrix/util-env:build (1s)
   ✔  nx run @pixiebrix/util-env:typecheck (98ms)
   ✔  nx run @pixiebrix/config-eslint:typecheck (694ms)
   ✔  nx run @pixiebrix/ui-icon-library:build (545ms)
   ✔  nx run @pixiebrix/util-types:build (2s)
   ✔  nx run @pixiebrix/ui-icon-library:typecheck (1s)
   ✔  nx run @pixiebrix/config-webpack:build (1s)
   ✔  nx run @pixiebrix/util-types:typecheck (1s)
   ✔  nx run @pixiebrix/util-telemetry:build (744ms)

# typecheck without build
   ✔  nx run @pixiebrix/util-eslint-plugin:typecheck (613ms)
   ✔  nx run @pixiebrix/util-env:typecheck (928ms)
   ✔  nx run @pixiebrix/config-eslint:typecheck (651ms)
   ✔  nx run @pixiebrix/config-webpack:typecheck (919ms)
   ✔  nx run @pixiebrix/ui-icon-library:typecheck (1s)
   ✔  nx run @pixiebrix/util-types:typecheck (2s)
   ✔  nx run @pixiebrix/util-json-schemas:typecheck (629ms)
   ✔  nx run @pixiebrix/util-telemetry:typecheck (786ms)

Here's an example tsconfig.lib.json:

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "emitDeclarationOnly": false,
    "outDir": "distribution",
    "rootDir": "src",
    "tsBuildInfoFile": "distribution/tsconfig.lib.tsbuildinfo",
    "types": [
      "node"
    ]
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    {
      "path": "../config-eslint"
    },
    {
      "path": "../util-env/tsconfig.lib.json"
    }
  ]
}

Could you provide a reproduction so we can troubleshoot this?

Unfortunately it's not very reproducible and the repo is private, I just know that it's been happening semi-regularly since we upgraded from 20.2 to the latest version.

[fregante]

the substantial overhead introduced by Nx

Side note: I had to stop using nx run-many -t typecheck on CI because it reached 18 minutes (or 8 with --excludeTaskDependencies) and use the raw, uncached tsc --build instead (1m30s)

[leosvelperez]

It's ok if you can't share a private repo, but you can try creating a reproduction. I'm not doubting there might be an issue, but we need a way to reproduce it to see what's going on and properly troubleshoot it.

As a last resort to unblock you, if that dependency is causing you trouble, you can always override the inferred dependsOn for that target in your nx.json file. I'm not saying this as a solution, but as a workaround until we can identify what's really going on and properly address it.

[fregante]

This ticket is a request to stop having typecheck depend on build as it does not require it. The "this causes bad data to be cached" is kinda tacked on and just a guess.

For the first part you don't need a repro, you can verify that any monorepo can be typechecked in its entirety without having to depend on build.

[leosvelperez]

Mm, you're right, and I can see the issue. Just to clarify, that PR was not focused on making typecheck faster with the dependency vs not having the dependency. The benchmarks in the PR did not compare that. It was meant to fix one thing, which it did but it introduced the issue you're referring to by mistake.

you can verify that any monorepo can be typechecked in its entirety without having to depend on build

We know this. We were trying to solve an issue with both tasks producing outputs to the same location, but I think it's solved with one change in that PR that didn't require having the dependency.

Let me check a few things, and I'll get back to you with an update.

[leosvelperez]

Right, I fully remember now what exactly we are addressing with the current solution (I should have described the issue better in that PR). Apologies, but I had forgotten the primary motivation behind the current setup. We wanted to reduce the duplicated processing that comes with running both build and typecheck (using tsc -b). Some files can be processed twice depending on which order those tasks run:

• running typecheck and then build will process all the files included by the tsconfig.lib.json twice (one per task)
• running build and then typecheck will process all the files included by the tsconfig.lib.json once (typecheck reuses the output of build)

The only way to prevent duplicate processing is to use the current solution or not have two tasks. We tried not inferring the typecheck task, but as mentioned in #31892 (comment), that caused another issue where other files included by other tsconfig files were not typechecked. That's when we decided to go with the current solution because it should work correctly in CI if you run the recommended tasks:

nx affected -t typecheck build

When you run both tasks in the same run, you'll see the kind of times we were showing in the PR. If you run them separately, the aggregated time can be worse, depending on which you run first and whether the output for the other task is present (so it can be reused) and also due to the overhead of running two different commands. If you're distributing the tasks' execution, and there are no dependencies between tasks, outputs from other tasks are not guaranteed to exist in a given agent.

So, that's the full summary of why we have the current solution. In your case, I'd argue that you'd be better off changing the command you're running on CI. You mentioned you were running nx run-many -t typecheck, which would have two issues:

• You're always running everything instead of what's affected
• You're running tasks in different executions/runs/commands instead of running them all at once and letting the Nx orchestrator distribute their execution (either only locally or using DTE)

So, to summarize, we still think this yields the best performance on CI when tasks are run as recommended (and as generated by our CI generators) because it reduces some duplicated processing.

Please let me know your thoughts. I'm also interested in the reasons behind you using nx run-many -t typecheck instead of nx affected -t typecheck build. That in itself might be the real/separate issue.