@nx/js:tsc doesn't work with different rather than build task name

[ThePlenkov]

Current Behavior

Hi!

I have noticed that if I rename build command to let's say build:tsc because I want to introduce another build task with build:tsc dependency - the command stops working. It seems thar it determines wrongly cwd and path to a config

Expected Behavior

It should be possible to rename build tasks and to run them as a dependency

GitHub Repo

No response

Steps to Reproduce

In my project.json the following task works as nx build package:

    "build:": {
      "executor": "@nx/js:tsc",
      "outputs": [
        "{options.outputPath}"
      ],
      "options": {
        "outputPath": "dist/packages/direct-load",
        "main": "packages/direct-load/src/index.ts",
        "tsConfig": "packages/direct-load/tsconfig.lib.json",
        "assets": [
          "packages/direct-load/*.md",
          "packages/direct-load/ui5.yaml"
        ]
      },
      "dependsOn": [
        "^build"
      ]
    },

but if defined like this - it doesn;t:

    "build:tsc": {
      "executor": "@nx/js:tsc",
      "outputs": [
        "{options.outputPath}"
      ],
      "options": {
        "outputPath": "dist/packages/direct-load",
        "main": "packages/direct-load/src/index.ts",
        "tsConfig": "packages/direct-load/tsconfig.lib.json",
        "assets": [
          "packages/direct-load/*.md",
          "packages/direct-load/ui5.yaml"
        ]
      },
      "dependsOn": [
        "^build"
      ]
    },
    "build": {
      "executor": "nx:run-commands",
      "options": {
        "options": {
          "commands": [
            "npm pkg delete dependencies express"
          ],
          "cwd": "dist/packages/direct-load"
        }
      },
      "dependsOn": [
        "build:tsc"
      ]
    },

In the second case I have an error like:

packages/direct-load/src/lib/direct-load.ts:1:32 - error TS6059: File '/workspaces/fiori-tools/packages/types/src/index.ts' is not under 'rootDir' '/workspaces/fiori-tools/packages/direct-load'. 'rootDir' is expected to contain all source files.

which makes me just think that root folder is wrongly determined in used like this.

Could you please have a look?

Since we do not have post-targets I see this way of declaring targets as the most logical way to extend standard tasks without writing an own executor.

Nx Report

node ➜ /workspaces/fiori-tools (main) $ npx nx report

 >  NX   Report complete - copy this into the issue template

   Node   : 20.3.1
   OS     : linux-x64
   npm    : 9.6.7
   
   nx             : 16.5.3
   @nx/js         : 16.5.3
   @nx/jest       : 16.5.3
   @nx/linter     : 16.5.3
   @nx/workspace  : 16.5.3
   @nx/devkit     : 16.5.3
   @nx/node       : 16.5.3
   @nrwl/tao      : 16.5.3
   nx-cloud       : 16.1.1
   typescript     : 5.1.6
   ---------------------------------------
   Local workspace plugins:
         @sap-ux/types
         @fiori/direct-load
         @fiori/home-page
         @fiori/ui5-ts
         @fiori/types

Failure Logs

No response

Operating System

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

Additional Information

No response

[ThePlenkov]

I have spend some time in the debugger and I put breakpoint in typescript emitFiles:

So what I have observed - is that there is a difference in config files: for nx build package and nx build:tsc package even though targets are identical.

And difference is in the paths resolution:

Somehow it resolves depedencies to dist for build:tsc name and to source package for just build name

[ThePlenkov]

these differences come from tmp/packages/direct-load/tsconfig.generated.json file

[ThePlenkov]

ok I found the place:

it looks like it thinks that dependency is buildable if it has a target with same same.. not sure if it's a good logic

[ThePlenkov]

what about introducing a special targetDefaults for @nx/js:tsc in nx.json? Something like:

{
  "targetDefaults": {
    "@nx/js:tsc": {
      "options": {
        "buildTaskName" : "build"
      },
  }
}

It can be even default.. But what I want to say is that it feels more logical that is better stays hardcoded rather then inherits from a depentent project which is confusing to my opinion

[mandarini]

related: #11289

This is potentially fixable if you align all the build target names to be the same.

For anyone having that error, solution: #17798 (comment)

[ThePlenkov]

@mandarini correct, that's what I found too #18257 (comment)

Not sure though if it's a good logic

[mandarini]

@ThePlenkov yeah, we're going to fix this at a later version, but for now it's the solution! :D

[leosvelperez]

@ThePlenkov did you solve the issue?

In Nx 16.6.0, we introduced a new way to identify the build target of dependent buildable libraries. The new way doesn't rely on the targets having the same name, but rather on the information available in the task graph. This behavior is not yet enabled by default, but you can try it by setting the following env var: NX_BUILDABLE_LIBRARIES_TASK_GRAPH=true.

We're trying to get feedback whether this new way works as expected before turning it on by default. Could you try it and let us know how it goes? We want to know:

• We don't break existing setups (with the same target name)
• It handles buildable library targets with different names (provided they are part of the task graph, so, target dependencies must be correctly configured)

[leosvelperez]

I'm closing this. For anyone coming to this, please refer to the explanation at #18257 (comment).

Ensure your build pipeline definition is accurate and tasks depend on the correct tasks. Set the env var NX_BUILDABLE_LIBRARIES_TASK_GRAPH=true to run your builds (it can be set in an .env file).

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.