## Current Behavior
There is no dependency between the inferred `typecheck` and `build`
tasks. Depending on their run order, this can result in duplicated
processing (type-checking, `.d.ts` generation). Given there's no
explicit dependency, the order would be non-deterministic.
Additionally, when `outDir` is set in the tsconfig files, it's used
as-is in the currently inferred outputs for `typecheck`. This can result
in extra files being cached for the task.
## Expected Behavior
For optimum performance, the inferred `typecheck` task should depend on
the `build` task. The `typecheck` task's outputs should be more granular
so that only the relevant files (declaration files and declaration map
files if enabled) are cached.
### Explanation
Consider a typical setup with specific tsconfig file for files with
different concerns:
- tsconfig.lib.json: TS configuration for the library runtime files
- tsconfig.spec.json: TS configuration for the unit test files
- tsconfig.json: TS solution configuration, a solution file that
references the specific config files above
When running `tsc -b tsconfig.lib.json --verbose` (build), we can see
how the `tsconfig.lib.json` TS project is built:
```bash
Projects in this build:
* tsconfig.lib.json
Project 'tsconfig.lib.json' is out of date because output file 'dist/tsconfig.lib.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
```
After that, if we run `tsc -b tsconfig.json --emitDeclarationOnly
--verbose` (typecheck), we'll see how the `tsc` output for
`tsconfig.lib.json` is reused:
```bash
Projects in this build:
* tsconfig.lib.json
* tsconfig.spec.json
* tsconfig.json
Project 'tsconfig.lib.json' is up to date because newest input 'src/lib/file.ts' is older than output 'dist/tsconfig.lib.tsbuildinfo'
Project 'tsconfig.spec.json' is out of date because output file 'out-tsc/jest/tsconfig.spec.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.spec.json'...
```
The relevant bit above is `Project 'tsconfig.lib.json' is up to date
because newest input 'src/lib/file.ts' is older than output
'dist/tsconfig.lib.tsbuildinfo'`. Because the initial `build` task
already typechecks and produces `.d.ts` files for the
`tsconfig.lib.json`, when the `typecheck` task runs, `tsc` identifies
that the outputs for that config files were already produced and can be
reused.
If we were to run the tasks in the inverse order, the results would be
different:
```bash
> npx tsc -b tsconfig.json --emitDeclarationOnly --verbose
Projects in this build:
* tsconfig.lib.json
* tsconfig.spec.json
* tsconfig.json
Project 'tsconfig.lib.json' is out of date because output file 'dist/tsconfig.lib.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
Project 'tsconfig.spec.json' is out of date because output file 'out-tsc/jest/tsconfig.spec.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.spec.json'...
> npx tsc -b tsconfig.lib.json --verbose
Projects in this build:
* tsconfig.lib.json
Project 'tsconfig.lib.json' is out of date because buildinfo file 'dist/tsconfig.lib.tsbuildinfo' indicates there is change in compilerOptions
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
```
Note how when the `build` task is run, `tsc` identifies that there was a
change in `compilerOptions` (`--emitDeclarationOnly`) and it requires
building the project. This is because the `typecheck` task only
generates declaration files and the `build` task must also emit the
transpiled `.js` files.
### Benchmark
Running those two different flows in a simple (non-Nx) project with a TS
configuration structure like the one mentioned above and with 5000 TS
files split in half for runtime and test files yields the following:
```bash
hyperfine -r 5 -p "rm -rf dist out-tsc" \
-n "build => typecheck" "npx tsc -b tsconfig.lib.json && npx tsc -b --emitDeclarationOnly" \
-n "typecheck => build" "npx tsc -b tsconfig.json --emitDeclarationOnly && npx tsc -b tsconfig.lib.json"
Benchmark 1: build => typecheck
Time (mean ± σ): 6.832 s ± 0.094 s [User: 11.361 s, System: 1.060 s]
Range (min … max): 6.734 s … 6.985 s 5 runs
Benchmark 2: typecheck => build
Time (mean ± σ): 8.789 s ± 0.015 s [User: 14.817 s, System: 1.267 s]
Range (min … max): 8.771 s … 8.812 s 5 runs
Summary
build => typecheck ran
1.29 ± 0.02 times faster than typecheck => build
```
## Related Issue(s)
Fixes #
## Current Behavior
The Windows drive letter in paths could have different casing in certain
circumstances. The `normalizePath` helper only considers it as
PascalCase, which can result in issues when the path drive letter is
actually in lowercase.
## Expected Behavior
The `normalizePath` should correctly handle the Windows drive letter
regardless of the casing.
## Related Issue(s)
Fixes#28798
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, if you have a webpack application that uses out
NxWebpackAppPlugin and has a non-buildable lib that has exports with
extension enabled for example:`export * from './lib/lib8446520.js';`.
The app fails to build.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using webpack and including libraries that contain extension it
should resolve.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30492
## Current Behavior
The `@angular/google-maps` package version is not updated when running
`nx migrate`.
## Expected Behavior
The `@angular/google-maps` package version should be updated when
running `nx migrate`.
## Related Issue(s)
Fixes#30523
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Update the install instructions for the new java landing page
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
Nothing there.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Adds a new
[/java](https://nx-dev-git-nxdev-gradle-landing-page-nrwl.vercel.app/java)
landing page
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Mike Hartington <mikehartington@gmail.com>
Co-authored-by: Mike Hartington <mhartington@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When nx is installed in the `.nx` directory the init flow is
substantially different. This changes how some prompting works as well
as how plugin installation flows.
## Expected Behavior
The two flows operate in a similar manner.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, the docs does not differentiate between inferred target
outputs and executor outputs.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Since the outputs differ we should highlight the difference in our docs.
Also, if we pass a bundler to the Next.js lib app generator it should
respect that option.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`@nx/rspack` set ups currently install `@rspack/plugin-minify` which has
been deprecated. It is also unused in the configurations that are
generated.
## Expected Behavior
Remove unused the unused `@rspack/plugin-minify`
## Related Issue(s)
Fixes#30318
## Current Behavior
The `@nx/module-federation` depends on the `@rspack/core` package but it
is currently only set as a `peerDep` meaning users need to install the
package manually.
## Expected Behavior
As the package depends on `@rspack/core`, make sure it is set as a
dependency
## Related Issue(s)
Fixes#30307
## Current Behavior
The `NxAppWebpackPlugin` and `NxAppRspackPlugin` both always set `<base
href="` even when it is set to undefined.
## Expected Behavior
If `baseHref` is set to false, do not set `<base href`.
## Related Issues
#30291
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Every time the vitest generator was run a new duplicate '^build'
dependency was added to the target defaults for the test task.
## Expected Behavior
No duplicate entries added!
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30288
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
If a buildable library depends on another buildable library that has
`outputs` using globs the build fails when using an executor that remaps
the dependency TypeScript path mappings to the build outputs.
## Expected Behavior
Building a buildable library using an executor that remaps the
dependency TypeScript path mappings to the build outputs should succeed.
The remapping logic should identify and replace the glob patterns and
keep the fixed part of the pattern (no segment with wildcards).
Note: additionally, an obsolete check was removed from the
`@nx/angular:package` and `@nx/angular:delegate-build`.
## Related Issue(s)
Fixes#30041
## Current Behavior
Buildable libraries using `tsc` for `build` don't get a `typecheck`
task, which results in test files not being type-checked.
## Expected Behavior
The `typecheck` task should be inferred, and test files should be
type-checked.
## Related Issue(s)
Fixes #
Jest should be compatible with react-router out of the box.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, there are two issues when using `jest` with react-router out
of the box
1. Test files are not included from `tsconfig`
2. While running the test `jsdom` is missing Node's `TextEncoder` and
`TextDecoder` so compilation fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running a test should work without issues when you create a react-router
app with Jest.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30387
## Current Behavior
The `@nx/js/typescript` plugin infers incorrect inputs for tsconfig
`include` patterns when their last segment doesn't contain a wildcard or
an extension (e.g. `"include": ["src"]`).
## Expected Behavior
The `@nx/js/typescript` plugin should [normalize such `include`
patterns](https://www.typescriptlang.org/tsconfig/#include) and infer
valid inputs.
## Related Issue(s)
Fixes#30014
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
In some use cases the local plugins generators and executors are not
transpiled, which causes an error when you execute them. see for example
This issue is introduced by this PR #29539 and is actually a regression
of an error we had in NX 18, see #22958
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR fixes this issue by updating the if statement to register the
typescript transpiler when this is not done yet.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30132
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`nx init` always either installs `next` or `latest` versions of Nx. The
intent here is that running `npx nx init` should always provide the
latest version of Nx, and we added a condition to use `next` if we
detected a beta version of Nx was running to facilitate easier testing
of RC and beta releases. The full logic to determine which version of Nx
to setup is below:
```ts
const version =
process.env.NX_VERSION ?? (prerelease(nxVersion) ? 'next' : 'latest');
```
The goal here was to avoid hitting the `npx` cache and accidentally
creating new workspaces with an older Nx version. This logic falls apart
a bit when considering prereleases though, as `npx nx@next init` would
always check the tag to make sure its up to date rather than using a
cached version. This is the case when providing **_any_** tag to `npx`.
A bad side effect of the above is that when trying to test PR builds and
the like, `nx init` will never setup the PR build when running `npx
nx@0.0.0-pr....` opting instead to setup `next`.
## Expected Behavior
Running `npx nx@0.0.0-pr.... init` sets up an nx workspace using the
specified PR release.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
In a few different places (Crystal plugins, executors, generators,
helpers) where `ts-node` compiler options are overridden and
`moduleResolution` is being set to something other than `node16`,
`nodenext`, or `bundler`, an error can occur if the `customConditions`
compiler option is being used.
## Expected Behavior
When overriding the `ts-node` compiler options and changing forcing
`moduleResolution` to have a value that's incompatible with
`customConditions`, the latter should be unset (set to `null`) to avoid
errors.
## Related Issue(s)
Fixes #
This PR replaces the cumbersome explicit matrix in `e2e-matrix.yml` with
a dynamic matrix built from the input JSON data.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, when you generate a react app and select `--use-react-router`
and `--bundler=` any other bundler except `vite` you would be forced
into using `vite`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When you generate a React app and opt into using `--use-react-router`
with `--bundler=webpack` (for example) you will get an error stating the
React Router can only be used with `vite`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Creating new workspaces since Nx 20.6.0 will generate the Nx
configuration in `package.json` files. This is intended, given that it
is part of the new setup using TypeScript Project References and Package
Manager Workspaces, but there's no way to choose to generate the Nx
configuration in `project.json` files. Project generators do allow to
choose but there's no way to do it when creating a new workspace. This
forces users who want to use `project.json` files to generate an empty
workspace and then use a project generator.
## Expected Behavior
When creating a new Nx workspace, users can provide an option
(`--use-project-json`) to generate the Nx configuration in
`project.json` files.
## Related Issue(s)
Fixes#30464
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Running a batch executor recreates the project graph
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The project graph is passed in when running a batch executor so that it
doesn't have to get recreated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Update library generators to set a `development` conditional export for
buildable libraries' `package.json` files and set the
`customConditions` compiler options in `tsconfig.base.json`. This will
only be done for workspaces using the TS solution setup.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
This PR updates the React monorepo tutorial.
- Remove video embeds since the content is outdated (e.g. shows old TS
setup) -- we have a separate task to update and add back later
- Update the generated files to ensure they are in sync
- Update to show Playwright instead of Cypress since that is the default
- Remove one mention of `project.json` for configuration, and point to
the Inferred Tasks page instead to learn how tasks are automatically
configured
- Update code example for `apps/react-store/src/app/app.tsx` to render
`Welcome react-store` instead of `Home` so that unit and e2e tests still
pass without having to update those as well (better for the flow of the
tutorial)
## Current Behavior
The current `NxModuleFederationPlugin` does not support SSR
## Expected Behavior
The current `NxModuleFederationPlugin` supports SSR
Add `buildLibsFromSource` to the `@nx/rollup:rollup` executor to bring
it to parity with Webpack/Rspack/Vite. This allows the bundle to point
to dist if `buildLibsFromSource: false` is set, which enables
incremental builds.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
Note: This only applies to workspaces using tsconfig paths, as that
linking mechanism is assumed by `buildLibsFromSource`. For NPM
workspaces, whatever is defined in `package.json` exports is used as we
use Node resolution in the new setup.
## Current Behavior
`buildLibsFromSource` does not exist
## Expected Behavior
`buildLibsFromSource exists
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `angular-rspack` and `angular-rsbuild` packages links are always
shown on the menu after navigating to the API section
## Expected Behavior
The links for these packages should only display on the `API` page
In the nx-dev pages, adjust the interface to utilize 'EnterpriseLayout'
instead of 'DefaultLayout'. The duration of the transition in
'customer-logos.tsx' has been reduced from 500 to 200 to boost
responsiveness.
The 'enterprise-layout.tsx' file was added and contains new animation
elements to enhance end-user experience. Updates were made to
'hero.tsx', simplifying and enhancing SVG animation.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
Legacy cache users should get artifacts when remote cache is hit
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30429
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
With a project structure where build.gradle.kts is defined in a separate
buildSrc directory, and not in the root project directory where
`gradlew` is defined, the gradle project is not included in nx project
graph. This is a valid gradle project configuration, with project-report
tasks configured. Running ./gradlew projectReport works and builds the
projectReport.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
With the fix, as long as expected tasks - projectReport or
projectReportAll - is defined, nx should be able to build the nx graph
regardless of the location of the `build.gradle` or `build.gradle.kts`
file.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29783
