js:tsc executor fails when run in a target not named "build"

[ajwootto]

Current Behavior

If you try to build something using the @nrwl/js:tsc executor that depends on some other packages in the repository, it works as long as the target that is running it is named "build".

It seems that if you name it anything else, it breaks some internal assumptions the package is making and prevents it from rewriting tsconfig path aliases such that the build fails with a bunch of Typescript resolve errors from the dependent packages.

Expected Behavior

The executor should work in any target regardless of what it's named, unless there's some piece of documentation I'm missing that explains why this is the case.

GitHub Repo

https://github.com/DevCycleHQ/js-sdks

Steps to Reproduce

1. clone repo
2. run nx build js
3. it builds successfully
4. change the "build" target in sdk/js/project.json to some other name
5. run nx <new build name> js
6. build now fails with a bunch of Typescript resolve errors

Nx Report

>  NX   Report complete - copy this into the issue template

   Node   : 18.16.0
   OS     : darwin arm64
   yarn   : 3.6.0
   Hasher : Native

   nx                 : 16.3.2
   lerna              : 5.6.2
   @nx/js             : 16.3.2
   @nx/jest           : 16.3.2
   @nx/linter         : 16.3.2
   @nx/workspace      : 16.3.2
   @nx/cypress        : 16.3.2
   @nx/detox          : 16.3.2
   @nx/devkit         : 16.3.2
   @nx/esbuild        : 16.3.2
   @nx/eslint-plugin  : 16.3.2
   @nx/next           : 16.3.2
   @nx/node           : 16.3.2
   @nx/react          : 16.3.2
   @nx/react-native   : 16.3.2
   @nx/rollup         : 16.3.2
   @nrwl/tao          : 16.3.2
   @nx/web            : 16.3.2
   @nx/webpack        : 16.3.2
   typescript         : 5.0.4
   ---------------------------------------
   Local workspace plugins:
   	 @devcycle/bucketing-assembly-script
   	 @devcycle/openfeature-nodejs-provider
   	 @devcycle/bucketing-test-data
   	 @devcycle/bucketing
   	 @devcycle/devcycle-react-native-sdk
   	 @devcycle/types
   	 @devcycle/nodejs-server-sdk
   	 @devcycle/devcycle-react-sdk
   	 @devcycle/devcycle-js-sdk

Failure Logs

No response

Operating System

• [X] macOS
• [ ] Linux
• [ ] Windows
• [ ] Other (Please specify)

Additional Information

No response

[mandarini]

@ajwootto thanks for filing an issue! :)

I cloned your repo, yarn installed the dependencies, then ran nx build nodejs and got this error: https://app.warp.dev/block/12n8kdP3UvipA1TTQW6kAY

Then I installed protoc and I got this error after trying to run nx build nodejs again: https://app.warp.dev/block/gw003ybjTjOjiUHH0u9TFT

But this does not matter much, in any case. I created my own repo: https://github.com/mandarini/tsc-target-name. Please see this repo and read the README, too. It explains what I did.

When you are changing the name of a target to something else, when invoking this target you need to use the new name, too. So, if you change the build to anything, then you will need to do nx anything nodejs instead of nx build nodejs.

Please let me know if that helps! :) I added the more info needed in case that was not your issue, and I misunderstood, so I need more info! :)

[ajwootto]

Hi @mandarini !

Sorry, I made a mistake in the repro steps. After renaming the target, I was correctly calling the newly-named target, eg. nx <my new name> nodejs

The problem appeared when that task was executed, where I received a bunch of Typescript errors about failures to resolve the dependent library code.

It may also be easier to reproduce in that repo with the "js" project, because it doesn't require protobuf and other tools to be installed.

Try the same instructions with js rather than nodejs

sorry for the confusion!

[ajwootto]

I opened a PR against your repo that adds a reproduction of the issue: https://github.com/mandarini/tsc-target-name/pull/1

[mandarini]

Oooook ! I see the issue now! :) Thanks for the repro

[mandarini]

@ajwootto temp workaround until I fix this: if you name the build target of the imported lib the same as the build target of the parent lib, then it works. But I'll fix this

[mandarini]

So, the issue is:

For @nx/js:tsc executor and for @nx/js:swc executor, if one project imports another project, both projects' build targets need to have the same name.

[mandarini]

We are not going to be fixing this right now, will get to it soon, however, possibly within the next month. We want to follow a different approach @ajwootto .

For the time being here are two workarounds you can do:

The scenario:

Here's the scenario:

• parent-lib has my-build-1 target with @nx/js:tsc executor for building
• parent-lib depends on child-lib which has my-build-2 target with @nx/js:tsc executor for building

The two different workarounds

You can use one of the two:

Same build names

You can name all the build targets with the same name. So, in the above scenario, rename my-build-2 target of child-lib to my-build-1.

Dummy same-name build target

You can create a dummy same-name build target in the project where you don't want to rename your actual build target, which will depend on the build target you want. So, in the above scenario, in the project.json of child-lib you can add this new target:

    "my-build-1": {
      "dependsOn": ["my-build-2"],
      "command": "echo dummy build",
      "options": {
        "outputPath": "dist/libs/mylib",
        "tsConfig": "libs/mylib/tsconfig.lib.json"
      }
    },

You can see my reproduction repository to understand better what I am saying (credits to @jaysoo for this solution).

[ajwootto]

Thanks for looking into it @mandarini

would it make sense to keep the issue open until then since it is technically a bug that is going to be fixed? Or is this expected behaviour?

Edit: I see in that PR that there was discussion around adding it to the docs, which I strongly agree with since this is a huge pitfall if you aren't aware of it. I don't think the incremental builds page is the right place for it, because that page seems to deal mostly with "scaling your large project by splitting things up into many builds" and here I'm dealing with NPM package publishing.

I think this page would be more appropriate: https://nx.dev/more-concepts/buildable-and-publishable-libraries#publishable-and-buildable-nx-libraries

I think there are also some things that Nx could do to make it less painful when you run into this, like failing task execution when a buildable library depends on another library where it can't find the "build" target to read from, as was the case here.

[mandarini]

Yeah, the reason I closed it is because the issue is not exactly what is described, but I guess we can keep it open, sure!

[ajwootto]

Yeah, the reason I closed it is because the issue is not exactly what is described, but I guess we can keep it open, sure!

@mandarini yeah no worries, just didn't want it to get lost!

by the way I posted an edit to the comment above with some additional considerations

[mandarini]

Oh no it will not get lost, it's already added in our "to-do" list haha! I wouldn't close it like that, under the carpet :P

[github-actions[bot]]

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.