@nx/esbuild:esbuild with "declaration": true always executes from $PWD

[scottpledger]

Current Behavior

Currently, executing nx build my-project where the build target is executed by the @nx/esbuild:esbuild executor with the "declaration": true option will produce different results depending on whether you're at the {workspaceRoot} or the {projectRoot}.

Expected Behavior

Executing a fully-specified target using the @nx/esbuild:esbuild executor should succeed from any $PWD under {workspaceRoot}.

GitHub Repo

https://github.com/scottpledger/nx-esbuild-issue

Steps to Reproduce

1. Either check out https://github.com/scottpledger/nx-esbuild-issue or perform the following:
   1.1. Create an Nx workspace with npx create-nx-workspace and the following options:

    NX   Let's create a new workspace [https://nx.dev/getting-started/intro]
   
   ✔ Where would you like to create your workspace? · nx-esbuild-issue
   ✔ Which stack do you want to use? · none
   ✔ Package-based monorepo, integrated monorepo, or standalone project? · package-based
   ✔ Do you want Nx Cloud to make your CI fast? · skip
   

   1.2. Add a package to the workspace with nx g @nx/js:lib test1 --directory=packages --bundler=esbuild and the following options:

   ✔ Which unit test runner would you like to use? · none
   ✔ What should be the project name and where should it be generated? · test1 @ packages/test1
   

   1.3. Add "declaration": true to the project.json:

   cat packages/test1/project.json | jq '. + { targets: .targets + { build: .targets.build + { options: .targets.build.options + { declaration: true } } } } ' > packages/test1/project.json
   

2. Run nx --skipNxCache build test1. This should succeed.
3. Run pushd packages/test1 ; nx --skipNxCache build test1 ; popd. It should succeed, but instead it will fail with the following error:

    NX   Invalid config file due to following: No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '["**/*"]' and 'exclude' paths were '[]'.
   

4. Run pushd packages/test1 ; nx --skipNxCache build ; popd. It should succeed, but instead it will fail with the following error:

    NX   Invalid config file due to following: No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '["**/*"]' and 'exclude' paths were '[]'.
   

Nx Report

Node   : 18.20.3
OS     : darwin-arm64
npm    : 10.7.0

nx (global)        : 19.2.0-beta.1
nx                 : 19.1.1
@nx/js             : 19.1.1
@nx/linter         : 19.1.1
@nx/eslint         : 19.1.1
@nx/workspace      : 19.1.1
@nx/devkit         : 19.1.1
@nx/esbuild        : 19.1.1
@nx/eslint-plugin  : 19.1.1
@nrwl/tao          : 19.1.1
typescript         : 5.4.5
---------------------------------------
Registered Plugins:
@nx/eslint/plugin

Failure Logs

Running `pushd packages/test1 ; nx --skipNxCache build --verbose ; popd` from the above-described repository:

> nx run test1:build

The project test1 is using the 'generatePackageJson' option which is deprecated for library projects. It should only be used for applications.
For libraries, configure the project to use the '@nx/dependency-checks' ESLint rule instead (https://nx.dev/nx-api/eslint-plugin/documents/dependency-checks).

 NX   Invalid config file due to following: No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '["**/*"]' and 'exclude' paths were '[]'.


Error: Invalid config file due to following: No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '["**/*"]' and 'exclude' paths were '[]'.
    at setupTypeScript (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/@nx/js/src/utils/typescript/run-type-check.js:62:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async runTypeCheck (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/@nx/js/src/utils/typescript/run-type-check.js:32:70)
    at async runTypeCheck (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/@nx/esbuild/src/executors/esbuild/esbuild.impl.js:167:34)
    at async esbuildExecutor (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/@nx/esbuild/src/executors/esbuild/esbuild.impl.js:118:32)
    at async getLastValueFromAsyncIterableIterator (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/nx/src/utils/async-iterator.js:15:19)
    at async iteratorToProcessStatusCode (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/nx/src/command-line/run/run.js:44:29)
    at async handleErrors (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/nx/src/utils/params.js:9:16)
    at async process.<anonymous> (/Users/scott.pledger/Development/nx-esbuild-issue/node_modules/nx/bin/run-executor.js:59:28)

————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

 NX   Running target build for project test1 failed

Failed tasks:

- test1:build

Hint: run the command with --verbose for more details.

Package Manager Version

No response

Operating System

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

Additional Information

No response

[snowmandev]

It appears this issue can be fixed by specifying a path for declarationRootDir that points to the src directory in your project's build options (e.g. "declarationRootDir": "libs/my-lib/src").

It appears there is an issue in the @nx/esbuild package (executers/esbuild/esbuild.impl.ts) within the getTypeCheckOptions function. It seems that context.root property is returning the absolute path of the workspace, causing the declarations to be written to: dist/libs/my-lib/libs/my-lib/src. As mentioned above, setting the declarationRootDir property corrects this.

[danielsharvey]

I agree with @snowmandev - using declarationRootDir works for me. However, as at now I have an issue when referencing other buildable libraries when generating declarations/typings - see #26376.

[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.