<!-- 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. -->
An RFC about this feature is happening here: #29025. This has the most
information about this feature.
<!-- This is the behavior we have today -->
Nx currently does not explicitly handle tasks which run continuously
until they are terminated.
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR adds the initial support for continuous tasks which run
continuously until they are terminated. This adds the ability to depend
on continuous tasks. There is some more work to be done but this will be
enough as an MVP.
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/js/typescript` plugin sometimes throws an error due to a
mismatch between the cached information for the tsconfig files and a
newer implementation.
## Expected Behavior
The `@nx/js/typescript` plugin should correctly invalidate the cached
tsconfig files when the implementation changes.
## Related Issue(s)
Fixes #
## Current Behavior
The helper to add a project to the package manager workspaces'
configuration doesn't handle correctly when there are no patterns and
this results in the error `Invalid glob pattern` being thrown.
## Expected Behavior
The helper to add a project to the package manager workspaces'
configuration should handle when there are no patterns.
## Related Issue(s)
Fixes #
## Current Behavior
When `buildLibsFromSource: false`, webpack fails to resolve custom
entries in the tsconfig `paths`
## Expected Behavior
The tsconfig paths will be correctly loaded by webpack and resolved.
## Related Issue(s)
Fixes#30155.
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
The `@swc/cli` version we're currently using has a security
vulnerability due to dependency on `cross-spawn`. This PR updates it to
the version that fixes the vulnerability.
Advisory: https://github.com/advisories/GHSA-3xgq-45jj-v275
## Current Behavior
Existing and new JS workspaces have a high security warning.
## Expected Behavior
No high security warning for new workspaces, and existing ones are
updated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/js/typescript` plugin doesn't handle [extending from multiple
tsconfig
files](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#supporting-multiple-configuration-files-in-extends).
It also identifies local workspace packages linked by the package
manager as external dependencies.
## Expected Behavior
The `@nx/js/typescript` plugin should support extending from multiple
tsconfig files. It should also identify local workspace packages linked
by the package manager correctly and add their resolved path to the task
inputs (not as external dependencies).
## Related Issue(s)
Fixes#29678
## 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
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 #
## 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
## 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 #
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 #
`tinyglobby` at `0.2.10` (what we use now) is slow on shallow files, but
the latest version `0.2.12` is fast due to this PR
https://github.com/SuperchupuDev/tinyglobby/pull/69/files.
This PR updates both the js and esbuild plugins to use the newest
versions, but also adds `tinyglobby@^0.2.12` to our root `package.json`
so we get the speed increase right away. I removed `fast-glob` in our
repo scripts and replaced it with `tinyglobby`.
## Current Behavior
Asset handling is slow for shallow files like `LICENSE` but is fine for
scoped patterns like `src/**/*.ts`.
## Expected Behavior
Asset handling should be fast for shallow files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
To create a new workspace that uses the new TS solution setup the
`--workspaces` flag must be provided (Node, React, and Vue stacks).
## Expected Behavior
New workspaces should be created by default using the new TS solution
setup (Node, React, and Vue stacks). Users can opt out of it by
providing the `--no-workspaces` flag.
## Related Issue(s)
Fixes #
## Current Behavior
Moving a project included in the package manager workspaces setup to a
new destination that's not matched by that configuration results in the
project not included in the package manager workspaces setup.
## Expected Behavior
Moving a project included in the package manager workspaces setup to a
new destination that's not matched by that configuration should result
in the new destination included in the workspaces setup.
## Related Issue(s)
Fixes #
The following are the main changes in the context of the TS solution
setup:
- Ensure `name` in `package.json` files is set to the import path for
all projects
- Set `nx.name` in `package.json` files when the user provides a name
different than the package name (import path)
- Clean up project generators so they don't set the `nx` property in
`package.json` files unless strictly needed
- Fix `@nx/vue:application` generator so it creates the Nx config in a
`package.json` file for e2e projects
- Ensure `@types/node` is installed in `vitest` generator
- Fix generated Vite config typing error (surfaced with Vite 6)
- Ensure `jsonc-eslint-parser` is installed when the
`@nx/dependency-checks` rule is added to the ESLint config
- Misc minor alignment changes
## Current Behavior
## Expected Behavior
## Related Issue(s)
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 -->
If we are using `esbuild` as our bundler and ts project references
(`--workspaces`) local libraries are not building are not resolved in
the build artifacts.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using ts project references with esbuild all types libraries
(buildable / non-buildable) should work out of the box.
## 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
In the TS solution setup, several project generators produce the runtime
tsconfig files (e.g. `tsconfig.lib.json`) with the `outDir` set to
`out-tsc/<project name>`. This causes issues with the inferred
`typecheck` task because the project `package.json` has the `types`
export pointing to `dist/...`, which wouldn't be produced by
`typecheck`.
## Expected Behavior
In the TS solution setup, project generators should produce the runtime
tsconfig files (e.g. `tsconfig.lib.json`) with the `outDir` set to a
path (`dist`) that matches the value in the project `package.json`'s
`types` export.
## Related Issue(s)
Fixes #
This PR adds support for skipping `typecheck` targets when using
`@nx/js/typescript`. Inside `tsconfig.json` for each project, you can
set `nx.addTypecheckTarget` to `false` to not infer `typecheck`.
This allows use to skip `typecheck` for JS projects using `tsc` to
build. Since `tsc` is already used during build, we don't need to run
`typecheck` that is just duplicated work.
<!-- 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
JS libs using `tsc` to build will do typechecking twice. Once during
`build` and once during `typecheck`.
## Expected Behavior
JS libs using `tsc` do not infer `typecheck` by default. And users can
change this behavior by setting `nx.addTypecheckTarget` in
`tsconfig.json`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
- Generating a non-buildable library in a workspace using the TS
solution setup where a plugin registration for `@nx/js/typescript`
already exists and doesn't configure a build target, results in that
plugin registration being updated excluding the new project and a new
registration being added including the project but inferring the build
target.
- Generating a library in a sub-directory that matches a pattern in the
package manager workspaces configuration, results in a more specific
pattern being added to the workspace configuration.
## Expected Behavior
- Generating a non-buildable library in a workspace using the TS
solution setup where a plugin registration for `@nx/js/typescript`
already exists and doesn't configure a build target, should not modify
that plugin registration and it should not add an extra one.
- Generating a library in a sub-directory that matches a pattern in the
package manager workspaces configuration, should not add a more specific
pattern.
## Related Issue(s)
Fixes #
## Current Behavior
Copy assets plugin for Vite is not copying files in watch mode when
those files are changed.
This is due to the path being incorrect after calculation.
There is also no indication to the user that the copy completed at all.
## Expected Behavior
Fix path calculation to allow copy to occur correctly
Output the relative dest of the file after copy completed.
## Related Issue(s)
Fixes#30141
Fix a bug introduced in #30087
#### Current Behavior
The `@nx/js` plugins throw an error when the project is served in the
project root but not in the workspace root.
#### Expected Behavior
Ensure that `nx run $project:serve` works correctly both in the
workspace root and the project root, restoring the previous behavior.
#### Related Issue(s)
Fixes#30087
## Current Behavior
When multiple processes/tasks are running in parallel for a single
project that produce tmp tsconfig files for buildable libraries, they
can clobber each other.
## Expected Behavior
Ensure the config file is generated with a unique id to prevent
clobbering
## Current Behavior
- The persistent tsconfig files cache used by the `@nx/js/typescript`
plugin does not get invalidated when the tsconfig files it extends from
are updated.
- Absolute paths are stored in the cache, which would be incorrect when
distributing the cache.
- The plugin throws a cryptic error when the lock file doesn't exist.
## Expected Behavior
- The persistent tsconfig files cache used by the `@nx/js/typescript`
plugin should get invalidated when the tsconfig files it extends from
are updated.
- Paths should be stored relative to the workspace root.
- The plugin should handle when the lock file is missing.
Additionally, a few other performance improvements were made to offset
the overhead introduced by creating a stricter cache key:
- cache and reuse file reads between tsconfig reads and file hashing
(now each file is only read once, if read at all)
- initialize a pre-populate tsconfig files cache in a first pass to skip
checking cache entries' key in subsequent reads
- reduce the tsconfig file cached content we store to disk
- cache the check for external project references
## Related Issue(s)
Fixes#29429
Improve the perf of the `@nx/js/typescript` plugin both in cold and warm
scenarios. The main changes done are:
- Batch some processing to do it once instead of doing it per config
file (avoids some duplicated processing)
- Use a custom TS host to read tsconfig files to reduce I/O operations
- Cache tsconfig files' reads
Benchmark results in a repo with 656 TS projects:
```
# Before the changes
Cold (NX_CACHE_PROJECT_GRAPH=false): ~2285 ms
Warm (NX_CACHE_PROJECT_GRAPH=true): ~2142 ms
# After the changes
Cold (NX_CACHE_PROJECT_GRAPH=false): ~597 ms
Warm (NX_CACHE_PROJECT_GRAPH=true): ~220 ms
```
Note: Once https://github.com/nrwl/nx/pull/29935 is merged. I'll send
another change to batch the file hashes.
## Current Behavior
## Expected Behavior
## Related Issue(s)
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 -->
- there is no option `fallbackCurrentVersionResolver: 'disk',`
- can't run release for newly created publishable libraries
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- move code to add release for publishable libraries into its own file
to be reused by other stacks
- add `fallbackCurrentVersionResolver: 'disk',` to project's
release.version. generatorOptions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/29723
This pull request contains a few changes to enhance our swc support for
Next.js with a custom server.
### Issues
Currently, we have a few issues with our configuration when using
executors for Next.js with a custom server:
1. The custom server does not have an independent build configuration.
2. The custom server does not have an independent output directory.
3. Serving via `@nx/next-server` or via `@nx/js:node` with
configurations `production` and `development` does not always work.
(These are contained inside `project.json`).
### Changes
All the above issues have been addressed
1. We now have an independent swc build configuration
called`.server.swrc` (_follows the same format as `.eslintrc`,
`.babelrc`_) etc...
2. Now each custom server output will be named `{app}-server` such that
if you have multiple custom servers for multiple apps the names will not
clash.
3. Serving now works out of the box but can be adjusted to suit your
needs via updating the custom server entry file `main.ts`
When we run inferred Jest tasks with workspaces enabled, it'll result in
an error like this:
```
npm ERR! A complete log of this run can be found in: /Users/jack/.npm/_logs/2025-02-05T13_41_51_079Z-debug-0.log
Error: Command failed: npm config set //localhost:4873/:_authToken "secretVerdaccioToken"
npm ERR! code ENOWORKSPACES
npm ERR! This command does not support workspaces.
```
This is because the cwd is the project root (e.g. `packages/mypkg-e2e`),
and `npm config set` cannot be run on packages inside the workspaces. By
passing `--ws=false`, it'll only be run in the workspace root and won't
error.
## Current Behavior
Jest e2e tests inferred from `@nx/jest/plugin` fail when starting a
local registry.
## Expected Behavior
Jest e2e tests should work even if they are inferred (or have cwd other
than workspace root).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `@nx/js/typescript` plugin infers tasks with `--verbose`. This can
prevent users from running the same task with `--clean.` It can also
produce a lot of logs that might not be too relevant.
## Expected Behavior
The `@nx/js/typescript` plugin should not infer tasks with `--verbose`.
This is more aligned with other tools.
A new plugin option `verboseOutput` is added to allow inferring all
tasks with `--verbose` if desired.
Note: This revealed that some things were working (e.g., `dependsOn`)
because all the `typecheck` commands inferred by the different plugins
matched. As soon as the command is different, the different inferred
tasks are not merged, which is expected. We shouldn't rely on that, and
each plugin inferring the task should set the right options/metadata.
The different plugins were updated in this PR accordingly (they don't
have the verbose option).
We'll follow up on this later, so only the `@nx/js/typescript` plugin
infers the `typecheck` task. This is a breaking change so it will be for
Nx v21.
## Related Issue(s)
Fixes#28677
<!-- 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 -->
If I set `skipFormat` to `true` when creating a JS library with the
rollup bundler, formatting is still run during the rollup configuration
creation step.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`skipFormat` flag should be respected.
## 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 -->
```bash
@coreproject-moe/monorepo@ /home/moonlitgrace/Projects/coreproject-monorepo
├─┬ @coreproject-moe/icons@0.0.65 -> ./packages/icons
│ └─┬ jest-config@29.7.0
│ └─┬ jest-circus@29.7.0
│ └─┬ dedent@1.5.3
│ └── babel-plugin-macros@2.8.0 deduped invalid: "^3.1.0" from node_modules/dedent
└─┬ @nx/js@20.0.5
└── babel-plugin-macros@2.8.0
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
No conflicts, without overriding `package.json`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28620
<!-- 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 an e2e task using the `@nx/cypress:cypress` executor that starts
a dev server by running another task that uses the `@nx/js:node`
executor result in the process to hang after the e2e tests have finished
running.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The async generator returned by starting the dev server and consumed by
the `@nx/cypress:cypress` executor should be finished, and the
`@nx/js:node` executor should properly clean up its child process once
the generator is finished.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29571
This PR updates our generators to no longer generate with `nx` in
`package.json` by default. The only times it is needed is if you pass
add `tags` or `implicitDependencies` to the project config.
This PR replaces our `projectType` checks to use the `getProjectType`
util from `@nx/js` to prefer the project config, but otherwise will
check for our conventions (e.g. using `exports` for libs,
`tsconfig.lib.json` vs `tsconfig.app.json`).
## Impact
- There shouldn't be any behavioral changes to existing projects that
have explicit `projectType`, `name`, etc. in with `project.json` or
`package.json` (via `nx` property).
- For new projects created under the new TS setup, the `nx` property
will no longer be there. Generators with logic that depend on
`projectType` will now check for `tsconfig.lib.json` and
`tsconfig.app.json` (so all of our generators are covered). If none of
those tsconfig files are found, then we check `package.json`, since
libraries are required to have `exports` to be consumed.
## Current Behavior
When using the TS solution setup and `jest` is used, `ts-jest` is used
as the transformer in most cases (except when the build compiler is
`swc`). The `ts-jest` transformer doesn't support modern module
resolutions like `nodenext` and it doesn't support TS project references
either.
## Expected Behavior
When using the TS solution setup and `jest` is used, `@swc/jest` should
be used as the transformer in cases where previously `ts-jest` was being
used and regardless of using `swc` as the build compiler.
## Related Issue(s)
Fixes #
## Current Behavior
Generating a js library with esbuild or rollup as bundlers and vitest as
the unit test runner, results in an eslint configuration where the
bundler config file is not ignored from the `@nx/dependency-checks`
rule.
## Expected Behavior
Generating a js library with esbuild or rollup as bundlers and vitest as
the unit test runner, should result in an eslint configuration where the
bundler config file is ignored from the `@nx/dependency-checks` rule.
## Related Issue(s)
Fixes #
## Current Behavior
When generating a non-buildable js library in a workspace using the
integrated setup, a `package.json` file is generated.
## Expected Behavior
When generating a non-buildable js library in a workspace using the
integrated setup, a `package.json` file should not be generated.
## Related Issue(s)
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
Creating a new workspace using the TS solution setup always generates a
`tsconfig.base.json` with `module: nodenext` and `moduleResolution:
nodenext`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Creating a new workspace using the TS solution setup should generate a
`tsconfig.base.json` with `module: nodenext`/`moduleResolution:
nodenext` for Node stacks and `module: esnext`/`moduleResolution:
bundler` for Web stacks (React, Vue).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
