<!-- 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 https://github.com/nrwl/nx/issues/27135
<!-- 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#19911Fixes#27421
<!-- 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 -->
The types that are generated for esbuild packages are not placed into
the correct folder structure in the built package and is very dependent
of the CWD.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The declaration files should be generated correctly to match the package
and not dependent on CWD
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26261#26376
We should be consistent about how options are defined in our plugins.
Currently, there are some options that use `enum`s and some that use
typed strings. I think typed strings are preferable because someone
extending a generator only needs to import the main generator that
they're extending, not all the transitive dependencies of that
generator.
Current extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
import { Linter } from '@nx/eslint';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: Linter.EsLint,
});
}
```
Desired extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: 'eslint',
});
}
```
The problem is not just an extra line of code, the person extending the
`reactApplicationGenerator` has to dig into the implementation details
of the generator itself in order to know where to find the `Linter`
enum. The `e2eTestRunner` is already a typed string and is easily
extended.
The solution I'm proposing in this PR would define a typed string in the
same file as the existing enum. None of the implementations need to
change. No community plugin code will be broken.
<!-- 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 -->
When the application are received a shutdown signal, the application
doesn't execute before shutdown functions and directly shutdown whole
application. The situation cannot execute before shutdown functions like
[NestJS Lifecycle
Events](https://docs.nestjs.com/fundamentals/lifecycle-events) and
custom shutdown hooks.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The application can run shutdown hooks like below output:
NX Successfully ran target build for project nest-test (5s)
Debugger listening on
ws://localhost:9229/e4bd44c0-9a6a-468a-8b46-b6fef1cef1c7
For help, see: https://nodejs.org/en/docs/inspector
```
NX Successfully ran target build for project nest-test (4s)
Debugger listening on ws://localhost:9229/75c8449b-43a4-4d8b-88c0-231761d7248c
For help, see: https://nodejs.org/en/docs/inspector
To exit the process with SIGINT, press Ctrl+C
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [NestFactory] Starting Nest application...
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [InstanceLoader] AppModule dependencies initialized +10ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [RoutesResolver] AppController {/api}: +7ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [RouterExplorer] Mapped {/api, GET} route +3ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [NestApplication] Nest application successfully started +2ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG 🚀 Application is running on: http://localhost:3000/api
[Nest] 393107 - 08/09/2024, 6:31:29 PM LOG onModuleDestroy
onModuleDestroy: 5.001s
[Nest] 393107 - 08/09/2024, 6:31:34 PM LOG beforeApplicationShutdown SIGINT
beforeApplicationShutdown: 5.004s
[Nest] 393107 - 08/09/2024, 6:31:39 PM LOG onApplicationShutdown SIGINT
onApplicationShutdown: 5.005s
NX Process exited with code 130, waiting for changes to restart...
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#9237 and #18037
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.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
<!-- This is the behavior we have today -->
When re-mapping a TS path mapping like `"@foo/lib1/plugins/some-file":
["packages/lib1/src/plugins/some-file.ts"]`, it results in:
```json
"@foo/lib1/plugins/some-file": [
"dist/packages/lib1/plugins/some-file",
"dist/packages/lib1/src/plugins/some-file.ts"
]
```
The first path is wrong because it's missing the `src` directory, and
the second one has a file extension that's not in the output.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When re-mapping a TS path mapping like `"@foo/lib1/plugins/some-file":
["packages/lib1/src/plugins/some-file.ts"]`, it should result in:
```json
"@foo/lib1/plugins/some-file": [
"dist/packages/lib1/plugins/some-file",
"dist/packages/lib1/src/plugins/some-file",
"dist/packages/lib1/src/plugins/some-file.ts"
]
```
In this case, the second path would correctly point to the output. It
doesn't have an extension, which allows the compiler to pick up the
correct one.
Note that while the first and third paths are still not valid for this
specific use case, they could still be valid for other use cases, and in
any case, they're still kept for backward compatibility. The util to
re-map these paths is currently very generic and generates potentially
valid paths. The invalid paths for a given use case won't throw an error
as long as there's one that's valid.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#21699
## Current Behavior
running `nx test js` fail on windows
## Expected Behavior
running `nx test js` succeed
## side notes
1. I was skipping `packages/js/src/plugins/typescript/plugin.spec.ts`
because it makes all tests fail, and even in wsl it's very flaky, it
fail 90% of the times, but I couldn't figure out why
I think it's worth looking at from someone with more experience with the
repo
2. for some of the cases that I fixed I'm not sure if I should change
the code to always return `/` or should change the test to adapt `/` in
linux and `\` in windows, so please if I mistaken one of them let me
know and I will do it the other way around but I believe it should be
fine since in windows `foo/bar` does work as a path still
In order to use `nx release` you must run `nx add @nx/js`. However, the
init generator will add Prettier and `tsconfig.base.json` files by
default, which is not what the user wants.
This PR adds two options:
- `addTsConfigBase` - generates `tsconfig.base.json` when `true`.
Default to`false`
- `setUpPrettier` - adds `prettier` and generates `.prettierrc` and
`.prettierignore` files when `true`. Defaults to `false`.
The programmatic `initGenerator` API defaults both options to `true` to
usages remain unaffected.
The one behavior change is if users run `nx g @nx/js:init` then the two
options default to `false`. However, since this is an internal API, the
actual usages should be through `nx add` or the programmatic API.
<!-- 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 -->
When using version plans as a versioning strategy with `nx release`,
there is no way to enforce that version plan files are created when
changing files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a new `nx release plan:check` subcommand, intended to be run in
CI (and/or potentially a git hook) which will return with exit code 1 if
touched projects are not represented in at least one version plan file
on disk.
What constitutes a touched file is shared with our `affected` logic in
other commands, with the additionally capability to be able to ignore
file patterns from consideration. This would be useful for not requiring
version plans when only documentation or spec files change, for example.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Add the `nx sync` command to run sync generators and apply changes to
bring the workspace up to date according to their logic.
- Add the `nx sync:check` command to validate that the workspace is up
to date by running the sync generators without applying the changes. It
can be used on CI as a validation check.
- Update the task runner to run the sync generators (or obtain their
state from the daemon) and prompt the user whether to apply the changes,
if any
- This is only run if the `NX_ENABLE_SYNC_GENERATORS` environment
variable is set to `'true'`
- Allow the user to configure a default value for the prompt
- Update the `@nx/js:typescript-sync` generator (keep tsconfig project
references in sync with the project graph) with misc 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 NXC-787 -->
<!-- Fixes NXC-788 -->
<!-- Fixes NXC-789 -->
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 #
<!-- 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 -->
Internal project references to files in a nested directory (e.g.,
`libs/lib1/cypress/tsconfig.json`) are not handled. They are currently
identified as external project references.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Internal project references to files in a nested directory should be
handled as such. Project references to nested projects should still be
identified as external project references.
## 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#20003
<!-- 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#23519
<!-- 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#23579
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
Angular v18.1.0 is not supported.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Angular v18.1.0 should be supported.
## 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 -->
There is no implementation for the `CreateNodesV2` API.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There should be an implementation for the `CreateNodesV2` API.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-790 -->
<!-- Fixes NXC-791 -->
Fixes #
This pull request is trying to add wasm32-wasi target support for the
nx/native
To test the build, you can run the following commands:
- `rustup target add wasm32-wasip1-threads`
- `pnpm exec napi build --release --platform --package-json-path
packages/nx/package.json --manifest-path packages/nx/Cargo.toml --js
./native-bindings.js -o packages/nx/src/native --target
wasm32-wasip1-threads`
And the wasm file will be built at
packages/nx/src/native/nx.wasm32-wasi.wasm
Blocked by:
- Support @napi-rs/cli 3.0 Cammisuli/monodon#48
- https://github.com/napi-rs/napi-rs/issues/2009
The pseudo_terminal mod is excluded on the wasm32 targets, which is as
expected.
The watch mod is excluded because of the upstream `watchexec` deps
introduced by ignore-files don't support the wasi target at this moment
(but we can improve it).
## Related Issues
Fixes https://github.com/nrwl/nx/issues/21860
Fixes https://github.com/nrwl/nx/issues/23821
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
Previously, the node executor od @nx/js did not kill spawned processes
due to not awaiting finishing of killing and infinite loop.
This fix allows for seemless running nx in docker containers with
support for signals
<!-- 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` -->
## Current Behavior
When killing nx running `@nx/js:node`, child processes are not killed
## Expected Behavior
Child processes should be killed
<!-- 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 -->
When nxViteTsPaths resolves the tmp tsconfig we create for the buildable
libs, it uses the absoluteBaseUrl of the tsconfig to when creating the
ESM matcher for resolving files.
There is no baseUrl set, therefore the absoluteBaseUrl becomes the
directory of the tmp tsconfig
This means the paths to the built artifacts are incorrect
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the workspace root, which lines up with the output locations for
built artifacts, for the baseUrl for the tmp tsconfig
## 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- remove default port for verdaccio so it can take port from config file
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/23007
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
Files are unformatted.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Files are formatted.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR ensures that `"rootDir": "."` is set in `tsconfig.base.json` is
set, or else generating libs in a standalone project will fail with and
error like this:
```
error TS5090: Non-relative paths are not allowed when 'baseUrl' is not set. Did you forget a leading './'?
```
## 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 #
Fixes a bug that resulted in returning an object instead of a string for
JS executors.
There is also a helper type introduced that triggers TS to show an error
for similar problems.
Also this PR rises the minimum prettier version from 2.7.1 to 2.8.0,
because that supports the `satisfies` TS operator.
_I had another PR for this change, but that got messed up by a rebase,
so I closed that and opened this one._
_I wrote some comments there that describe what I did and why:
https://github.com/nrwl/nx/pull/22335 ._
_Also, since I created that PR many things have changed in the master
branch which allows this PR to be even simpler._
## Current Behavior
Currently build processes fail with this error message:
The "path" argument must be of type string or an instance of Buffer or
URL. Received an instance of Object .
I am experiencing it with a NestJS project.
## Expected Behavior
Builds pass without problems.
## Related Issue(s)
https://github.com/nrwl/nx/issues/22160Fixes#22160
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
[swc config is not
required](https://swc.rs/docs/configuration/compilation#exclude)
## Current Behavior
if not configed `"exclude"` will get a error
```text
TypeError: Cannot read properties of undefined (reading 'concat')
at generateTmpSwcrc (/Users/hongxu/repos/smallfish/node_modules/@nrwl/js/src/utils/swc/inline.js:7:41)
```
## Expected Behavior
give a default value for swc exclude if nx must need it
This PR adds `withNx` function to `@nx/rollup/with-nx` so it can be used
in `rollup.config.js` to replicate what `@nx/rollup:rollup` executor
does without needing to use the executor.
e.g.
```js
// rollup.config.js
const { withNx } = require("@nx/rollup/with-nx");
module.exports = withNx(
{
main: "./src/index.ts",
outputPath: "./dist",
tsConfig: "./tsconfig.lib.json",
compiler: "babel",
external: ["react", "react-dom", "react/jsx-runtime"],
format: ["esm"],
assets: [{ input: ".", output: ".", glob: "README.md" }],
},
{
// Provide additional rollup configuration here. See: https://rollupjs.org/configuration-options
// e.g.
// output: { sourcemap: true },
}
);
```
## Notes
1. Existing `@nx/rollup:rollup` continues to encapsulate rollup options
and will not support an isolated mode.
2. Newly created JS and React libs with `--bundler=rollup` will use the
new `withNx` function and explicit `rollup.config.js`.
3. If `NX_ADD_PLUGINS=false` or `useInferencePlugins: false` is set,
then new projects will continue to use the `@nx/rollup:rollup` executor.
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
We only ever discover one version of an external dependency for the
file-map.json. This means the `@nx/dependency-checks` lint rule can
produce incorrect failures when multiple copies of a dependency exist
within a workspace.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
In the file-map.json the project specific version of a package (if
multiple exist) is preferred and therefore the lint rule produces
accurate results.
---
For example, in a repo where the root package.json has lodash@4.0.0
(which becomes `npm:lodash` on graph) and the foo project has
lodash@3.0.0:
**Before**
**After**
## Performance
`NX_ISOLATE_PLUGINS=true NX_PERF_LOGGING=true NX_DAEMON=false nx show
project nx --json false`
** Before **
Time for 'build typescript dependencies' 505.52144700009376
** After **
Time for 'build typescript dependencies' 701.247584999539
- Update `/packages/` links to `/nx-api/`
- Convert some unneeded absolute links to relative
- Remove leftover examples doc for the already removed `cypress-project`
generator
<!-- 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` -->
## 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#26126
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
npm warnings:
```
npm WARN ERESOLVE overriding peer dependency
npm WARN While resolving: @swc-node/core@1.13.1
npm WARN Found: @swc/core@1.3.107
npm WARN node_modules/@swc/core
npm WARN dev @swc/core@"~1.3.85" from the root project
npm WARN 3 more (@swc-node/register, nx, ts-node)
npm WARN
npm WARN Could not resolve dependency:
npm WARN peer @swc/core@">= 1.4.13" from @swc-node/core@1.13.1
npm WARN node_modules/@swc-node/register/node_modules/@swc-node/core
npm WARN @swc-node/core@"^1.12.0" from @swc-node/register@1.8.0
npm WARN node_modules/@swc-node/register
npm WARN
npm WARN Conflicting peer dependency: @swc/core@1.5.7
npm WARN node_modules/@swc/core
npm WARN peer @swc/core@">= 1.4.13" from @swc-node/core@1.13.1
npm WARN node_modules/@swc-node/register/node_modules/@swc-node/core
npm WARN @swc-node/core@"^1.12.0" from @swc-node/register@1.8.0
npm WARN node_modules/@swc-node/register
```
## 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 https://github.com/nrwl/nx/issues/23688
This PR adds the ability for incremental builds when using the Webpack
Plugin.
Instead of using the source library directly, you can now utilize the
output folder by utilizing the `buildLibsFromSource` option within your
webpack.config file, through `NxAppWebpackPlugin`. This means that
instead of accessing `mylib/src/index.ts`, it will access
`dist/mylib/index.js`.
This directly aligns with incremental builds as it ensures that the
build process only recompiles the source doe that has been modified
since the last build.
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
Lifecycle scripts related to publishing change the output of `npm
publish`, which mixes JSON with non-JSON content despite the `--json`
flag being set. Currently, we will error when attempting to parse the
whole thing as JSON.
The lifecycle scripts contents themselves are not shown to the user.
Additionally, during dry-run we have no choice but to print the version
that currently exists on disk, which can be confusing.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We extract and parse the JSON from the `npm publish` output, even when
it is mixed with other output. We also show the lifecycle script outputs
to the user, where applicable.
During dry-run, we replace the version in the publish output with a
placeholder to avoid confusion around what would be published.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/22925
<!-- 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` -->
## Current Behavior
Plugin's cache entries overwrite each other if multiple instances of the
same plugin are running. They also don't remember previous cache states.
## Expected Behavior
Plugin's caches grow as changes are made, and don't overwrite previous
entries.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
