<!-- 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 g @nx/remix:lib packages/foo` generates invalid package names in new
TS setup. e.g. `@acme/packages/foo`.
## Expected Behavior
The name should be valid in `package.json`.
## 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 -->
If you don't have Prettier installed, then `nx g @nx/remix:app
apps/myapp` will generate a `package.json` with trailing comma, and `npm
install` fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`package.json` should be valid without Prettier.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Add migration to remove the `tailwindConfig` option from the ng-packagr
executors, which have been unused since Angular v17. Tailwind CSS
configurations located at the project or workspace root will be picked
up automatically.
<!-- 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#29217
Add migration to remove Angular ESLint rules that were removed in v19:
- `@angular-eslint/no-host-metadata-property`
- `@angular-eslint/sort-ngmodule-metadata-arrays`
- `@angular-eslint/prefer-standalone-component`
See Angular ESLint v19 changelog for reference:
https://github.com/angular-eslint/angular-eslint/blob/main/CHANGELOG.md#1900-2024-11-29
<!-- 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 -->
When Nx is unable to connect to the DB, nothing works and the user needs
to run `nx reset` to remove the db file.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When Nx is unable to connect to the DB, the db is destroyed and
recreated automatically within the same command.
## 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 -->
This repo uses Nx `20.2.0-beta.3`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.2.0-beta.7`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
The `rollup.config.js` file will be resolved as ESM if the closest
`package.json` has `type: 'module`. This causes an error when computing
the project graph and when reading the file for builds.
```
Original error: require is not defined in ES module scope, you can use import instead
```
<!-- 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. -->
This PR also updates the output directory to `{projectRoot}/dist` for
the new TS setup.
## Current Behavior
`nx g @nx/react:lib --bundler=rollup` has an error due to Node
resolution
## Expected Behavior
`nx g @nx/react:lib --bundler=rollup` works out of the box
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29193, #[29195](https://github.com/nrwl/nx/issues/29195)
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@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 -->
## 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#29139
## Current Behavior
Our Module Federation support across Angular and React contains Host and
Remote generators.
The module-federation.io docs have started to shift towards Consumer and
Producer terminology for better translation of meanings across
languages.
## Expected Behavior
To stay consistent with official terminology, add aliases for the host
and remote generators to allow for the new terminology. i.e. host ->
consumer, remote -> producer.
Therefore the following are all valid
```shell
nx g host shell --remotes=remote1
nx g host shell --producers=producer1
nx g consumer shell --remotes=remote1
nx g consumer shell --producers=remote1
nx g remote remote1 --host=shell
nx g remote remote1 --consumer=shell
nx g producer producer1 --host=shell
nx g producer producer1 --consumer=shell
```
Update the npm workspaces tutorial to reflect the changes made in
https://github.com/nrwl/nx/pull/29149.
Updated doc:
https://nx-dev-git-docs-nx-sync-terminal-output-nrwl.vercel.app/getting-started/tutorials/npm-workspaces-tutorial
<!-- 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 -->
Resolving custom plugins to their paths to be loaded involves loading
our default plugins. When plugin isolation, this loads the default
plugins for each and every plugin worker.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Resolution of the plugins is the same and easily serializable to send to
the worker. Resolving plugins on the main thread allows Nx to reuse the
default plugins and decrease the memory usage greatly.
## 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 #
<!-- 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 mock for this test is not actually mocking the function being used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The function being used is getting mocked.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Update the `@nx/js:typescript-sync` sync generator to produce the
updated project references in multiple lines. This improves the
formatting of the generated project references when not using Prettier.
<!-- 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#29165
## Current Behavior
On Windows, when packageManager=pnpm, `create-nx-workspace` fails due to
an issue with `child_process.spawn`.
Using `spawn`, the `@nx/workspace:preset` generator is executed twice
when `packageManager=pnpm`, causing the overall create-nx-workspace flow
to fail, even though most things have been set up correctly to that
point.
Using `fork` has shown success.
## Expected Behavior
Running `create-nx-workspace --packageManager=pnpm` should work on
Windows
## Fixes
Fixes#20222Fixes#27270Fixes#22917Fixes#22312Fixes#28710Fixes#28289Fixes#28235Fixes#22383Fixes#21742Fixes#20270
<!-- 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 -->
This PR fixes several issues:
1. Affected loaded plugins again.
2. `package-json` plugin takes a while and is loaded often.
3. Performance logging was not showing up properly.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
1. Affected does not load plugins again.
2. `package-json` plugin utilizes a cache so that it is fast even when
it is loaded often.
3. Performance logging shows up properly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@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 -->
## 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#28316
- Add migration to disable the `@angular-eslint/prefer-standalone` rule
when it's not already set. This prevents a breaking change due to the
[rule being promoted to the recommended rules in
v19](https://github.com/angular-eslint/angular-eslint/commit/8dfdc4f4d4b2a0b23f91aeb7ef14fa384bec3cec).
- Update the `@nx/angular` package peer dependencies range to drop
Angular v16 and include Angular v20.
<!-- 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#29163
## Current Behavior
The logic for the `module-federation-dev-server` and
`module-federation-ssr-dev-server` is duplicated across Angular, React
and Rspack.
The majority of this logic is the same, and the duplication causes an
increased maintenance tax.
## Expected Behavior
Move the logic into a utility that is exposed from
`@nx/module-federation`.
Included a new FAQ entry to clarify the existence and conditions of the
Pro plan for existing users, which is no longer available to new users.
Added a link to this FAQ section from the pricing display page to help
users easily find information about the Pro plan. Updated HTML in the
FAQ section with an additional class for better scrolling behavior.
---------
Co-authored-by: Juri Strumpflohner <juri.strumpflohner@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 -->
the glob pattern in the e2e-ci example is incorrect for nested
directories example mentioned.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
when using nested directories the **/** pattern is needed, so the
example was incorrect
it's also confusing why something wouldn't work, so added more info as
to the different common glob patterns (`**/*`, `**/**`) to be more clear
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@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
<!-- 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 #
This PR updates app and lib generators in the following packages such
that they will generate files with the TS solution setup if it is
detected.
- `@nx/react`
- `@nx/next`
- `@nx/remix`
- `@nx/expo`
- `@nx/react-native`
React apps and libs will be linked using npm/pnpm/yarn/bun workspaces
feature rather than through tsconfig paths. This means that local
aliases like `@/` will work with Next.js and Remix apps.
Note: This will be behind `--workspaces` flag when using `npx
create-nx-workspace` and choosing React stack. If you use the None/TS
stack then adding plugins like `nx add @nx/react` then generating apps,
it will automatically pick up the new TS solution setup.
<!-- 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
React generators are not compatible with TS solution setup (i.e.
workspaces + TS project references).
## Expected Behavior
React generators work with new TS solution setup (Plain, Next.js, Remix,
Expo, React Native).
## Related Issue(s)
#28322
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Co-authored-by: Nicholas Cunningham <ndcunningham@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 -->
## 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#18243
<!-- 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 we generate a Nest application and run the serve target
with development configuration the `node-env` is set to `production`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running the serve target in `development` should build the artifacts as
`development` so they can be served correctly.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26761
- Update artifact generator schemas:
- Clarify `path` is the artifact file path relative to the current
working directory
- Clarify `name` is the artifact symbol name
- Remove prompt for `name` and remove it from the important options
(won't be displayed by default in Nx Console generation UI, it will be
part of the collapsed options) given that most of the time, it's meant
to match the filename (last segment of the `path`)
- Remove some leftover options related to the name and path formats that
were previously missed
- Fix an issue with NestJS generators
- Fix an issue with Next `page` 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` -->
<!-- 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
Missing documentation on how to use Playwright's `--project` argument
with Nx.
Because Nx also has a `--project` argument, passing it to the command
like `nx e2e app --project=firefox` will result in the `--project` being
stripped from the command that is sent to Playwright.
## Expected Behavior
The fix is simple enough, change the command to be `nx e2e app --
--project=firefox` to ensure the argument is forwarded correctly to
Playwright.
Add some information to the Playwright plugin's overview documentation
to explain this.
## Related Issue(s)
Fixes#26965
## Current Behavior
SSR with Module Federation frequently encounters issues related to the
eager resolution of shared packages.
This has resulted in numerous erroneous behaviours including but not
limited to:
- Failure to start server
- Failure to resolve remotes
- Failure to server render remotes
## Expected Behavior
Using the `'hoisted'` runtime provided by MF 2.0, we can ensure that SSR
for Module Federation runs in an async environment, removing the issues
surrounding eager consumption and resolution of shared modules.
In testing, this has fixed the issues outlined above
## Related Issue(s)
Fixes#27000Fixes#27964
<!-- 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#28960
<!-- 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 we run the nest generators (interceptor, resource, guard etc...) it
tends to duplicate the path and leads to unexpected folder creations.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It should generate in the path provided.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29076
<!-- 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 -->
The deprecated sync API for getting powerpack license information is
used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The new async API for getting powerpack license information is used if
it is available. If not, it uses the sync API.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Replaced the URL in the webinar signup link with a shortened version to simplify the href. Removed the onClick event handler for tracking the webinar sign-up click event.
Introduce the `WebinarNotifier` component and integrate it within the app. This helps in promoting the upcoming webinars to users by displaying a notification banner with details and a signup link.
<!-- 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, `create-nx-workspace` links to tutorials which in most cases,
users are in the middle of doing or have already done in the past.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Rather than tutorials, `create-nx-workspace` will welcome users to the
Nx community and give them ways to show their appreciation, stay up to
date, and chat about Nx.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The React + Angular migrations intended to update the path for the
`ModuleFederationConfig` imports in webpack and rspack config files will
fail on externalNodes in the project graph that have `@nx/webpack` or
`@nx/rspack` listed as a dependency.
## Expected Behavior
If the dependency is discovered in an `externalNode` we should skip that
node, instead of continuing with the migration.
<!-- 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 -->
When we run the ngrx-root-store generator on a MFe host app it assumes
`app.module.ts` is created.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We should check if `app.module.ts` exists first, then fall back if not.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28970
<!-- 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 we create a new Next.js app it checks if `tsconfig.app.json` exists
else it throws an error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It should check for `tsconfig.json` instead of `tsconfig.app.json`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29035
## Current Behavior
Current default for outputHashing is set to 'none'.
This means that both executor and plugin usage will output file names
that will not bust browser cache.
## Expected Behavior
Set default for `outputHashing` to 'all' to ensure all outputted files
are hashed allowing for cache busting.
## Related Issue(s)
Fixes#29011
<!-- 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 -->
This repo uses Nx `20.2.0-beta.2`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.2.0-beta.3`.
## 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 -->
Current projects are added to excludes of rspack plugin.
Init is also not detecting rspack workspaces
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure excludes is not being set up when generating new apps as they are
resilient to project graph creation now.
Init should detect projects correctly
## 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 -->
The `withModuleFederation` helper currently lives in the `@nx/rspack`
package.
With the goal of consolidating the module federation support into a
single package, this introduces a divergence in where module-federation
support lies
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Move `withModuleFederation` helper for angular into the
`@nx/module-federation` package, exposed via
`@nx/module-federation/rspack`.
Adds a migration to migrate existing projects to use the new package
## 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
-->
Add documentation for how assignment rules feature works with Nx Cloud.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
Co-authored-by: Isaac Mann <isaacplmann@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 -->
The `withModuleFederation` helper currently lives in the `@nx/react`
package.
With the goal of consolidating the module federation support into a
single package, this introduces a divergence in where module-federation
support lies
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Move `withModuleFederation` helper for angular into the
`@nx/module-federation` package, exposed via
`@nx/module-federation/webpack`.
Adds a migration to migrate existing projects to use the new package
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
WIP
<!-- 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 #
---------
Co-authored-by: Colum Ferry <cferry09@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 -->
## 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 -->
The `withModuleFederation` helper currently lives in the `@nx/angular`
package.
With the goal of consolidating the module federation support into a
single package, this introduces a divergence in where module-federation
support lies
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Move `withModuleFederation` helper for angular into the
`@nx/module-federation` package, exposed via
`@nx/module-federation/angular`.
Adds a migration to migrate existing projects to use the new package
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- feat(module-federation): migrate to latest
- feat(rspack): add convert to legacy plugin
- feat(rspack): add convert-to-inferred 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` -->
<!-- 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 -->
Our current rspack configs rely on executor usage.
But there is no automated method to convert the config to use inferred
targets
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add convert-to-inferred generator
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Without this fix, the regular expression would replace other modules
that have old module name in their name.
E.g. `MapIconModule` contains `IconModule` and when migrating
`IconModule`, the migration would wrongfully update `MapIconModule` to
`MapIconComponent`.
## Expected Behavior
Migration changes only the Module/Component that's being migrated.
<!-- 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 -->
We're currently installing Rspack 1.0.5. The latest is 1.1.2.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure we install the latest for users, and migrate existing users to
latest
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
improvement the typo and the tutorial for beginners
<!-- 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` -->
`yarn global` was removed in modern versions of yarn, this adds a hint
that it is only available in v1 of it.
<!-- 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. -->
<!-- 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 a runtime resolve bug in older versions of Module Federation
2.0 Packages.
It is fixed in v0.7.6
We're currently installing 0.6.9
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Migrate to the latest version of MF2.0 packages
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
The `eslint` version is causing errors like:
```
Error while loading rule '@typescript-eslint/no-unused-expressions': Cannot read properties of undefined (reading 'allowShortCircuit')
```
This is because we are installing both eslint 8 and 9 to the workspace,
which are not compatible. We shouldn't need to add `eslint`,
`typescript`, `vite` and other tooling to the app's package.json since
they should following single version policy by default and be installed
at the root.
Note: This is only an issue when you enable workspaces.
<!-- 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 #
While following the docs to preserve git histories I ran into some
issues.
This update hopefully makes sure any future readers can complete the
outlined procedure successfully
<!--
_[Please make sure you have read the submission guidelines before
posting an
PR](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## nx-foundry
<!--
Describe what your plugin is and what is its goal or issues it
addresses. If you don't provide a description, we will not merge your
PR.
Is it focused on a technology, tooling or behaviour? Does the plugin
provide generators, executors or graph support?
Do you know who is already using the plugin? Mention who is the author
of the plugin.
-->
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
We're using Playwright by default, but the e2e test is ensuring Cypress
installation.
<!-- 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 #
- feat(rspack): add NxAppRspackPlugin
- feat(rspack): add NxReactRspackPlugin
<!-- 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 -->
We currently do not have rspack plugins to encapsulate our app, web and
react support for Rspack. This leads to issues with defining configs
that are supported by Crystal
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add and expose two plugins, `NxAppRspackPlugin` and
`NxReactRspackPlugin`, to support building configs that are supported by
crystal
## 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 `buildLibsFromSource` option is not being used. So even
if the user sets it to `'buildLibsFromSource': false` it will not be
updated.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `buildLibsFromSource` should be supported.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
There is an issue with Rspack that requires the baseUrl to be set in the
generated tsconfig.
Fixes #
There is a conflict between ESLint and Prettier rules, which causes
incorrect formatting behavior.
Reordering the config so that `eslint-config-prettier` is applied last
ensures proper rule overrides and resolves conflicts with Prettier.
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@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 -->
## 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 #
<!-- 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 -->
`@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` are
left at old versions after converting to flat config.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` are
removed when converting to flat config.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- feat(module-federation): consolidate module federation utils into
module-federation package
- chore(module-federation): fix tests and linting
<!-- 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 -->
Our current support for Module Federation relies on utilities that are
spread and duplicated across the `@nx/webpack` package and the
`@nx/rspack` package.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Now that we have a `@nx/module-federation` package, dedupe the utils and
consolidate them into a single package
## Todo
- [x] Migrations for React + Angular to install `@nx/module-federation`
and point `ModuleFederationConfig` export to that package from
webpack.config and rspack.config files
<!-- 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
N/A
## Expected Behavior
Add new recipe on the CI section about using CIPE Affected Project Graph
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@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 -->
I got this error locally, I think it is because @storybook/test-runner
is incompatible with storybook version
https://github.com/storybookjs/test-runner/issues/505
<img width="1147" alt="Screenshot 2024-11-15 at 12 22 13 PM"
src="https://github.com/user-attachments/assets/e2a9f4c9-e784-4946-8677-b60b62ff36ef">
from https://github.com/storybookjs/test-runner#storybook-compatibility
storybook ^8.2.0 should use @storybook/test-runner ^0.19.0
## 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 -->
This repo uses Nx `20.1.0-beta.3`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.2.0-beta.2`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Integrate a new MinIO icon into the UI icons library and Nx Powerpack features. Adjust the layout and styling of the Nx Powerpack features to improve flexibility and responsiveness.
<!-- 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 using NX_PLUGIN_NO_TIMEOUTS there is not a reference counted as the
setTimeout is not called. This could theoretically result in node
killing the process if the only thing that was keeping it alive was the
plugin call.
## Expected Behavior
A ref is tracked either way to prevent the process from getting dropped.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
avaiable -> available
<!-- 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 #
It renames the ResourceClasses component to CreditPricing and updates its references throughout the application. It also includes additional non-compute pricing information and a more detailed breakdown of credit costs associated with various CI/CD operations for Nx Cloud.
<!-- 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 create fresh angular or react integrated project no eslint
extension out of the box. Few years ago I fill the issue
https://github.com/nrwl/nx/issues/7047 about deprecated tslint extension
looks like that has been deleted but without change to eslint extension
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
when I create angular / react project eslint extension should be added
to recommended vscode extensions
## 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 -->
Setting global styles as entry points in rspack causes HMR to fail
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Rspack does not require styles to be set as entrypoints as it will be
handled by the CssExtractPlugin.
Remove the entries
## 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 #
<!-- 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 navigating directly to a route that renders a portion of a remote
app, SSR was not correctly server rendering the remote portion.
This was because of the output type provided to rspack and MFP
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure commonjs-module is set as output type for MF with SSR
## 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 #
This PR brings the rspack executor `@nx/rspack:rspack` inline with
webpack.
It also prepares the executor to be used with the soon to be implemented
`NxRspackAppPlugin` so that we can support executor and inferred
targets.
Implicit dependencies are not referenced in code and therefore TSC
incremental builds are not applicable.
## Current Behavior
A project using the `@nx/js:tsc` executor will fail to build if it has
implicit dependencies on projects which do not use the `@nx/js:tsc`
executor.
To reproduce:
* Clone https://github.com/cogwirrel/nx-tsc-batch-implicit-deps-example
* `pnpm i && pnpm nx run-many --target build --batch --all`
## Expected Behavior
- Implicit dependencies that do not use the `@nx/js:tsc` executor are
permitted. For example, a TypeScript project may implicitly depend on a
Python project, but the TypeScript project should still be buildable in
batch mode.
- Projects using the `@nx/js:tsc` executor will still fail to build if
they have explicit dependencies on projects which do not use the
`@nx/js:tsc` executor.
Tested by publishing to the local registry, upgrading the [example
repo](https://github.com/cogwirrel/nx-tsc-batch-implicit-deps-example)
to use my local version, and built successfully in batch mode.
## Related Issue(s)
Fixes#28839
Fix type esbuildMidleware. Should be esbuildMiddleware
closed#28774
<!-- 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. -->
I was looking at the source to understand how `sourceRoot` is used and
saw it was referenced in the eslint-plugin but it turns out it isn't
actually used
## Current Behavior
This parameter isn't used
## Expected Behavior
The parameter should be removed
<!-- 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 -->
`@nx/module-federation` cannot be published because it doesn't have
public publish access
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`@nx/module-federation` can be published.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…d dependency targets
<!-- 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 -->
Dummy tasks are given an ID containing the parent task's target.
Multiple parent tasks can create the same dummy task which overrides
other dummy tasks.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Dummy tasks are given an ID containing the dependency and the parent
tasks's name. This means different parent tasks will create different
dummy tasks instead of overriding other ones.
## 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 -->
Running `nx-dev:build-base` takes a lot of memory and particularly if it
is run after `test` tasks, it will cause agents to run out of memory.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
I don't have a fix for the task taking up a lot of memory... but I do
have a fix which will alleviate the issue. I've split up `test` tasks
and `nx-dev:build-base` to run on different agents.
We should still look into how to make this task not take up so much
memory. What I've learned is that prerendering pages for `nx-dev` has a
memory leak so we should investigate what during prerendering a page is
not cleaned up properly.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Socket paths have quite a short allowed length. It's easy to hit the
maximum.
## Expected Behavior
We should exceed the maximum as rarely as possible. By lowering the
workspacePath hash portion, we reduce the chances of exceeding the path.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27725
<!-- 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#28894
<!-- 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 -->
Rspack w/ SWC requires setting `runtime: 'automatic'` to allow React
global to be set in browser
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Set `runtime: 'automatic'`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Add `poll` option to the ng-packagr executors. This change was made
upstream for Angular v18, but it was missed on the Nx executors.
<!-- 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 #
<!-- 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 #
<!-- 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 -->
`withNx` from `@nx/rspack` is not reflective of what `@nx/webpack` does.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bring `withNx` in line with `@nx/webpack`
## Notes
<!-- 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 unitTestRunner is set to none, spec files are still generated
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
SkipTests when unit test runner set to none
## 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 -->
Nx Cloud Heartbeat was disabled temporarily.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx Cloud Heartbeat is enabled again
## 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 -->
We do not currently have an `@nx/module-federation` package to house the
shared executors and utils for Module Federation across `Webpack`,
`Rspack` and `Angular`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Create a single package to store the Module Federation capabilities
within Nx
## 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 #
<!-- 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 -->
`nx/src/command-line/nx-commands` takes ~88-91ms on my machine to
require which needs to happen for every single Nx command.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx/src/command-line/nx-commands` takes ~30-33ms on my machine to
require.
## 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 #
<!-- 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 -->
Latest migrations for Remix will install verions `2.13.1`.
The latest version of remix packages is `2.14`
We also were not updating auxillary @remix-run/* packages, including
server adapters.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure version `2.14` is installed
Ensure auxillary packages are migrated
## 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 #
<!-- 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 current next-env.d.ts is outdated so when you run `nx build` Next.js
would update the `next-env.d.ts` file which would trigger git changes
due to the outdated content.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When you run `nx build` the `next-env.d.ts` ideally should not update
from what is generated OOTB.
## 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 -->
The unix dotfiles are incompatible with posix dotfiles. Having the 2
modes being switched between yields weird errors.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Posix dotfiles seem fine for what we're doing so Nx will stick with that
mode for all cases.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
ViewOnGraph button doesn't work until you open the accordion
## Expected Behavior
ViewOnGraph button should direct to graph without the need to open the
accordion first.
I believe it's better from the UX prespective that user shouldn't click
twice on the same button to fire its action.
<!-- 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 -->
Generators adding plugins to `nx.json` can modify projects'
`package.json` files with some JSON serialization changes even though
there are no actual changes and prettier is not installed, so they
shouldn't be formatted.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Generators adding plugins to `nx.json` should not modify projects'
`package.json` files with JSON serialization changes when there are no
actual changes to make and prettier is not installed.
## 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 -->
This repo uses Nx `20.1.0-beta.2`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.1.0-beta.3`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Currently we send a message to the plugin to shutdown when the parent
process either dies or is ready for them to shutdown. This works, but
fails when the host process is killed with a sigterm as the cleanup
can't run. This PR shifts the strategy such that whenever the one and
only socket connection ends, the plugin automatically shuts down
<!-- 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 way VS Code / Nx Console starts the daemon makes the ci info rust
crate believe that the daemon process is running in CI. This starts the
database using the unix dotfile... which causes issues
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The ci info rust crate is not used, we have our own logic which is
identical to the JS logic we have.
## 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 -->
Task dependencies were getting conflated between different targets. If
nx runs lint tasks which depend on TaskA and test tasks which depend on
TaskB... the task graph was reporting that both lint and test tasks
depended on TaskA.. which is incorrect.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Task dependencies are not conflated between different targets. If lint
tasks depend on TaskA and test tasks depend on TaskB.. then... lint
tasks will truly depend on TaskA and test tasks will truly depend on
TaskB properly.
## 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 -->
This repo uses Nx 20.0.7
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses nx 20.1.0-beta.0
## 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 #
<!-- 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 -->
`withWeb` from `@nx/rspack` is not reflective of what `@nx/webpack`
does.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Bring `withWeb` in line with `@nx/webpack`
## 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 -->
DB connections are sometimes left open.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
DB connections are closed when the process exits
## 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 you create a new project using the new ts setup to support ts
project references jest does not work out of the box due to
incompatibility with the module being set inside tsconfig to `nodenext`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Jest should work out of the box with our current setup
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…login/logout
<!-- 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 you call `nx login` and `nx logout`, we did not pass in import
paths to node modules so the displayed messages for each command were
just raw text.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When you call `login` or `logout`, you get formatting on the command
output.
## 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 #
<!-- 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 -->
- getNonDummyDeps is a recursive function. we pass in cycle arg to this
function. currently we end the recursion when the task is in a cycle.
however, currently there is an error "Maximum call stack size". i
suspect this recursion is not being ended because the cycle is not
detected when there are multiple cycles.
- add a function to get all cycles of the graph
- also, change getNonDummyDeps to track a list of seen tasks, even with
no cycle detected, this function will not run into infinite recursion
## 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/28788
<!-- 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/27736 and
https://github.com/nrwl/nx/issues/27736
<!-- 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 #
<!-- 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 `@nx/rspack:rspack` executor had listed other properties as required
in the schema that could have been set by the rspack config.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Make those properties optional and add validation after config is
resolved
## 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 -->
We switched to using `loadConfigFile` from `@nx/devkit` to load Nuxt
Config files when plugins were not isolated.
However, they are now, so we can use `loadNuxtConfig` again.
The effect of using `loadConfigFile` paired with Nuxt's auto-imports
resulted in inconsistent failures.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use `loadNuxtConfig` when `NX_ISOLATE_PLUGINS=true`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28506Fixes#28374
<!-- 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 -->
We currently have validation for the `main` property in the `executor`
schema, however, this value could be defined in the `rspack.config`
file.
This can cause an inaccurate schema validation error
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
After loading the config file and applying the executor options, run
validation over the config.
## 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 running postinstall with Nx, we create a files archive file. When
there are multiple versions of nx installed, the post install would run
for all versions. This causes issues where one version might overwrite
the archive files while another version is writing to the same location.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `setupWorkspaceContext` is now only ran when we detect that it is
the main nx package. This also makes the creation of the archive file
more atomic so that we dont overwrite files while its being written by
other processes
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
closes#28291
<!-- 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 -->
eslint 9 support --quiet param for not run warn rules, but nx not pass
that param directly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
nx executor should pass --quiet directly to eslint
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28291
This can help us debug issues that come up during these tests.
<!-- 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 #
<!-- 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 `target` property is currently required by the `@nx/rspack:rspack`
executor, but is not by the `@nx/webpack:webpack` executor.
This can make migrating between the two a little more difficult.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Target should be handled by Nx's `withWeb` helper or set intentionally
by the user in their `rspack.config` file.
## 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 https://github.com/nrwl/nx/issues/26805
<!-- 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 `createNodesV2`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There should be an implementation for `createNodesV2`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
closed#28615
<!-- 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#28615
<!-- 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 Next.js version in @nx/next is set to 14.0.3, which lacks
the latest features and improvements available in the 14.2.16 release.
Additionally, the current version has known vulnerabilities:
[GHSA-gp8f-8m3g-qvj9](https://github.com/advisories/GHSA-gp8f-8m3g-qvj9):
Cache Poisoning vulnerability in Next.js (versions before 14.1.0)
[GHSA-g77x-44xx-532m](https://github.com/advisories/GHSA-g77x-44xx-532m):
Denial of Service (DoS) condition in Next.js image optimization
(versions before 14.2.0)
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
With this PR, the Next.js version in @nx/next is updated to 14.2.16,
addressing the listed vulnerabilities and bringing in the latest
features and bug fixes.
## 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 -->
Module Federation tests take ~21-25mins
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Module Federation tests take ~11-13mins
## 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 #
<!-- 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#28561
<!-- 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/28121
<!-- 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/28451
<!-- 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#28541
<!-- 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 #
…e2e tests
<!-- 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 -->
We currently have hombrewed support for Dynamic Module Federation.
However, Module Federation 2.0 comes with more powerful helpers to
handle dynamic federation.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
For new host projects using dynamic federation, use the Module
Federation Runtime.
For existing hosts using Nx's dynamic federation, continue to use it
when adding new remotes to it.
Deprecate Nx's dynamic federation helpers with intended removal in Nx 22
### Example Screenshot of Deprecation Message
<img width="810" alt="image"
src="https://github.com/user-attachments/assets/6c6a9504-6d89-497b-9259-9272b3f47276">
## 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 -->
With Webpack, we setup DefinePlugin to define `NX_PUBLIC` env vars.
This was not replicated in Rspack
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure `NX_PUBLIC` env vars are included in the DefinePlugin
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28720
<!-- 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 -->
- we introduce a feature to allow circular project dependencies to
execute tasks in pr https://github.com/nrwl/nx/pull/28227/files
- for this feature, we introduce the concept of dummy task as a
temporary placeholder so we can still generate a task graph even if
dependencies contain circular dependencies
- however, it does not handle a task graph of multiple dummy task deps.
for example:
lib1 -> lib2 -> lib3 -> lib4
if we got task graph like:
lib1:build -> lib2:dummy
lib2:dummy -> lib3:dummy
lib3:dummy -> lib4:rebuild
currently, it does not create a dependency between
lib1:build->lib4:prebuild
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
it should link the dependency when it contains multiple level of
depending on dummy tasks
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/28599 and
https://github.com/nrwl/nx/issues/28380
This PR fixes an issue where `create-nx-workspace` with Next.js preset
generates with Jest spec files, but does not install
`@testing-library/react` correctly due to not checking the normalized
schema file.
<!-- 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 #
closes: #28703
<!-- 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 #
This PR adds a new `disableJestRuntime` option to `@nx/jest/plugin`. By
setting this to `true`, the inference plugin will not use `jest-config`
and `jest-runtime` to retrieve `outputs`, nor matching spec files when
`ciTargetName` is used. Instead, we'll use our own config loader and
glob/matcher to get both values for the inferred targets.
This speeds up computation quite a bit. With a large monorepo (800
projects, 75K files), the computation goes from 2m 41s to 35s, or ~78%
time reduction.
NOTE: This has no effect on existing projects and needs to be opted
into.
<!-- 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 #
This PR updates `@nx/playwright/plugin` to create non-conflicting
outputs for atomized tasks.
<!-- 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
Outputs from `outputDir` and reporters are the same for each atomized
task, which results in missing outputs.
## Expected Behavior
All outputs should be captured and cached correctly.
## 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 #
---------
Co-authored-by: Isaac Mann <isaacplmann@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
<!-- 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 #
---------
Co-authored-by: Isaac Mann <isaacplmann@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
<!-- This is the behavior we have today -->
Currently, if you are using Next.js 15 have SVGR enabled via `WithNx`
and are using turbopack. You could potentially have issues loading your
svg. This happens because of how webpack imports svg and not having an
additional configuration for turbopack (currently it is under the
experimental option).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Moving forward, we can call this out and deprecate the option to be
removed in Nx 21. As such should you need to use SVGs it is recommended
to do so manually. Something similar to [this
comment](https://github.com/vercel/turborepo/issues/4832#issuecomment-1751407444).
## 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 #
<!-- 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#28572
<!-- 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 -->
Using the viteConfigGenerator leads to build and serve targets being
overriden
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the `vitestGenerator` to only add the test target
## 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 -->
The pattern added for .gitignore is incorrect
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add the correct pattern
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28685
<!-- 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 #
Add `vite.config.mts` and `vitest.config.mts` to `vitest.workspace.ts`
and `tsconfig` files.
- Angular generator creates vite.config.mts files.
- Users might also use mts files.
<!-- 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 -->
`vite.config.mts` and `vitest.config.mts` were ignored in
`vitest.workspace.ts`.
They were not included in the tsconfig files neither.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The opposite 😊
---------
Co-authored-by: Colum Ferry <cferry09@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 the workspace has `eslint.config.cjs` at the root, generation of
new lint projects currently does not check for it correctly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure utils continue to work as expected when `eslint.config.cjs` is
detected at the workspaceRoot
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28214
- This adds `vitest` option to `unitTestRunner` for Angular generators.
- This **does not** add vitest option to `create-nx-workspace` but I
think we should provide this as an option in the future. Please let me
know if you wantme to add this here or as a future feature.
---------
Co-authored-by: Colum Ferry <cferry09@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
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Benjamin Cabanes <3447705+bcabanes@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
<!-- 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 #
This PR removes logic where we handle both `@nx/` and `@nrwl/` scope.
The latter scope has stopped being published in v20, and are no longer
relevant.
- Cleans up e2e
- Removes references to `@nrwl/` scope in our generators and executors
- Removes `@nrwl/` from `nx/package.json` `packageGroup`
- Cleans up documentation quality script
<!-- 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#28577
<!-- 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 -->
We currently still generate Remix Classic applications
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We should generate Remix Vite applications
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When using Nest.js in combination with [decorator
metadata](https://docs.nestjs.com/fundamentals/execution-context#reflection-and-metadata),
the class names and handlers become mangled/compressed causing them to
lose the reference to the correct class/handler name.
## Expected Behavior
The decorator metadata works as intended.
## Approach
This PR implements a custom instance of the
`SwcJsMinimizerRspackPlugin`, where the setting is modified to keep
original class and function names from the `compress` and `mangle`
options.
## Related
I've opened a related PR on the rspack-examples repository:
https://github.com/rspack-contrib/rspack-examples/pull/158
<!-- 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 #
Update the `@nx/js:setup-build` and the generators it depends on to
support the new TS setup with project references.
<!-- 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 -->
The switch from `DefinPlugin` to `EnvironmentPlugin` did not account for
`production`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure `production` is accounted for and set as expected
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28584
<!-- 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 -->
After the switch to use `resolveConfig` we failed to set the value for
`NODE_ENV` which is an argument to the function.
This means it always defaulted to development.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure `NODE_ENV` is set as expected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28584
<!-- 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 `@nx/rspack:rspack` executor supports `baseHref` as an option, but
we do not set it in the `rspack.HtmlRspackPlugin`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure if `baseHref` is set, we pass it to `rspack.HtmlRspackPlugin`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28455
<!-- 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 #
<!-- 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 -->
Currently we use `<%= style %>` to set the style file extension in the
`main.tsx` template file.
This is incorrect when `style=tailwind`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If `options.style=tailwind` update the `templateVariables` that are used
to set `style=css`
## 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 -->
Docs show incorrect regex pattern for valid MF remote names
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Docs show correct regex pattern for valid MF remote names
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28558
This change speeds up Nx Cloud runs by not orchestrating cache hits for
lint tasks.
<!-- 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
-->
replace localhost with options. listenAddress
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/28314
<!-- 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/28301
<!-- 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. -->
this pr is a follow up to https://github.com/nrwl/nx/pull/26033.
for function `createTaskGraph`, it should not accept
`defaultDependencyConfigs`, it should be `extraTargetDependencies`.
## Current Behavior
<!-- This is the behavior we have today -->
this caused an issue where the task graph shows that 2 tasks depend on
each other; however, when actually running, it does not.
## 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/26929
<!-- 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 -->
Personal access token blog post appears twice
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Personal access token blog post appears once
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR removes migrations that are unused in our packages.
Other changes:
- Update the `remove-migrations` generator to remove all files inside
the migration directory, rather than just the implementation, spec file,
and `__snapshots__` directory. There were some helpers that were not
removed due to this problem.
- Add a check to the `assertValidMigrationPaths` test util (used in
`migrations.spec.ts` test files) to ensure that all paths inside
`./src/migrations` are included in `migrations.json` file. There were a
few migrations missing in the `@nx/expo` package, and we never run them
nor cleaned them up.
**Note:** This has no effect on users and is purely a clean-up.
## 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 #
- Updates workspace:ci-workflow generator to disable task distribution
by default
- Updates gradle:ci-workflow generator to disable task distribution by
default
- Updates all tutorials to reflect the new generator and adds a line
explaining how to enable task distribution
<!-- 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 -->
We do not have an automated method for people to switch to rspack from
webpack applications
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We should have a generator that will convert webpack application
projects to use rspack
## 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#28191
<!-- 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 directory is workspace root, when walking through the directory, it
will include the directory root path, then will strip prefix, it will be
empty string. it will return "*" as a found path.
- When copying "*", it will run into a recursive loop because it will
try to copy the walkspace root with node_modules into
node_modules/.cache/nx
## 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/28393
<!-- 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 #
removed the webpack-sources import and replaced it with the sources
export from rspack
<!-- 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 -->
`@nx/rspack` uses `webpack-sources` which is not listed as dependency.
The issue originated in PR #27676 but i decided to split it out. I also
opened #28225 to add the dependency-check rule for rspack.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`@nx/rspack` uses the reexport from `@rspack/core`
https://rspack.dev/api/javascript-api/#sources-object
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
#28225#27676
<!-- 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, we are using `createNodes` API which should be deprecated in
favour of `createNodesV2`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We should be using `createNodesV2` instead of `createNodes`.
## 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 -->
As part of the work to normalize `-` in MF project names for Federation,
setting the NX_MF_DEV_REMOTES env var was missed.
This causes issues with the RuntimeLibraryControlPlugin
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remote names should be normalized correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28497
<!-- 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 you create a react rspack app when there is a `@nx/rspack/plugin`
definition in the nx.json, it causes the project graph to fail to create
nodes.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure the projects created via @nx/react:app --bundler=rspack are added
to exclude array if the plugin exists
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28464
## Current Behavior
NX Cannot read properties of undefined (reading 'trim')
TypeError: Cannot read properties of undefined (reading 'trim')
at
/path/node_modules/@expo/package-manager/build/node/NpmPackageManager.js:80:22
at Array.map ()
at NpmPackageManager.parsePackageSpecs
(/path/node_modules/@expo/package-manager/build/node/NpmPackageManager.js:79:14)
at NpmPackageManager.addAsync
(/path/node_modules/@expo/package-manager/build/node/NpmPackageManager.js:34:56)
at installPackagesAsync
(/path/node_modules/@expo/cli/build/src/install/installAsync.js:178:30)
at process.processTicksAndRejections
(node:internal/process/task_queues:105:5)
at async installAndUpdatePackageJson
(/path/node_modules/@nx/expo/src/executors/install/install.impl.js:33:5)
at async buildExecutor
(/path/node_modules/@nx/expo/src/executors/update/update.impl.js:13:9)
at async getLastValueFromAsyncIterableIterator
(/path/node_modules/nx/src/utils/async-iterator.js:15:19)
at async iteratorToProcessStatusCode
(/path/node_modules/nx/src/command-line/run/run.js:39:25)
## Expected Behavior
› Installing 1 SDK 51.0.0 compatible native module using npm
npm install
## Related Issue(s)
Fixes#28488
closed#28482, #28486
<!-- 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, `neverConnectToCloud` is set to `true`, there are still attempts
made to connect to NxCloud.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
if, `neverConnectToCloud` is set to `true`, we should not attempt to
connect to NxCloud.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
using `windowsHide: true` is causing an issue on windows: Ctrl + C
handling isn't enabled and no `SIGINT` is sent to the child process when
users exit the process. See https://github.com/nodejs/node/issues/29837
and https://github.com/nodejs/node-v0.x-archive/issues/5054 for
reference. This will cause leftover processes throughout nx.
This PR sets `windowsHide: false` everywhere except for the plugin
workers and some short-lived utils. They `spawn` child processes but
have explicit handling to make sure they kill themselves when the parent
process dies, so the missing Ctrl + C handling doesn't cause issues.
We will follow up to make sure any other culprits that still cause
windows popups (especially when used through Nx Console) are handled.
Leaving no leftover processes running is more important for now, though.
Keep in mind the underlying tooling (like vite) might have some windows
popups themselves that Nx will inherit.
## Current Behavior
build executors for expo crash when package manager pnpm and workspaces
are used
## Expected Behavior
no crashies
## Related Issue(s)
https://github.com/nrwl/nx/issues/28208Fixes#28208
## FAQ
- why not handle the `undefined` by the calling code instead
The less the calling code knows about inner workings, the better: in
this case, doing this would add the implicit dependency on "pnpm and
workspaces" to the calling code
- but it's an empty function, my performance
We call it once per user interaction.
- but still, it's an empty function
We return an `empty array` when there are no elements; we don't return
`undefined` when the array is empty and `array` when array is non-empty.
Hopefully so.
- but,
The doc also says that this function returns a function.
<!-- 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 the Vite Build Executor, we're using `loadConfigFromFile` from Vite
to get the config options.
The issue with this is that vite will not attempt to set `NODE_ENV`
which may be required by both the config file that is being loaded, and
other plugins.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use resolveConfig which does set NODE_ENV correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27627
<!-- 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, styles are not included in the main bundle by default.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Similar to webpack, styles should be included by default.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28465
<!-- 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/js:verdaccio` current call `npm config` to setup npm scopes in
global `.npmrc` file, which it's supposed to do.
However, when process is killed (using terminal exit command or any
other way), the process is killed and doesn't restore changed config.
In my case I'm changing scope to my private scope (using `scopes`
option), but after kill I need to restore manually.
## Expected Behavior
When process be killed, restore all configs that was set.
## Related Issue(s)
#28353Fixes#28353
<!-- 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 -->
When Vite's tries to handle a `.ts` config file it builds it to JS with
a `.timestamp-` suffix. These files are still picked up by Nx when they
shouldn't as it's a temp file
(https://github.com/vitejs/vite/issues/13267).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add these temp files to gitignore to prevent processing.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28371
<!-- 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 rspack plugin has no dependency-checks in place. I discovered it
while working on #27676.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/dependency-checks` eslint rule should be used.
There are a few dependencies that I don't know how to proceed with:
```
The "rspack" project uses the following packages, but they are missing from "dependencies":
- @nx/workspace
- webpack-sources
- @module-federation/sdk @nx/dependency-checks
The "@rspack/plugin-minify" package is not used by "rspack" project
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
#27676
---------
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
Co-authored-by: Colum Ferry <cferry09@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 -->
Port is not respected from `rspack.config.[jt]s` and needs to be
explicitly set in `project.json` options.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Port should be configurable via config, options, etc.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28040 (port portion)
<!-- 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 -->
```
[webpack-dev-server] WARNING
⚠ DefinePlugin:
│ Conflicting values for 'process.env.NODE_ENV' ("'development'" !== "\"development\"")
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`process.env.NODE_ENV` should resolve to `'development'` and not a
quoted value: `"'development'"`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28040 (NODE_ENV part)
<!-- 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 -->
`neverConnectToCloud` was not respected in the `isNxCloudUsed` function
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`neverConnectToCloud` is now respected
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28287
Provide a recap of features from the previous release
<!-- 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 -->
When the sql database throws a busy signal, there is no handler in nx to
try the operation again.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a handler to tell sqlite to handle the operation again, and try
up to N times.
## 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 -->
The docs specify that the react library generator supports using rspack
as a bundler option.
The react library generator does not have rspack as an option.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remove misleading docs
## 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 -->
Using `NX_NO_CLOUD` does not disable the remoteCache implementation for
Nx Cloud
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Using `NX_NO_CLOUD` will disable nx cloud remote cache
## 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 global prefix is used, there is an issue with the mapping of string
remote usage.
It selects a single character from the string rather than using the full
string
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the full string as remote name when mapping remotes
## 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 -->
We previously had a schema restriction on the characters allowed for
remote names. It was to prevent names that violated the JS spec for a
variable declaration.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure invalid project names fail error allowing the user to fix it at
generation
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28354, #28408
---------
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 running serve with Rspack, `stats: false` is being added to
`devMiddleware` preventing logs from being output to the terminal.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure logs are logged to the devServer
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28179
<!-- 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 #
<!-- 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#28046
<!-- 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 order of the `provide*` functions for NgRx matters and should
therefore be structured as such
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure `provideStore` is first provider added
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28107
<!-- 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 #
---------
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
When running nx build expo-app, the build executor copies dependencies
and devDependencies of the workspace package.json (see
copyPackageJsonAndLock function).
The build executor does not copy the resolutions object (for yarn) nor
the overrides object (for npm).
## Expected Behavior
The build executor copies the overrides object or the resolutions
object, if present in the package.json. The original project
package.json is restored after the build is completed successfully or
after it errors.
## Related Issue(s)
#28249
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 -->
Some executors using `@nx/webpack:webpack` point to a webpack config
that is exported from the `@nx/react plugin.
We do not want to try modify this.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Skip the migration if the webpack config points to the exported plugin
from @nx/react.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28377
<!-- 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 #
`npx nx serve angular-store` this would not work if the user does not
move to the directory first.
<!-- 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 #
Co-authored-by: Isaac Mann <isaacplmann@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
<!-- 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 #
---------
Co-authored-by: Jonathan Cammisuli <jon@cammisuli.ca>
<!-- 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
Using `getJestProjectsAsync` to include both `project.json` and inferred
targets can result in errors due to duplcicated paths.
You see an error like this:
```
Error: Whoops! Two projects resolved to the same config path: /Users/jack/projects/ocean/libs/nx-cloud/data-access-organization-dashboard/jest.config.ts:
Project 1: /Users/jack/projects/ocean/libs/nx-cloud/data-access-organization-dashboard/jest.config.ts
Project 2: /Users/jack/projects/ocean/libs/nx-cloud/data-access-organization-dashboard
This usually means that your "projects" config includes a directory that doesn't have any configuration recognizable by Jest. Please fix it.
at ensureNoDuplicateConfigs (/Users/jack/projects/ocean/node_modules/jest-config/build/index.js:325:13)
at readConfigs (/Users/jack/projects/ocean/node_modules/jest-config/build/index.js:474:5)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at async runCLI (/Users/jack/projects/ocean/node_modules/jest-cli/node_modules/@jest/core/build/cli/index.js:151:59)
at async Object.run (/Users/jack/projects/ocean/node_modules/jest-cli/build/run.js:130:37)
```
## Expected Behavior
Using `getJestProjectsAsync` should work and include all inferred
projects.
## 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 #
<!-- 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 -->
By default we connect all workspaces to Nx Cloud via the V2 connect
endpoint.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Certain users (on-prem or single tenant) may not have access to the V2
endpoint, and so we should fall back to V1 so as not to prevent new
workspaces from being created.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates the Jest migration so it handles both CJS and ESM format
for Jest config file. We now generate with ESM so those need to be
handled. There are four combinations:
1. `require` (CJS) with `module.export` (CJS)
2. `import` (ESM) with `export default` (ESM)
3. `require` (CJS) with `export default` (ESM)
4. `import` (ESM) with `module.export` (CJS)
(1) and (2) should cover almost all cases, and (3) and (4) are there
just in case. If the format isn't matching what we generate, then just
bail.
<!-- 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 #
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
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 -->
## 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 #
<!-- 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
DB cache is disabled by default
## Expected Behavior
DB cache is enabled by default
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
BREAKING CHANGE
<!-- 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 -->
* `@nx/devkit` supports Nx 17 - 20.
* Node 18 - 22 is supported
* `ExecutorContext.projectGraph`, `ExecutorContext.nxJsonConfiguration`,
and `ExecutorContext.projectsConfigurations` is marked as optional
because `ExecutorContext` in some versions of Nx did not have them.
* `ExecutorContext.workspace` is marked as optional because
`ExecutorContext` in some versions of Nx did not have the above
properties which contain the same information.
* `ProjectGraphNode` is deprecated.
* `NxPluginV1.processProjectGraph` was deprecated long ago and there has
been a warning since.
* `appRootPath` has been deprecated for a long time.
* `parseTargetString` had a variant that did not take either the project
graph or the executor context.
* `readNxJson` has a variant which does not take a tree. This was not
clearly deprecated.
* There are handlers to require from `@nx/` instead of `@nrwl`
* Nx tries to get a root install from `@nrwl/cli`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
* `@nx/devkit` supports Nx 19 - 21.
* Node 20 - 22 is supported
* `ExecutorContext.projectGraph`, `ExecutorContext.nxJsonConfiguration`,
and `ExecutorContext.projectsConfigurations` is marked as required
because `ExecutorContext` in Nx 19+ is guaranteed to have them.
* `ExecutorContext.workspace` is removed because the same information is
available in the above properties
* `ProjectGraphNode` is removed.
* `NxPluginV1` is no more. All plugins should be `NxPluginV2`.
* `workspaceRoot` is the replacement for `appRootPath`. `appRootPath` is
removed.
* `parseTargetString` no longer has a variant that did not take either
the project graph or the executor context.
* `readNxJson` still has a variant which does not take a tree but it's
clearly deprecated to be removed in Nx 21.
* `@nrwl` packages are no more so we don't have to redirect requires
anymore.
* `@nrwl/cli` is no more so Nx shouldn't try to get a root install there
*
## 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 -->
This repo uses Nx 19.8.0-beta.2
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 20.0.0-beta.7
## 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 #
<!-- 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 multiple plugins touch the `project > metadata` (note NOT `project
> target > metadata`), only the last plugin to run has their
`metadata.targetGroups` data present, meaning currently `targetGroups`
is clobbering instead of merging.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When multiple plugins write to `metadata.targetGroups`, that data is
merged together, so data written by all plugins is present.
## 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 -->
The database is currently opened with the following flag:
```
OpenFlags::SQLITE_OPEN_NO_MUTEX,
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The database is opened with the following flag:
```
OpenFlags::SQLITE_OPEN_FULL_MUTEX
```
This allows sqlite itself to handle multiple connections to the database
and make all writes serial.
## 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 -->
Heartbeat seems to be having issues.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Heartbeat is disabled.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Since `--preset=ts` has changed, we want to provide users with a way to
generate the older, integrated setup if they need to.
<!-- 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 #
This PR changes the root `package.json` to use a scoped name when using
`create-nx-workspace`. This was already done in most presets, but we
missed the old "package-based" setup.
e.g. These
```
create-nx-workspace acme --preset=ts
create-nx-workspace acme --preset=npm
```
Should all result in `@acme/source` being used in root `package.json`,
not `acme`. The scope will be used when generating projects if the user
doesn't pass `--importPath`.
<!-- 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, our table heading generated from markdown files `.md` are
positioned `center` while the data `td` are positioned `left`.
It doesn't look uniform and on larger tables, it can be jarring.
Examples:
- https://nx.dev/ci/reference/release-notes#helm-package-compatibility
- https://nx.dev/reference/releases#supported-versions
-
https://nx.dev/blog/reliable-ci-a-new-execution-model-fixing-both-flakiness-and-slowness#problem-in-numbers
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Both heading and data should have the same alignment to be symmetrical.
## 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 -->
Eslint 9 is installed for new angular workspace but v7 of
@typescript-eslint/utils package is being installed and is incompatible
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Esnure v8 of @typescript-eslint/utils is installed
## 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>
<!-- 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 -->
There is no function to determine if the db cache is enabled
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a function to determine if the db cache is enabled.
## 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 -->
Tasks can end up depending on themselves if they depend on a dummy task
which ends up depending back on itself. This throws a weird error like:
```
NX Could not execute command because the task graph has a circular dependency
devkit:build --> devkit:build-base --> nx:build-base --> nx:build-base
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Tasks cannot depend on themselves. No errors are thrown in those cases.
## 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 -->
Custom task runners are a high level abstraction to customize caching, a
relatively low level mechanism, to utilize other methods of remote
caching. The abstraction of custom task runners makes it hard for Nx to
make guarantees to make it faster.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Custom task runners are now deprecated. They will still work for Nx 20
but a warning will be shown when they are being used. The migration path
is to use Nx Cloud (the ideal caching solution) or a Nx Powerpack cache
(written by the Nx Core team which we can make guarantees about).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR removes these from v20 since they were deprecated and slated for
removal:
- `executeWebpackDevServerBuilder` export from `@nx/angular/executors`,
users should use `executeDevServerBuilder`
- `withStylus` util from `@nx/next/plugins/with-stylus` since it was
deprecated in v17 and has just throw an error that users need to use
SASS with Next.js
The `getRollupOptions` function from `@nx/react/plugins/bundle-rollup`
has been deprecated as mention previously and slated for removal in v22.
New users are using inferred targets from Rollup, and existing projects
using this module should run `nx g @nx/rollup:convert-to-inferred` or
manually update rollup config to use `withNx` function.
Also, bumped some deprecation for later in v21:
- Remove inline builds from tsc/swc
- Changes to SVGR to align with Webpack v5 (e.g. `import ReactComponent
from './img.svg?svgr'`)
- Remove `isolatedConfig` from Webpack executor -- requires a migration
that extracts to a standard webpack config just in case (different from
the original one that extracts to `withNx`)
The ESLint TODOs were rescoped to `TODO(eslint)` and we'll look at it in
further flat config work rather than tying it to an Nx release.
<!-- 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 #
fix(js): resolve VerdaccioWarning: The configuration property "logs" has
been deprecated; Replaced with "log"
Currently, the Verdaccio configuration generated by running `nx generate
setup-verdaccio` contains the deprecated `logs` property. I have updated
this property to `log`, thereby removing the VerdaccioWarning that is
displayed when running `nx local-registry`
<!-- 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
Currently, the Verdaccio configuration generated by running `nx generate
setup-verdaccio` includes the deprecated 'logs' property. When you run
`nx local-registry` Verdaccio displays the following warning:
<img width="1453" alt="image"
src="https://github.com/user-attachments/assets/ccd95587-ec1b-458c-8717-8173a95c1e5d">
## Expected Behavior
Run `nx local-registry` without the warning after using the
`setup-verdaccio` generator.
BREAKING CHANGE
In Nx v19, implementing a custom changelog renderer would involve a lot
of work on the user side. They would need to create an additional
function making every property available in its declaration and then
call the underlying default one and customize the final string (or
reimplement the whole thing).
E.g.
```js
const changelogRenderer = async ({
projectGraph,
commits,
releaseVersion,
project,
entryWhenNoChanges,
changelogRenderOptions,
repoSlug,
conventionalCommitsConfig,
changes,
}) => {
const defaultChangelog = await defaultChangelogRenderer({
projectGraph,
commits,
releaseVersion,
project,
entryWhenNoChanges,
changelogRenderOptions,
repoSlug,
conventionalCommitsConfig,
changes,
});
// ...Do custom stuff and return final string...
};
module.exports = changelogRenderer;
```
In Nx v20, changelog renderer are classes. The DefaultChangelogRenderer
can therefore easily and granularly be extended and customized, and the
config does not need to be redeclared on the user side at all. We will
improve things even further in this area, but this breaking change is an
important stepping stone.
E.g. for manipulating the final string equivalent to the previous
example:
```js
module.exports = class CustomChangelogRenderer extends (
DefaultChangelogRenderer
) {
async render() {
const defaultChangelogEntry = await super.render();
// ...Do custom stuff and return final string...
}
};
```
E.g. for customizing just how titles get rendered:
```js
class CustomChangelogRenderer extends DefaultChangelogRenderer {
renderVersionTitle(): string {
return 'Custom Version Title';
}
}
```
<!-- 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 #
This PR allows `nx add` to initialize plugins that have prompts.
<!-- 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 -->
`getCache` has an argument for nxjson. This breaks nx cloud when using
the db cache.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`getCache` now only has options as an argument, and uses `readNxJson` in
the function body
## 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 #
<!-- 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 #
<!-- 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 -->
`axios` is loaded before tasks are run which causes a 30 ms delay.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`axios` is not loaded before tasks are run.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
BREAKING CHANGE
In Nx v19, `release.version.generatorOptions.updateDependents` is
"never" by default, meaning dependents are not automatically patched
when their dependencies change (applicable to independent projects).
In Nx v20, `release.version.generatorOptions.updateDependents` is "auto"
by default, meaning dependents are automatically patched when their
dependencies change (applicable to independent projects).
BREAKING CHANGE
In v19 of nx, the programmatic usage of `await releasePublish({ ... })`
would throw in the case that _any_ project failed to publish. It would
return the number `0` (to represent the overall exit code) in the case
that all projects were successfully published.
Now, in v20, the programmatic usage of `await releasePublish({ ... })`
will always return a `PublishProjectsResult` object, which is a mapping
of project names to an object of `{ code: number }` for each project.
This allows consumers to make informed decisions about which projects
failed to publish and decide how to handle it in their release scripts.
For example, where there are projects called "pkg-a" and "pkg-b" and
"pkg-a" is successfully published and "pkg-b" fails:
```ts
const result = await releasePublish({
dryRun: false
});
// result is set to { "pkg-a": { code: 0 }, "pkg-b": { code: 1 } )
```
<!-- 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 -->
Nx project names can be kebab-cased but module federation remotes that
use global or var will not support this.
They need to be snake cased
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
snake_case the remote names
## 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 -->
If there are project dependencies and not all projects contain the same
task target, a circular dependency error is shown.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If not all circular dependent projects contain the same task target,
allow execution of the target.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Enable generating the new & minimal TS setup by default when
generating the `ts` preset with CNW.
The existing `NX_ADD_TS_PLUGIN` environment variable is kept with its
default value inverted and set to `true`. It can be used to opt out of
the new TS setup by running CNW with `NX_ADD_TS_PLUGIN=false`.
- Throw an error when running generators that don't yet support the new
TS setup.
- We'll add support for those generators incrementally in follow-up PRs.
<!-- 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
-->
<!-- Fixes NXC-1066 -->
<!-- Fixes NXC-1068 -->
## 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 -->
Generating a JS publishable library with `--bundler=none` results in the
generator silently switching the `bundler` to `tsc` and generating a
`build` target.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Trying to generate a JS publishable library with `--bundler=none` should
throw an error.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-1075 -->
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 setting the Nx configuration for a JS library in the `package.json`
file, the provided tags is not set and the relevant `nx release`
configuration in `nx.json` is not set either.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When setting the Nx configuration for a JS library in the `package.json`
file, the provided tags should be set and the relevant `nx release`
configuration in `nx.json` should be configured.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-1074 -->
Fixes #
`--last-failed` allows running only the failed tests from the previous
run.
Example: `playwright test --last-failed`.
[Documentation](https://playwright.dev/docs/test-cli#reference)
<!-- 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 -->
Cannot provide `--last-failed` flag to playwright
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Should be able provide `--last-failed` via configuration entry
`lastFailed: boolean`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28096
- Move the integrated vs. package-based concept page to the deprecated
section
- Remove the integrated project in package-based repo recipe
- Remove the package-based project in integrated repo recipe
- Rename standalone to integrated recipe
- Update references to integrated or package-based terms in tutorials
<!-- 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
-->
<img width="428" alt="Screenshot 2024-09-30 at 8 54 38 PM"
src="https://github.com/user-attachments/assets/59b47117-4136-4a59-8e08-c223eafa94b4">
<img width="445" alt="Screenshot 2024-09-30 at 8 53 49 PM"
src="https://github.com/user-attachments/assets/9f9586fa-ae7a-44fe-bd67-305331b46bd4">
<img width="337" alt="Screenshot 2024-09-30 at 8 52 46 PM"
src="https://github.com/user-attachments/assets/762a6aaa-7260-47db-87b4-b394b4da4df1">
## 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 #
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Co-authored-by: Nicholas Cunningham <ndcunningham@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 -->
Transitive deps may not exist on the project graph or be installed in
the root package.json file.
They could require the singleton pattern and should use the
`additionalShared` functionality.
However, the additionalShared will check project graph and root
package.json, erroring if the package cannot be found.
The last resort should be to use `require.resolve` to check the
node_modules folder to find the package.json of the package and select a
version from it.
## 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#28137
<!-- 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 -->
Exports defined in `package.json` of packages could be objects rather
than strings such that we could see both:
```json
{
"exports": {
".": {
"default": "./src/index.js"
},
"index": {
"default": {
"default": "./src/index.js"
}
}
}
}
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The logic currently assumes it can only be a string.
Ensure it checks if an object exists first
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28129
<!-- 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 -->
`@nx/react:setup-ssr` defaults to webpack which causes issues when the
`react` app is already using rspack.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Infer bundler based on the `build` target
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28128
<!-- 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 we use generator's via the CLI passing the `name` arg
has more than one responsibility:
1. it can be used as a path
2. it can be used as the generator's name (e.g. Component name)
This is not intuitive as if we use via Nx Console because it creates
some ambiguity around the `--name` property which is normally described
as only 2.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
What is expected is that the `name` property should only have the
responsibility of determining the name of the generated module
(Component, Directive etc...).
The new property `path` replaces the `directory` property but fulfils
the same purpose as determining where the module should be created.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
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 -->
Custom webpack functions may return a promise that needs to be awaited
before we attempt to do any additional work on it
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure custom webpack functions are awaited. they will no-op for
synchronous functions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28200
This PR updates examples in `.md` files (both docs and blog posts) to
use positional args. Nx 20 changes the position arg to be either
`directory` for apps/libs or `path` for artifacts (e.g. components).
So before you'd do this:
```
nx g app myapp --directory=apps/myapp
nx g lib mylib --directory=libs/mylib
nx g lib mylib --directory=libs/nested/mylib
nx g lib @acme/foo --directory=libs/@acme/foo --importPath=@acme/foo
nx g component foo --directory=libs/ui/src/foo --pascalCaseFiles
```
Will now be simplified to
```
nx g app apps/myapp
nx g lib libs/mylib
nx g lib libs/nested/mylib
nx g lib libs/@acme/foo # name and import path are both "@acme/foo"
nx g component libs/ui/src/foo/Foo
```
For cases where `name` and `importPath` need to be changed, you can
always manually specify them.
```
nx g lib libs/nested/foo # name is foo
nx g lib libs/nested/foo --name=nested-foo # specify name with prefix
nx g lib libs/@acme/foo --name # use "foo" as name and don't match importPath
nx g lib libs/@internal/foo --importPath=@acme/foo # different importPath from name
<!-- 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 #
This PR updates the default test runner for React/Web apps to be
`vitest`. It aligned better with our emphasis on modern tooling, and the
lack of ESM and proper TS support (using `module` other than `commonjs`)
in Jest makes it hard to use in some workspaces.
<!-- 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 #
This PR removes the `@nrwl/*` packages. Also cleans up references to the
legacy packages.
NOTE: The rescope page is now under `/deprecated/rescope`. There is
still >1000K monthly traffic to it, which might be due to older Nx
users.
<!-- 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 -->
The link to show a list of powerpack plugins shows all plugins
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The link to show powerpack plugins shows powerpack plugins
## 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 -->
The native task hasher is faster and has been default for quite a while.
There's still a node hasher implementation though.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The native task hasher is the only task hasher implementation. The node
task hasher is no more.
## 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 -->
`@nrwl/rspack` is not being released because the repository url is
incorrect.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`@nrwl/rspack` is released... for now because the repository url is
correct.
## 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 --force is passed into every `expo install` command -> then
the package install command
- but it is not supported in yarn, change it to an option so it would
not get passed in everytime
## 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/28062
<!-- 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/27821
<!-- 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/28035
<!-- 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 #
---------
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 -->
## 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/26854
<!-- 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/27971
<!-- 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 -->
Counting project dependencies during the sort resulted in a lot of
duplicate work.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Count project dependencies for all tasks up front.. so that this
information can be easily accessed during the sort.
## 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 #
<!-- 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/26904
<!-- 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/26594
- feat: add rspack plugin (#143)
- feat: add rspack plugin (#143)
- feat(rspack): update to latest rspack version (#159)
- feat(rspack): add missing features (less/sass/stylus, assets, etc.)
(#160)
- feat(rspack): add missing features (less/sass/stylus, assets, etc.)
(#160)
- feat(rspack): clean-up project setup (#161)
- feat(rspack): clean-up project setup (#161)
- fix(rspack): use correct app dir when generating non-root projects
(#162)
- fix(rspack): use correct app dir when generating non-root projects
(#162)
- chore(repo): migrate to Nx 15.8.5 (#169)
- feat(rspack): update and pin rspack to 0.1.0 (#173)
- fix(rspack): fix rspack build
- chore(rspack): remove comment (#175)
- feat(rspack): set mode in configuration and expose option (#177)
- fix(rspack): handle existing stylePreprocessorOptions (#182)
- fix(rspack): add dependency to ajv-keywords that match the version
used by rspack (#187)
- fix(rspack): pass devServer options to devServer (#193)
- fix(rspack): set externals for target node (#194)
- feat(rspack): install latest patch when configuring (#195)
- fix(rspack): add withWeb if web app (#200)
- chore(repo): fix release script (#202)
- chore(repo): fix release script (#202)
- feat(rspack): configuration generator better ux (#201)
- feat(rspack): builder returns outfile (#207)
- fix(rspack): use ensureTypescript before tsquery (#215)
- feat(rspack): simplify app generator (#212)
- feat(rspack): simplify app generator (#212)
- fix(rspack): implement watch mode (#217)
- fix(rspack): do not force cssmodules (#222)
- fix(rspack): use builtin minify instead (#172)
- fix(rspack): use built-in tsconfig paths support (#227)
- fix(rspack): add back `resolve.alias` configuration since
`resolve.tsConfigPaths` seem to be incorrect in some scenarios (#229)
- feat(misc): update to Nx 16 and rescoped packages (#235)
- feat(misc): update to Nx 16 and rescoped packages (#235)
- fix(misc): replace missed references to @nrwl scope (#239)
- chore(repo): add legacy packages for nx rescope (#238)
- chore(repo): add legacy packages for nx rescope (#238)
- fix(repo): fix publishing for legacy packages (#240)
- fix(repo): fix publishing for legacy packages (#240)
- fix(misc): target commonjs for legacy packages (#241)
- fix(repo): add json files to assets (#243)
- chore(repo): update to 16.0.3 (#244)
- chore(repo): update to nx 16.2.1 (#271)
- fix(rspack): lock version to 0.1.11 (#279)
- fix(rspack): refine output filename patterns (#280)
- chore(rspack): update to latest (#278)
- feat(rspack): Add extractLicenses option to rspack's project
configuration (#230)
- feat(rspack): Add extractLicenses option to rspack's project
configuration (#230)
- fix(rspack): add missing license-webpack-plugin dependency (#301)
- chore(repo): upgrade to nx 16.6.0 (#319)
- fix(rspack): add fileReplacements support (#231)
- chore(reop): update nx to 16.7.1 (#325)
- chore(rspack): add jest babel config to e2e (#321)
- chore: don't use rspack internal module (#328)
- chore(repo): update nx to 16.8.1 (#335)
- feat(rspack): add typecheck (#338)
- chore(repo): update nx to 17.0.1 (#342)
- feat(rspack): add generatePackageJson plugin (#341)
- feat(rspack): add generatePackageJson plugin (#341)
- feat: upgrade rspack to 0.4.4 (#352)
- fix(rspack): Add missing peer dep (#372)
- chore(repo): migrate to latest nx (#376)
- chore(repo): migrate to latest nx (#376)
- feat(rspack): update rspack to install the latest version (#379)
- feat(rspack): add option to keep existing versions of packages for
init generator (#378)
- fix(rspack): do not depend directly on ajv to allow for correct
hoisting (#384)
- fix(rspack): ensure react-refresh is installed (#385)
- fix(rspack): User port should be respected. (#387)
- feat(rspack_: update rspack to install latest version (#389)
- feat(rspack): support object configs (#402)
- feat(rspack): add crystal plugin for inferring projects (#407)
- feat(rspack): add crystal plugin for inferring projects (#407)
- feat(rspack): bump to latest rspack (#412)
- fix(rspack): add postcss-loader for css files (#415)
- feat(rspack): add module federation support (#416)
- feat(rspack): add module federation support (#416)
- fix(rspack): add hook for dev server to log when compilation completed
(#417)
- feat(rspack): add module-federation-static-server (#418)
- fix(rspack): ensure process is default import (#420)
- chore(repo): move packages/rspack to packages/rspack to prepare to be
imported
- chore(repo): move packages-legacy/rspack to packages-legacy/rspack to
prepare to be imported
- chore(repo): move e2e/rspack-e2e to e2e/rspack to prepare to be
imported
- chore(repo): fix e2e setup
- chore(repo): add rspack commit scope
- chore(rspack): configure correctly
- chore(rspack): final fixes
- docs(rspack): add docs for rspack
- chore(rspack): fix rspack e2e
- chore(react): add rspack bundler test
<!-- 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
-->
<img width="330" alt="Screenshot 2024-09-23 at 1 26 23 PM"
src="https://github.com/user-attachments/assets/fa62fcb6-a0a5-4684-a162-8003d1156418">
<img width="994" alt="Screenshot 2024-09-23 at 1 26 10 PM"
src="https://github.com/user-attachments/assets/8b2c8949-7aeb-4e9f-9502-14381ad980e4">
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Closes#27893
## Current Behavior
see #27893
## Expected Behavior
see #27893
## Related Issue(s)
see #27893
Fixes #
- docs for affected
---------
Co-authored-by: Isaac Mann <isaacplmann@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 -->
## 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 #
<!-- 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
Sometimes tslib is missing even though it is needed for typechecks.
## Expected Behavior
tslib is installed when needed. i.e. `importHelpers: true`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27656
This PR enables composite graph functionality:
- Experimental feature to enable Composite Graph
- In Composite Graph mode:
- Nodes are shown by default.
- Show/Hide All Projects function similarly to regular mode
- Focus a Composite Node renders the inner nodes with up-to 3 additional
containers: Green area contains external nodes that depend on the inner
nodes; Orange area contains external nodes that the inner nodes depend
depend on; Purple area contains external nodes with circular
dependencies with the inner nodes.
- Focused node can be unfocus/reset.
- Only one node can be focused at one given time. - Show All projects
while having a focused node will unfocus the node.
- Expand a Composite Node renders the inner nodes of the composite node
in-place (i.e: still keep the context of the current graph). Expanded
node can be collapsed to go back.
This PR fixes an issue with buildable/publishable Angular libs, where TS
rules are being applied to JSON files.
<!-- 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#28069
---------
Co-authored-by: James Henry <james@henry.sc>
<!-- 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#27617
Co-authored-by: James Henry <james@henry.sc>
<!-- 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
-->
Updated references about start-ci-run to include mentions of warnings
that you get if you don't include the `--distribute-on` flag.
Also removed references to the legacy `--stop-all-agents` command in
favor of `--complete-ci-run`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- ✅ Activate powerpack recipe
- ✅ Powerpack owners documentation
- [x] Powerpack custom remote cache documentation
- [x] Powerpack conformance documentation
Infrastructure for powerpack docs
- Adds the ability to generate API docs from ocean packages
To generate API documentation for plugins in the ocean repository, run
the `nx documentation` command with the `NX_OCEAN_RELATIVE_PATH`
environment variable set to the relative path to your checked out copy
of the ocean repo.
```
NX_OCEAN_RELATIVE_PATH=../ocean nx documentation
```
This will create generated API documentation in the
`docs/external-generated` folder. This API will be merged into the
normal `docs/generated` documentation when the docs site is built.
Because there are two separate output folders, if someone runs `nx
documentation` without the `NX_OCEAN_RELATIVE_PATH` environment
variable, the ocean documentation will not be overwritten. The ocean
documentation will only be updated or deleted when someone explicitly
chooses to do so.
---------
Co-authored-by: Juri Strumpflohner <juri.strumpflohner@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 -->
## 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 -->
Users get a `disk i/o` error from connecting to SQL because of a vfs.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Not really sure but this might address those errors. Might not. We don't
need this at the moment though because the SQL database is not compiled
for wasi.
## 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 flag in `nx.json` to enable the db cache
* Typings for powerpack are `any`
* Powerpack errors are not shown in `nx report`
* 9999 workspaces show up when user purchases unlimited license
* There is no indication from caching that license has expired.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
* There is an `enableDbCache` flag for `nx.json`. It'll probably be
changed soon.
* Typings for powerpack come from the powerpack packages
* Powerpack errors are shown in nx report
* "an unlimited number of workspaces" shows up when user purchases
unlimited license
* There is an indication when licenses expire.
## 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 #
`nx add` errors should be surfaced to users.
<!-- 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
Users do not see errors from init generator.
## Expected Behavior
Users see errors from init generator.
## 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 #
- feat(storybook): remove cypress options from configuration generator
- feat(react): remove cypress options from storybook-configuration
- feat(react): remove cypress options from stories generator
- feat(react): remove component-cypress-spec generator
- chore(storybook): restore @nx/cypress dep
- feat(remix): remove cypress options from storybook
- feat(angular): remove cypress options from storybook-configuration
- feat(angular): remove cypress options from stories generator
- feat(angular): remove component-cypress-spec generator
- feat(vue): remove cypress options from stories 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` -->
<!-- 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 Storybook Interaction Testing, there's no longer a need to setup
Cypress to specifically test storybook instances
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remove cypress options for creating an e2e project specifically for
testing storybook instances.
Use Storybook Interaction Testing instead
## 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 #
<!-- 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 -->
Whenever a file is created in a project, the daemon will insert the
newly created file at the end of the project file map list. This causes
issues with cache determinism because the newly created file is not
sorted. When doing `nx reset`, the file will then be properly sorted
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Whenever a file is inserted into the project map, sort the changed file
map.
## 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 #
This PR allows init generators to prompt during `nx init`.
Demo (temporarily adds prompt to vite init):
https://www.loom.com/share/ad40e6f02186478596ea6e1f08dba7a4
<!-- 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 #
<!-- 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 #
---------
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
<!--
_[Please make sure you have read the submission guidelines before
posting an
PR](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## nx-solhint
<!--
Describe what your plugin is and what is its goal or issues it
addresses. If you don't provide a description, we will not merge your
PR.
Is it focused on a technology, tooling or behaviour? Does the plugin
provide generators, executors or graph support?
Do you know who is already using the plugin? Mention who is the author
of the plugin.
-->
<!-- 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 db cache does not work without task details.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The db cache works without task details.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Add a missing class name causing the icon text to display on screen.
<img width="2033" alt="Screenshot 2024-09-20 at 3 58 36 PM"
src="https://github.com/user-attachments/assets/0a741e04-6467-463f-9e16-058aa495c095">
<!-- 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 #
<!-- 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 -->
Invalid cache message shown twice.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Invalid cache message shown once.
## 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 -->
Some packages that use `exports` in the package.json may point to a
directory such as `esm/<entrypoint>`.
They would still be imported such as `mypackage/secondary-point`.
This needs to be shared still for Module Federation.
However, our current logic for finding secondary entry points for
packages looks at the sub dirs of the package and tries to match it with
the exports fiels.
Therefore if `mypackage/secondary-point` was set up such that
```
"./secondary-point": {
default: "esm/secondary-point/index.mjs"
}
```
then it would never be found correctly, causing share problems.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
exports of secondary entrypoints should be shared correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26878
<!-- 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 name is `@nx/powerpack-shared-cache`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The name is `@nx/powerpack-shared-fs-cache`
## 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 #
<!-- 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 `license-webpack-plugin` is trying to scan the root package.json on
windows, resulting in an error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Patch the `license-webpack-plugin` to prevent it from scanning the root
package.json. A similar fix was needed for rspack.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27989
This PR expands the concept page for sync generators to show config
examples for `applyChanges` and `disableTaskSyncGenerators`. It also
adds a link when during the sync prompt for users to read more about it.
<img width="1392" alt="Screenshot 2024-09-19 at 12 00 14 PM"
src="https://github.com/user-attachments/assets/a13f50b7-557a-4c76-8903-49486ebf4ff2">
Preview:
https://nx-dev-git-feat-sync-docs-and-links-nrwl.vercel.app/concepts/sync-generators
<!-- 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 -->
React Module Federation generators were normalizing names and using them
incorrectly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The host and remote generators should always use the name provided by
the determineProjectNameAndRootOpitons
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27901
<!-- 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 -->
Some of the commands and file contents are outdated approaches for
Angular
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Correct the commands and file contents
## 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 -->
It will cause confusion if this is documented without other
documentation.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`activate-powerpack` is undocumented for now.
## 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 -->
The remote cache was not being initialized on the new db cache.
Powerpack license expiration improperly assumed to be unix timestamp in
ms
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The remote cache is being initialized on the new db cache. Powerpack
license expiration shows up properly.
## 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 #
<!-- 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 Nx Powerpack product.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Integration with Nx Powerpack is added. Nx Powerpack is optional, stay
tuned for more information which will be released soon.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
Co-authored-by: JamesHenry <james@henry.sc>
<!-- 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 -->
When `prettier` is not installed, running `nx format` results in an
uncaught error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When `prettier` is not installed, running `nx format` should handle the
error and log a more appropriate message.
## 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 #
This PR switches `globWithWorkspaceContext` with
`globWithWorkspaceContextSync` for `nx init` and `nx import`, since the
latter isn't guaranteed to have updated file map during the init/import
process.
Note: Also updates Gradle import test to ensure the destination repo
does not have uncommitted changes.
<!-- 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
Sometimes plugins are not detected.
## Expected Behavior
Always detect plugins.
## 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 -->
- between this.tasksSchedule.scheduleNextTasks() and
this.tasksSchedule.nextTask(), scheduledTasks are different when in
parallel, so when calling `processAllScheduledTasks`, it does not
process the all scheduled tasks, so it did not populate env.
## 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/27586
<!-- 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 #
This PR handles Windows arguments correctly, since Powershell and Cmd do
not support single quotes.
**Changes:**
- Properly escape '\' in Windows paths
- Set source and destination using environment variables rather than
args to avoid pwsh handling of quotes
<!-- 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-887 -->
Fixes #
---------
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 -->
Setup angular incremental builds doc does not contain info on esbuild
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add information about using incremental builds with angular.
Also callout that the performance gain may not be as effective as it was
with webpack
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27716
When users run `nx import` and open a PR with the imported package, they
should be able to use `git rebase --rebase-merges` to update their
branch with latest main.
## Why this matters
If the repo requires the PR to be updated with latest main before merge,
the user must have a way to do this and avoid having to do the import
process all over again.
<!-- 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
Rebase results in git error
## Expected Behavior
Rebase works
## 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 -->
`build-storybook` is being added to cacheable operations multiple times
when the `@nx/storybook:init` generator is being invoked.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Do not add `build-storybook` multiple times
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27866
<!-- 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 #
- docs(nx-dev): add blog for nx rspack mod fed
- docs(nx-dev): add next-gen module federation deployments blog post
<!-- 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 -->
Should use correct namedInputs in the migration instead of assuming
'production' is available.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the correct namedInputs based on what is listed in `nx.json`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27899
…connecting to the db
<!-- 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 flag to disable the DB and little logs for when Nx fails to
connect to the DB.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a `NX_DISABLE_DB=true` flag which can be used to disable usage
of the DB. There are more logs which should help us identify what
exactly is failing when connecting to the DB.
## 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, if we generate a react app with `--routing` enabled navigate
to the 2nd page and doing a refresh fails the load.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Routing to another page and refreshing should work out of the box.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#23188
<!-- 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
After running `nx test project` or `nx run-many -t test` with no test
files with `@nx/vite:test` plugin, vitest process exit directly but nx
reporter keep waiting for finish notification which cause to waiting
indefinitely.
vitest reference:
https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/core.ts#L409-L413https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/cli/cli-api.ts#L102-L116
console log example:
```bash
nx test project
> nx run project:test
RUN v2.0.5 /path/to/project
include: src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}
exclude: **/node_modules/**, **/dist/**, **/cypress/**, **/.{idea,git,cache,output,temp}/**, **/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build,eslint,prettier}.config.*
No test files found, exiting with code 0
```
```bash
nx run-many -t test --no-cache -p project
NX Running target test for project project
With additional flags:
--cache=false
→ Executing 1/1 remaining tasks...
⠹ nx run project:test
```
## Expected Behavior
`nx test project` should exit directly in case vitest process exit
early.
## 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 the `@nx/angular/mf` file is loaded, it sets `remoteUrlDefinitions
= {}`.
As this is a global, this can lead to erroneous behaviour by resetting
existing definitions. It is also always truthy, breaking logic on
whether urls need to be set or not.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The object should be conditionally set if undefined when calling
`setRemoteDefinition`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27793, #27842
<!-- 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 Remix plugin is too strict when finding Remix Vite projects
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Remix plugin should be more permissive in finding Remix Vite
projects
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27884
<!-- 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 `serve-static` target is being added in the `add-e2e` file, however,
it has uses beyond e2e.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `serve-static` target should be added with more intention
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27854
<!-- 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 -->
Vite typecheck target is not falling back to default if production does
not exist.
It also does not have an input on typescript itself
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Inputs should be configured correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
we have fully isolated graph & error components with a good api but no
way to access them directly from the outside (in console).
This PR adds two functions to the window object so that we can render
the PDV directly instead of needing the entire app with routing and
everything.
---------
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 -->
## 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
The DX to migrate to project crystal isn't great right now - people have
to run `convert-to-inferred` generators manually.
## Expected Behavior
We should provide a smoother way to migrate, so we introduced an
`@nx/workspace:infer-targets` generator that can handle multiple
conversions at once, either for the whole workspace or at a project
level.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
When we load `.ts` files and the closest `package.json` specifies
`"type": "module"`, then the file may error upon loading. This happens
because we're not setting `compilerOptions` correctly when registering
`ts-node/esm`-- in fact there is no way to pass options through this
hook.
This PR sets defaults on `TS_NODE_COMPILER_OPTIONS` such that the
`module` and `moduleResolution` are correct values for ESM. It also
works for CJS since both `module` and `moduleResolution` check the
closest `package.json` to determine the format.
## 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#23228
Some error messages are not displaying properly, as they pass their
original message as a cause. While `node` supports this, our
`handleErrors` function was not displaying error causes.
```
"Failed to process project graph. Run "nx reset" to fix this. Please report the issue if you keep seeing it.
CreateMetadataError: The "test-plugin" plugin threw an error while creating metadata: cause message
at /Users/agentender/repos/nx/packages/nx/src/utils/handle-errors.spec.ts:17:29
at handleErrors (/Users/agentender/repos/nx/packages/nx/src/utils/handle-errors.ts:11:26)
at Object.<anonymous> (/Users/agentender/repos/nx/packages/nx/src/utils/handle-errors.spec.ts:15:23)
at Promise.then.completed (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/utils.js:298:28)
at new Promise (<anonymous>)
at callAsyncCircusFn (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/utils.js:231:10)
at _callCircusTest (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:316:40)
at async _runTest (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:252:3)
at async _runTestsForDescribeBlock (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:126:9)
at async _runTestsForDescribeBlock (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:121:9)
at async run (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:71:3)
at async runAndTransformResultsToJestFormat (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapterInit.js:122:21)
at async jestAdapter (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapter.js:79:19)
at async runTestInternal (/Users/agentender/repos/nx/node_modules/.pnpm/jest-runner@29.7.0/node_modules/jest-runner/build/runTest.js:367:16)
at async runTest (/Users/agentender/repos/nx/node_modules/.pnpm/jest-runner@29.7.0/node_modules/jest-runner/build/runTest.js:444:34)
Caused by:
Error: cause message
at /Users/agentender/repos/nx/packages/nx/src/utils/handle-errors.spec.ts:16:21
at handleErrors (/Users/agentender/repos/nx/packages/nx/src/utils/handle-errors.ts:11:26)
at Object.<anonymous> (/Users/agentender/repos/nx/packages/nx/src/utils/handle-errors.spec.ts:15:23)
at Promise.then.completed (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/utils.js:298:28)
at new Promise (<anonymous>)
at callAsyncCircusFn (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/utils.js:231:10)
at _callCircusTest (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:316:40)
at async _runTest (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:252:3)
at async _runTestsForDescribeBlock (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:126:9)
at async _runTestsForDescribeBlock (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:121:9)
at async run (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/run.js:71:3)
at async runAndTransformResultsToJestFormat (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapterInit.js:122:21)
at async jestAdapter (/Users/agentender/repos/nx/node_modules/.pnpm/jest-circus@29.7.0/node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapter.js:79:19)
at async runTestInternal (/Users/agentender/repos/nx/node_modules/.pnpm/jest-runner@29.7.0/node_modules/jest-runner/build/runTest.js:367:16)
at async runTest (/Users/agentender/repos/nx/node_modules/.pnpm/jest-runner@29.7.0/node_modules/jest-runner/build/runTest.js:444:34)"
`
```
<!-- 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
Plugins that export `createNodesV2` are not considered as having
inference capabilities
## Expected Behavior
`createNodesV2` is the future API replacing `createNodes`, so it should
show the same capability
## 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
-->
NxCloudId should be part of the URL that is created when connecting a
new workspace.
## 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 #
Co-authored-by: FrozenPandaz <jasonjean1993@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 -->
## 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 #
The `NxAppWebpackPlugin` does not support relative paths in
`additionalEntryPoints`.
So this will fail:
```js
new NxAppWebpackPlugin({
...
additionalEntryPoints: ['.src/foo.ts']
```
The resolved path is relative to workspace root when it should be
project root.
<!-- 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
Build will fail.
## Expected Behavior
Build should work.
## 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
-->
More graphics for changing and viewing access tokens (both CI and
personal). Also update the CI access token page with more information on
how to set them and the purposes of read-only tokens.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
This PR adds a warning when the user choose different source and
destination roots. This is a problem for Nx workspaces using path
options in `project.json`, and possibly other config files such as
`tsconfig.json`, `jest.config.ts`, etc.
Note: Also included a guard that the destination directory isn't an
absolute path like `/tmp/foo`, because the behavior will not work as
expected.
The message when the source is an Nx workspace:
<img width="1392" alt="Screenshot 2024-09-11 at 9 32 54 AM"
src="https://github.com/user-attachments/assets/c8ebedba-fd66-4dbf-ada9-eacf86bd67fc">
The message when the source is not an Nx workspace:
<img width="1392" alt="Screenshot 2024-09-11 at 9 30 44 AM"
src="https://github.com/user-attachments/assets/ade9fbd1-4d5d-4d0c-93f6-eaad176af333">
<!-- 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 https://github.com/nrwl/nx/issues/27819
<!-- 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 #
- Fixes typo for login/logout on commands landing page
- Mention that `nx-cloud login` is the same as `nx login`
- Update references to `npx nx-cloud login` to use `nx login` by default
instead
- Updates Workspace ID access level wording in the "Nx CLI and CI Access
Tokens" page
<!-- 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 -->
The new db cache is not being used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The new sqlite db cache is being used.
## 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 -->
Default access level of workspace ID setting is read-only
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Default access level of workspace ID setting is read-write
## 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 #
<!-- 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 -->
This repo uses Nx 19.7.0-beta.1
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 19.7.0-beta.6
## 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 #
<!-- 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 -->
We can serve each application in a module federation setup statically,
but only individually.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add a serve static executor for module federation hosts which will also
spin up the remotes statically
## 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 -->
The `server-process.json` for the daemon gets included in a root
project's **/* fileset when it changes after the daemon has started.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `server-process.json` watching is handled in the `outputs` file
watcher which will not add it to the workspace files and won't show up
in the **/* fileset.
## 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 we had initially designed our Module Federation support for React,
we had to get some changes put in place in webpack itself directly to
allow for ESM.
However, the best support for Module Federation for both Rspack and
Webpack comes from CJS.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure CJS is used to ensure interopability between webpack and rspack
module federation applications
## 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 -->
wasm build is broken, blocking releases.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
wasm build is not broken.
## 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 -->
The help tooltip for an example using `args` is misleading. It states
that `args` are CLI positional arguments, but they can also be CLI
flags.
Additionally, the fallback example shows an example using `options`,
which has a few caveats.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The help tooltip for an example using `args` should state that `args`
are CLI flags or positional arguments.
The fallback example should show only an example using `args` to reduce
the likelihood of users bumping into any of the caveats of using
`options`, which could be frustrating.
Note: a separate change to the docs will be made to explicitly call out
these caveats. Users would still be able to use `options`, but it
shouldn't be the recommended way of providing args unless they are well
aware of the caveats.
## 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
-->
Newly generated `ci-workflow` setups should use the latest GH package +
v9 PNPM version
## 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 a race condition in the `@nx/eslint/plugin` causing projects to
be missing lint.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/eslint/plugin` creates a map of lintable files up front before
analyzing any particular project and there is no race condition.
## 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
- Nonexistant outputs are considered globs
- Glob outputs are walked from workspace root, which is slow on large
repos
[NX Daemon Server] - 2024-09-06T19:44:39.674Z - Done responding to the
client outputsHashesMatch
[NX Daemon Server] - 2024-09-06T19:44:39.674Z - Handled
OUTPUTS_HASHES_MATCH. Handling time: 94. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:44:39.775Z - [REQUEST]: Responding to
the client. recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:44:39.775Z - Done responding to the
client recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:44:39.775Z - Handled
RECORD_OUTPUTS_HASH. Handling time: 100. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:44:39.818Z - [REQUEST]: Responding to
the client. PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:44:39.818Z - Done responding to the
client PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:44:39.818Z - Handled
PROCESS_IN_BACKGROUND. Handling time: 14. Response time: 0.
## Expected Behavior
- Nonexistant outputs are only globs if they should be
- Globs are a bit faster
[NX Daemon Server] - 2024-09-06T19:43:36.899Z - Handled
OUTPUTS_HASHES_MATCH. Handling time: 0. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:43:36.900Z - [REQUEST]: Responding to
the client. recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:43:36.900Z - Done responding to the
client recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:43:36.900Z - Handled
RECORD_OUTPUTS_HASH. Handling time: 0. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:43:36.944Z - [REQUEST]: Responding to
the client. PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:43:36.944Z - Done responding to the
client PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:43:36.944Z - Handled
PROCESS_IN_BACKGROUND. Handling time: 13. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:43:36.949Z - Uploading file artifacts
[NX Daemon Server] - 2024-09-06T19:43:36.949Z - Done uploading file
artifacts
> Note timings are from Nx repo, close enough to be comparable. No real
improvement was expected here, mainly checking that things didn't get
worse.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
- feat(react): add remote rspack module federation support
- feat(react): add host rspack module federation support
- feat(react): add federate module rspack module federation support
- fix(react): migration test
<!-- 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 -->
We do not have an option to generate a react host and remote with rspack
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add rspack as an option when generating host and remote
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- adds a new Personal Access Tokens page
- updates the existing Access Tokens page to emphasise they're more for
CI
- adds `nx-cloud login` reference
- adds `nx-cloud configure` reference
---------
Co-authored-by: lourw <56288712+lourw@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
<!-- This is the behavior we have today -->
You need to use NX_ENABLE_LOGIN=true to connect to Nx Cloud with
nxCloudId. Documentation also is hidden for `nx login` and `nx logout`
aliases.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx connect` automatically connects via nxCloudId. Documentation shows
up for `nx login` and `nx logout` commands.
## 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 -->
The orchestrator creates the cache.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The cache file has a function which the orchestrator can use to get the
cache.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Add a new flag `--skipSync` to the run commands to skip running
syncing when running tasks.
<!-- 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-946 -->
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 -->
Graphs in nx.dev not working
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Graphs in nx.dev works
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates the tsconfig paths plugin for Vite such that it resolves
paths with file extensions as well.
<!-- 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#22868
- fix(module-federation): SSR should work correctly
- fix(module-federation): ssr-dev-servers should wait for remotes before
starting final 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` -->
<!-- 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 #
- feat(remix): add createnodesv2
- feat(remix): support vite in the plugin
- feat(remix): support remix vite in plugin
- fix(remix): init should ues addPlugin v2
<!-- 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 -->
Nx does not currently infer targets when someone is using remix w/ vite
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx should infer targets for remix vite apps
## 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 #
---------
Co-authored-by: FrozenPandaz <jasonjean1993@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 -->
## 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 #
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@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 -->
- nx login and logout aliases point toward nx-cloud login and logout
- when you connect a new workspace, by default nxCloudId will be added
to your nx.json
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- removed documentation and references to nx login and logout aliases
- when you connect a new workspace, by default nxCloudAccessToken will
be added to your nx.json
## 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 #
<!-- 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 plugin isolation turned on, it works on CI but doesn't on slow
laptops due to corporate software.
We currently run nx with the following patch to figure out why it happen
:
```patch
diff --git a/src/project-graph/plugins/isolation/plugin-pool.js b/src/project-graph/plugins/isolation/plugin-pool.js
index b10ee0d28c994db4e39c4f650dd47496c22cdb60..5a4dfb015906de8a0f9028e09140c6a3f543ca28 100644
--- a/src/project-graph/plugins/isolation/plugin-pool.js
+++ b/src/project-graph/plugins/isolation/plugin-pool.js
@@ -266,6 +266,7 @@ async function startPluginWorker() {
const id = setInterval(async () => {
const socket = await isServerAvailable(ipcPath);
if (socket) {
+ console.log('Managed to start the worker after', attempts, 'attempts.')
socket.unref();
clearInterval(id);
resolve({
@@ -273,10 +274,10 @@ async function startPluginWorker() {
socket,
});
}
- else if (attempts > 1000) {
+ else if (attempts > 10000) {
// daemon fails to start, the process probably exited
// we print the logs and exit the client
- reject('Failed to start plugin worker.');
+ reject('Failed to start plugin worker after ' + attempts + ' attempts.');
}
else {
attempts++;
```
With the added logging, we can see the following:
On ci (nx agents, or circleci)
```
Managed to start the worker after 17 attempts.
Managed to start the worker after 20 attempts.
Managed to start the worker after 23 attempts.
Managed to start the worker after 26 attempts.
Managed to start the worker after 27 attempts.
Managed to start the worker after 27 attempts.
Managed to start the worker after 28 attempts.
Managed to start the worker after 39 attempts.
Managed to start the worker after 47 attempts.
Managed to start the worker after 34 attempts.
Managed to start the worker after 36 attempts.
Managed to start the worker after 40 attempts.
Managed to start the worker after 47 attempts.
Managed to start the worker after 52 attempts.
Managed to start the worker after 54 attempts.
Managed to start the worker after 54 attempts.
Managed to start the worker after 55 attempts.
Managed to start the worker after 41 attempts.
Managed to start the worker after 53 attempts.
Managed to start the worker after 59 attempts.
Managed to start the worker after 46 attempts.
Managed to start the worker after 60 attempts.
Managed to start the worker after 52 attempts.
Managed to start the worker after 67 attempts.
```
On local (Mac, silicon m1)
```
Managed to start the worker after 59 attempts.
Managed to start the worker after 112 attempts.
Managed to start the worker after 166 attempts.
Managed to start the worker after 221 attempts.
Managed to start the worker after 274 attempts.
Managed to start the worker after 160 attempts.
Managed to start the worker after 269 attempts.
Managed to start the worker after 436 attempts.
Managed to start the worker after 390 attempts.
Managed to start the worker after 480 attempts.
Managed to start the worker after 427 attempts.
Managed to start the worker after 655 attempts.
Managed to start the worker after 754 attempts.
Managed to start the worker after 745 attempts.
Managed to start the worker after 200 attempts.
Managed to start the worker after 158 attempts.
Managed to start the worker after 854 attempts.
Managed to start the worker after 852 attempts.
Managed to start the worker after 1011 attempts.
Managed to start the worker after 373 attempts.
Managed to start the worker after 1180 attempts.
Managed to start the worker after 628 attempts.
Managed to start the worker after 789 attempts.
Managed to start the worker after 747 attempts.
```
We even got to numbers as high as 2000 on some laptops.
For the reference, we have the following plugins on our `nx.json`
```json
{
"plugins": [
{
"name": "tsc",
"plugin": "./tools/nx-tools/src/plugins/tsc.ts",
"options": {
"targetName": "type-check"
}
},
{
"name": "eslint",
"plugin": "./tools/nx-tools/src/plugins/eslint.ts",
"options": {
"targetName": "lint"
}
},
{
"plugin": "@nx/vite/plugin",
"options": {
"buildTargetName": "build",
"previewTargetName": "preview",
"testTargetName": "test",
"serveTargetName": "dev",
"serveStaticTargetName": "serve-static"
}
},
{
"plugin": "./tools/nx-tools/src/plugins/jest.ts",
"options": {
"targetName": "test"
}
},
{
"plugin": "./tools/nx-tools/src/plugins/tsup.ts",
"options": {
"targetName": "build"
}
},
{
"plugin": "./tools/nx-tools/src/plugins/storybook.ts",
"options": {
"buildStorybookTargetName": "build-storybook",
"serveStorybookTargetName": "storybook",
"testStorybookTargetName": "test-storybook",
"staticStorybookTargetName": "static-storybook"
}
}
]
}
```
One thing we managed to find out is the more plugin on the project, the
bigger the number.
So for now, the current workaround is to bump to 10000 instead of 1000
tries
_Debugged in pair with @AgentEnder_
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Plugin worker should work and nx should be working with plugin isolation
<!-- 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
Parallelism is part of the project schema but not `targetDefaults`. This
means it's highlighted as a warning in `nx.json`
## Expected Behavior
There should be no warning.
<!-- 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 create an app with `--appName <app name in camel case>`, it
currently has an error. it is caused by line:
```
const { root: appRoot } = readProjectConfiguration(
host,
names(options.appProject).fileName
);
```
it should not convert appProject to fileName, it should just take the
appProject as it is:
```
const { root: appRoot } = readProjectConfiguration(host, options.appProject);
```
## 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/24080
This PR fixes an issue with `nx import` where multiple directories
cannot be imported from the same repo. We now use `git filter-repo` (if
installed) or `git filter-branch` (fallback) to prepare the repo for
import so anything not in the subdirectory will be ignored (i.e. cleaner
history).
Note: `filter-repo` is much faster but requires the user to install it
first via their package manager (e.g. `brew install git-filter-repo` or
`apt install git-filter-repo`). We fallback to `git filter-branch` since
it comes with git, but it is slower, so the process may take 10+ minutes
on really large monorepos (e.g. next.js).
Also:
- Use `await` before returning a promise to Node can maintain correct
stacktrace
- Remove logic for `if (relativeSourceDir === '')` since using
`filter-branch` moves all the files to the root (`.`)
- Default destination project location to be the same as source (e.g.
importing `packages/a` will go to `packages/a` unless user types in
something else)
- Add `--depth` option if users don't want to clone with full history
(default is full history)
- Fix issues with special characters causing `git ls-files` + `git mv`
to since `mv` doesn't work with escaped names
<!-- 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 -->
expo tends to cache the output if there is no change in metro.config.js
we don't need to explicitly set the args --clear when
https://github.com/expo/expo/issues/30930 is fixed
## 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/27392
<!-- 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/27367
<!-- 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 running sync generators in the background (daemon) to cache the
results for when needed, they are isolated from each other (each run
with its own `Tree`). This is done because there's no guarantee which
sync generator will be run together since that would depend on each
specific task graph being run. When a task is run, a task graph is
constructed, and sync generators are collected from it and run/retrieved
from the cache.
Currently, when we run a task and ask the daemon to run the relevant
generators, if there are cached results for a generator that ran in
isolation, we return it. We don't check if its file changes conflict
with those of another generator included in the task graph. This results
in the changes for those conflicting files of the first generator
getting overwritten by the changes of the second generator.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When running tasks for which there are conflicting file changes between
generators in the daemon, the conflicting generators should be re-run
sequentially using the same `Tree` to guarantee that file changes are
not overwritten and lost.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-903 -->
Fixes #
Tabs are not displaying correctly on the second page that is viewed.
Should be able to select the `project.json` tab on `Run Tasks` and then
switch to `Cache Task Results` and have the `Nx >= 17` tab shown.
This update introduces a new 'genreate-token' option to force local
token creation. It ensures tokens are not created for GitHub-based
setups unless explicitly overridden. Adjustments include updated logic
in the generator function and schema to accommodate the new option.
<!-- 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/22631
<!-- 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
-->
Enables `nx connect` to use the V2 endpoint from Nx API such that it
creates an `nxCloudId`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes an issue with `node:test` not being recognized as a
built-in Node module, and since it is not in `node_modules` with a
resolvable `package.json`, it hits an infinite loop.
<!-- 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 #
This PR fixes and issue when `watch: false` and
`runBuildTargetDependencies: true` results in the server process
restarting, but no build happens.
<!-- 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#20963
<!-- 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 #
The test to ensure we don't bundle secrets/tokens is causing an error
like this:
```
NX Connection to Nx Cloud failed with status code ERR_BAD_REQUEST
```
e.g. https://staging.nx.app/runs/0IjxPh53dK
Likely due to validation errors now in place. We shouldn't be hitting Nx
Cloud from the test project, so I've renamed the variables to be
something that isn't used to connect to Cloud.
<!-- 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 -->
There's no way to disable sync generators registered in inferred tasks
by a Crystal plugin.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There should be a way to disable sync generators registered in inferred
tasks by a Crystal plugin.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-904 -->
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 -->
Calling remoteCache directly for the Nx cloud package causes issues with
how nx cloud deals with imports
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`remoteCache` is now a function call so that the nx cloud package
functions properly
## 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
When you specify the `envFile` property on a `nx:run-commands` executor,
values in that file don't override values from other loaded env files
(like `.env` and others that are loaded by the task runner).
## Expected Behavior
`envFile` contents should take precedence. The properties specified in
the `env` option should still override this.
## 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 #
<!-- 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 vite plugin's typecheck target is not using the tsconfig.lib.json
project when running typecheck for libs
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It should use the correct tsconfig
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27501
- feat(devkit): add util for determining the e2e web server info
- feat(vite): add util for determining the e2e web server info
- feat(webpack): add util for determining the e2e web server info
- fix(webpack): allow port override
- fix(devkit): e2e web server info util should handle target defaults
- feat(webpack): export the e2e web server info utils
- fix(vite): rename util
- fix(devkit): util should determine the devTarget for cypress
- fix(react): improve accuracy of e2e project generation
<!-- 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 logic for finding the correct targets and web addresses to use when
setting up e2e projects is flawed and missing some key considerations.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The logic is accurate and usage is simplified across plugins
Projects:
- [x] Angular
- [x] Expo
- [x] Next
- [x] Nuxt
- [x] Vue
- [x] Web
- [x] Remix
- [x] React
- [x] React Native
## 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 -->
When the name of a gradle project is overwritten by a different plugin,
the plugin throws an error creating dependencies.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The plugin uses the `CreateDependenciesContext` to get the name of a
project at the project root and uses that to create the dependency.
## 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 -->
--e2eTestRunner option is not working when create-nx-workspace with
preset react native
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
--e2eTestRunner option should be working when create-nx-workspace with
preset react native
## 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 -->
Output is still streamed sometimes when `--outputStyle static` is used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Output is not streamed when `--outputStyle static` is used.
## 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 -->
Imperatively running tasks does not return task results.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Imperatively running tasks returns task results along with the overall
status and the task graph
## 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 -->
N/A
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When running `npx nx login`, a file server should open and take you to
Nx Cloud to create a new personal access token.
When running `npx nx logout`, the user should be prompted with Nx Cloud
URLs of instances that they can revoke personal access tokens to.
## 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 -->
This repo uses pnpm `9.2.0`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses pnpm `9.8.0`
## 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 -->
We check the CLI property exists and if it's not `nx` we will use the ng
compat layer to run the migration.
If the CLI property does not exist, we check both if the migration is in
the `schematics` object on the `migrations.json` and if the contents of
the migration implementation contains an import from `@angular-devkit`.
The problem with the fallback is that if only types are imported from
`@angular-devkit` the import is stripped from the migration
implementation completely.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We had planned already to remove the fallback of reading the file
contents.
We had also planned to remove using the `cli` property to determine if
the migration needed the `ng compat layer`.
However, as the `cli` property is still useful for now for package's
that needed some manner to circumvent the flawed fallback logic, let's
continue to use it until v21.
Log a warning however if the `cli !== 'nx'` and it is placed in the
`generators` section of the `migrations.json` to provide ample time for
plugin developers to move them to the `schematics` property.
Fallback has been updated to whether or not the migration lives in
`schematics` and not flawed read file logic.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20282
<!-- 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/26889
… - update to yarn 2+
Closes#27588
## Current Behavior
See #27588
## Expected Behavior
See #27588
## Related Issue(s)
See #27588
Fixes #
Co-authored-by: @NgDaddy Paweł Twardziak <contact@ngdaddy.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 -->
This repo uses pnpm v8
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses pnpm v9
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: “JamesHenry” <james@henry.sc>
<!-- 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 order of the CI providers prompt does not match their popularity
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The order of the CI providers prompt matches their popularity
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Webpack-dev-server v5 changed the proxy config to only accept arrays.
This PR adds a migration for JSON proxy config files to automatically do
the conversion for users. If it's not a JSON format, then we log a
warning and point them to the v5 migration page.
<!-- 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 -->
React, Tailwind and Rspack is not working out of the box
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It works out of the box.
In tandem with nrwl/nx-labs#415
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27028
<!-- 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 -->
Nx build native isn't working correctly on windows, stating that
`window` is not a correct option for `cfg!`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the `windows` option for `cfg!` as stated by the error message
## 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 incremental builds with `@nx/angular:webpack-browser` the
dependent libraries need to be built.
However, there is no target default to force a build to build
dependents.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add a targetDefault and update docs to reflect this requirement
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26483
<!-- 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 -->
Unit tests are failing due to failing snapshots
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Snapshots are updated appropritately.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR ensures that `overrides` and `resolutions` are in the generated
package.json file as well. If they are missing, then using
`--frozen-lockfile` will fail due to mismatched overrides in the
lockfile.
Also adds a `skipOverrides` flag to the affected executors and plugins
-- same as `skipPackageManger` that was added previously.
Affected executors/plugins:
- `@nx/vite:build`
- `@nx/webpack:webpack`
- `@nx/remix:build`
- `@nx/next:build`
- `NxAppWebpackPlugin`
<!-- 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#26884
Updated doc:
https://nx-dev-git-docs-dependency-checks-lock-file-callout-nrwl.vercel.app/nx-api/eslint-plugin/documents/dependency-checks
<!-- 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#22442
<!-- 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 -->
This repo uses Nx `19.6.0-beta.6`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `19.7.0-beta.1`
## 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
The daemon is hard-disabled in docker, even if you try to explicilty
enable it using the `NX_DAEMON` env var.
## Expected Behavior
We should disable the daemon by default in docker but allow users to
opt-in using the env var. There might be issues that come with that but
since it's opt-in, it will be at their own risk.
## Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/14126
<!-- 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/27357
<!-- 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/26850
This PR adds a `nxCopyAssetsPlugin` for Vite to brings it to parity with
the other compilers/bundlers (tsc, swc, esbuild, rollup, and webpack).
When generate a lib with Vite (e.g.`nx g @nx/js:lib --bundler=vite` or
`nx g @nx/react:lib --bundler=vite`), we expect it to at least copy
`README.md` as an asset.
Note: Vite has support for copying assets from `public/` but that is
less flexible and more intended for apps, not libs.
<!-- 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#27351
<!-- 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
-->
Fixes login issue with nx Cloud due to switch to new nxCloudId auth
method
## 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 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 -->
The old remote caches are broken with the new db cache.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The old remote caches are working properly with the new db cache.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Current behavior:
`nx g create-package create-my-plugin --project my-plugin` fails because
`e2eProject` defaults to the root project.
Expected behavior:
`nx g create-package create-my-plugin --project my-plugin` succeeds.
We already do this for esbuild apps (e.g. express, fastify, koa), but we
don't do it for webpack (nest).
<!-- 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#27389
## Current Behavior
The [docs](https://nx.dev/nx-api/next/generators/library#unittestrunner)
say that you can use vitest as a unitTestRunner option. It also worked
when I tested with the following command:
```sh
nx g @nx/next:library shared --dir=modules/shared --style none --dry-run --projectNameAndRootFormat as-provided --component false --unitTestRunner vitest
```
But types say otherwise:
## Expected Behavior
Types will allow 'vitest' option for a unitTestRunner
## Related Issue(s)
none
Co-authored-by: Emily Xiong <xiongemi@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 -->
## 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
## Current Behavior
<!-- This is the behavior we have today -->
Nx has some persistent storage managed as separate files on disk. For
example, the local cache queries the file system for existing
directories.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx has a new more performant persistent storage via SQLite database. The
db is used for the following purposes now:
1. Storing task details of different hashes (This serves as reference
for other tables to get more information about a hash)
2. Storing a record of cached artifacts
3. Storing a history of tasks which have run
The cache in particular has the following benefits:
* It's faster, YMMV but it's definitely faster because it writes and
reads less from disk.
* It's able to track access of different cached artifacts
* It purges cached artifacts more intelligently by looking at when
artifacts were last ACCESSED rather than when they were CREATED. This
will also eliminate cache misses due to the cached artifacts being
purged simply because they were CREATED.
## 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 -->
The `withVerbose` util is only used in a few places.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `withVerbose` util is used throughout and also contains middleware
to default to the value in `process.env.NX_VERBOSE_LOGGING === 'true'`
## 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 -->
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
<!-- 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#27470
## Current Behavior
It's not possible to import `setRemoteDefinition` from `@nx/angular/mf`.
## Expected Behavior
Export `setRemoteDefinition` in `@nx/angular/mf`
<!-- 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 -->
Nx Cloud uses the nxCloudAccessToken to authenticate and provide
permissions access the cache.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Users who want to use Nx Cloud locally with a read-write token will need
to run `nx-cloud login` to generate a personal access token and have
`nxCloudId` in their nx.json. These two pieces of identification are
needed together to provide permissions to access nx cloud features.
By default users who do not have a personal access token/do not have an
Nx Cloud account will have 'read' permissions.
## 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 #
This PR adds a section to the `Adding Images, Fonts, and Files` React
recipe to show how to use SVGR with Vite.
With our Vite setup, we're keeping the configuration minimal so we don't
want SVGR out of the box.
<!-- 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#19282
## Currently
When we installed swc from the Next.js generator it installed an older
version that expected version of swc this caused the node & build
generator to not work.
## Expected
With these changes the version will be in sync with what the
`@nx/js:swc` executor is expecting. With that in mind the build should
now work as expected and by extension the serve target for custom server
as well.
fixes: #27222
<!-- 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 -->
https://nx.dev/getting-started/tutorials/gradle-tutorial#running-tasks
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
https://nx-dev-git-feat-graph-add-expand-targets-nrwl.vercel.app/getting-started/tutorials/gradle-tutorial#running-tasks
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Max Kless <maxk@nrwl.io>
fixes: #22450
<!-- 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 run any next target outside of nx the build will fail
because we only fallback for graph creation of if running prod server.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Targets should work if they are run outside of the Nx cli
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR adds `sourceMap` option to `@nx/rollup:rollup` executor and the
`withNx` util (for Project Crystal). The same option is used for
Webpack.
## 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#9199
This PR adds `skipPackageManager` option to several build executors in
order to disable generating the `packageManager` field in the resulting
`package.json` file. This field may be problematic on different
platforms so we want a way to work around it.
Affected executors:
- `@nx/webpack:webpack`
- `@nx/vite:build`
- `@nx/next:build`
- `@nx/remix: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` -->
<!-- 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#27027
<!-- 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 -->
Vite intentionally does not run typechecking on projects. They recommend
running `tsc --noEmit` separately.
The `@nx/vite/plugin` could make this easier by adding a `typecheck`
when it detects a `tsconfig` file in the `projectRoot`.
This can then be added to the build pipeline on CI. Or users can add it
to a `dependsOn` for the `build` target if they wish.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/vite/plugin` could make this easier by adding a `typecheck`
when it detects a `tsconfig` file in the `projectRoot`.
This can then be added to the build pipeline on CI. Or users can add it
to a `dependsOn` for the `build` target if they wish.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27501
<!-- 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 -->
Stories generation for React components only handles components
receiving a `props` argument typed with an `Interface`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stories generation for React components should handle receiving the
props with any name or as a destructured object and typed with an
`Interface`, a type literal definition, or an inline type literal. In
case it's a destructured object, it also supports having no type, in
which case the story args will have those properties with type
`unknown`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22053
<!-- 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 #
Allows consumers to use vitest 2 with the @nx/vite plugin.
closed#27259
<!-- 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 -->
Users cannot use Vitest 2 with @nx/vite.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Users can use Vitest 2 with @nx/vite.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27259
<!-- 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/27160
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 -->
Files which have special characters in the path cannot be imported.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Files which have special characters in the path can be imported.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27468
This PR expands the recipe for [Set Up App
Proxies](https://nx.dev/recipes/node/application-proxies). There is no
way for us to add proxy config automatically since `proxy.json` is
specific to our executor, and users should use the underlying tools'
proxy support instead.
Also adds an info for users using `--frontendProject` option in
crystalized workspaces.
Note: The proxy feature from Webpack and Vite allow more advanced use
cases, so it's preferred to the old `proxy.json` support anyway.
Preview:
https://nx-dev-git-docs-node-proxy-config-nrwl.vercel.app/recipes/node/application-proxies#set-up-application-proxies
<!-- 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#27321, #23158
We're showing `.cts` and `.mts` files as supported, but Webpack CLI will
not load them.
The language support is outlined here:
https://webpack.js.org/configuration/configuration-languages/#typescript
This PR removes those extensions to match what our plugin actually
infers from.
<!-- 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#27438
This PR ensures that we pass Vite config file to the programmatic
`startTest` API from Vitest. It fixes the issue with plugins not loading
as well as other issues with the config file not being used.
This mainly affects a custom `configFile` option being passed to the
executor. The previous fix to additionally load in `plugins` via
overrides is causing plugins to load twice when the Vite config file is
picked up by Vitest (e.g. #27500).
## 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#27500, #22001
<!-- 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 -->
Vite Plugin was originally only checking if the `lib` option was defined
in a vite config, and using that to avoid inferring serve targets.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Some libraries may still need a serve target, and if they have a server
config defined, the serve target should be inferred
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27370
<!-- 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 host application is never set as a candidate to share packages from.
Particularly in angular, this causes issues with the injection context
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Host application should be a valid option for sharing packages
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27162
<!-- 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 the introduction of App Router by NextJs, components may not live
in a `components` directory. Storybook config should reflect this.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stories path should be a glob from project root
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27233
Bump the NgRx package versions to ensure the `@ngrx/signals` package is
migrated correctly. That package version was out of sync with the rest
of the NgRx packages. Starting on v18.0.2, the package version is in
sync with the rest.
<!-- 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 #
… `launch-templates`
<!-- 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
When you use esbuild in 'browser' mode you have to provide all 'define'
attributes as environment variables and only with "NX_PUBLIC_" prefix
## Expected Behavior
Esbuild configuration has to work as it is described in docs. And prefix
feature has to work as an additional functionality
## Related Issue(s)
This issue will be fixed: https://github.com/nrwl/nx/issues/19106
Co-authored-by: Dmitrii Kamenskikh <dkamenskikh@devexperts.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 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>
Integrate a new Monorepo World banner with animations in the hero section using framer-motion. Updated the UI icons library to include Monorepo World icon and relevant SVG file.
Link the parallelism blog post to the actual reference document.
Currently the blog post shows up in a search for `parallelism` but the
actual reference does not. This link can help while we work on the
search.
This PR adds events to track engagement in our docs. Since we use a
scrollable `<div>` in our docs, the normal `scroll` events in GA do not
work.
A new `<ScrollableContent>` component is added that will do two things:
- Send `scroll_25`, `scroll_50`, `scroll_75`, and `scroll_90` events
whenever the user scrolls to 25%, 50%, 75%, of 90% of the content
- Optionally reset scroll top to zero whenever router changes (existing
behavior)
All of the places where we have content in a scrollable `<div>` is
replaced with `<ScrollableContent>`.
Note: 90% means user has reached the bottom, since it's not usually
possible to get to 100%.
<!-- 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 `@nx/dependency-checks` rule sometimes doesn't apply all identified
fixes and wrongly succeeds. ESLint performs multiple passes to try to
apply fixes, and in each pass the rule receives the updated source code
with the previously applied fixes. This allows merging different fixes,
but the `@nx/dependency-checks` rule always reads the `package.json`
file from the filesystem, caches it globally, and mutates it. It never
uses the updated source code provided in the rule context.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/dependency-checks` rule should apply all identified fixes [as
long as they don't
conflict](https://eslint.org/docs/latest/extend/custom-rules#conflicting-fixes).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27412
<!-- 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
<!-- 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 -->
Target Defaults set up for the Module Federation builds is incorrect or
missing.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Target Defaults for Module Federation builds is set up correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27448
## Current Behavior
see #27433
## Expected Behavior
see #27433
## Related Issue(s)
see #27433
Fixes #
- if compiler is `swc`, `@vitejs/plugin-react-swc` is being imported;
otherwise `@vitejs/plugin-react` is being imported
Co-authored-by: Emily Xiong <xiongemi@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 -->
`module-federation-ssr-dev-server` is calling `dev-server` builder
instead of `ssr-dev-server` builder
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`module-federation-ssr-dev-server` calls the correct builder
## 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 -->
New workspaces are generated with `@nx/angular` as a production
dependency even though the generated code does not use any runtime
helper from it.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
New workspaces should be generated with `@nx/angular` as a development
dependency. When generating a new MF host or dynamic MF application
(host or remote), the `@nx/angular` package should be moved to the
production dependencies because the generated code uses some runtime
helpers from it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27333
## 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
<!-- 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 -->
`nx:build-native` updates the typings which `graph-client:build-client`
uses. Not running it in the right order could result in a compilation
error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx:build-native` updates the typings which `graph-client:build-client`
uses so it depends on `nx:build-native`
## 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 #
<!-- 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 og images for the blogs are not being generated.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The og images for all blogs should be generated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- 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
Custom reporters are not usable because we enforce an enum on the schema
## Expected Behavior
Custom reporters can be specified
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@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 -->
Version plans, stable in the imminent `19.6.0` release, is undocumented.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Version plans is a documented feature.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
This commit integrates the "Explain with AI" feature into the Enterprise
and Pro plans for providing detailed explanations and insights for
failed task outputs. It also remove the Nx Workflows mention of the
pricing page. It also updates various links within the Hobby plan and
modifies plan table descriptions to reflect the accurate feature names.
<!-- 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 #
This PR adds a recipe for converting executor-based configuration to
inferred configuration.
The goal of the recipe is to guide users on what commands to run,
understand what changes were applied, and how to verify the migrations.
Preview:
https://nx-dev-git-docs-inferred-migration-recipe-nrwl.vercel.app/recipes/running-tasks/convert-to-inferred
[x] Link to this from Project Crystal concept page
[x] Mark recipe as related to Migration feature page
<!-- 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 #
---------
Co-authored-by: Isaac Mann <isaacplmann@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 -->
Current docs chat uses `gpt-3.5-turbo`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Docs are now using `gpt-4o-mini`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Simplify imports and content descriptions for engineering contact page. Added new Nx Cloud support section and adjusted links and icons in the contact links component for consistency.
<!-- 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 -->
When a style path is passed to the `NxAppWebpackPlugin` we normalize it
to the `projectRoot`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When a style path is passed to the `NxAppWebpackPlugin` if it is already
normalized i.e. it is relative to the project we should assume the path
is correct.
## 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 -->
Migrations are naively setting `serve-static` or `preview` as the target
without checking if that target exists
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Check if the target exists based on executor usage as a last port of
call, and use the name of the target it is found on
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Closes https://github.com/nrwl/nx/pull/27439
<!-- 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 -->
This repo uses Nx `19.5.0-beta.5`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `19.6.0-beta.6`
## 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 -->
Projects which have neither webpack or vite configs were assumed to be
vite.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Projects which have neither webpack or vite configs are not migrated.
## 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, if you have a SSR Mfe project and you run multiple ssr
projects using the 'serve' target it would fail due to conflicting ports
unless explicitly set `PORT=4202 node dist/acme/server.js`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Now the default is to have the server take the same port as it was
generated with so that if you run multiple server apps that depends on
other apps in dev mode there will be no conflicts.
## 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 #
<!-- 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#27175#26914#22941#26531
<!-- 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 -->
Nx Agents numbers are calculated by using the dynamic changeset feature,
where the agent counts are hardcoded.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx Agents are spawned using the "auto" keyword.
## 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 -->
Project graph error handling is always expecting the `message` property
to exist on the error. This may not always be the case.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Only attempt to run `indexOf` if the `message` property exists.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27078
<!-- 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 the `@nx/jest/plugin` some jest utils are imported from the location
of the `jest` package to ensure the plugin uses the same utils the
`jest` package would use. This is not entirely correct because the
`jest` package doesn't directly depend on those utils, so they might not
be resolved correctly.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/jest/plugin` should import those jest utils from the location
of the `@jest/core` package resolved from the `jest` package location,
to ensure the plugin uses the same utils the `jest` package would use.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Update the `nx sync` output when there are changes to sync (currently
there's no output)
- Update the `nx sync` and `nx sync:check` output when there are no
changes to sync (currently there's no output)
- Handle exiting the prompt for applying sync generator changes when
running tasks
<!-- 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 -->
Currently, the default for remotes is to server them as development.
Which means a separate node process for each remote that is inside the
workspace.
This does not scale well and can lead to out of memory exceptions.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Remotes will start as static by default, which allows for better scaling
as the remotes increase.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
TODO
- [ ] Migrations
- fix(angular): turn mf dts off by default #27198
- fix(react): turn mf dts off by default
- fix(react): add migration to turn module federation dts off by default
- fix(angular): add migration to turn module federation dts off by
default
<!-- 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 -->
Nx already provides Typing support for Module Federation projects. The
`@module-federation/enhanced` package has typing support turned on by
default but it can be problematic.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Turn off `@module-federation/enhanced` own dts plugin providing typing
support in favour of Nx's own typing support
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27198
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
Assets are not copied to the dist folder after running @nx/next:build
## Expected Behavior
Assets should be copied to the dist folder after @nx/next:build
## Related Issue(s)
https://github.com/nrwl/nx/issues/26900
Fixes #
Fix the order, and wrong number of parameters call to
createWebpackConfig()
---------
Co-authored-by: Nicholas Cunningham <ndcunningham@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 -->
## 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 -->
Daemon is stopped.. but then started in the postinstall process. The
results might be premature and cause issues for subsequent commands.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Daemon is stopped... and disabled in postinstall process. This won't
cause issues for subsequent commands.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
The `next/babel` and `babel-jest-preset` Babel presets bring in
conflicting plugins. This will cause Jest tests to fail.
This PR updates our own `@nx/next/babel` preset to remove the
conflicting plugin from `next/babel`. Import assertions are out of date
anyway, and we should be using import attributes (which
`babel-jest-preset` supports).
See: https://github.com/tc39/proposal-import-attributes
<!-- 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 #
<!-- 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 #
- Deprecate the `@nx/angular` data persistence operators in favor of
importing them from `@ngrx/router-store/data-persistence`. The operator
will be removed from the `@nx/angular` package in Nx v21.
- Update the deprecation message for `@nx/angular/testing` helpers to
communicate that they will be removed in Nx v21.
<!-- 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#27322
<!-- 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 -->
We're only checking for Vite and adding `preview` as a string on its own
when running the migration to update cypress.config.ts
ciWebServerCommand
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Check both Vite and Webpack and update according to plugin if one exists
## 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
The syntax to test a single file is different when using the jest
executor versus the jest cli
```sh
jest <file>
# vs
nx test project --testFile <file>
```
## Expected Behavior
I would expect the jest executor to support a single positional argument
as well
```sh
nx test project <file>
```
This is one of the common questions/complaints that I hear from
developers when transitioning from our standalone apps to our monorepo
This change supports both syntaxes so that this is not a breaking change
and prints a warning when both are used
<!-- 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 an error when `updateFilesInContext` is called without a
`workspaceContext` available.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`updateFilesInContext` ensures there is a `workspaceContext` available.
## 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 -->
Importing other projects/ repositories into an Nx workspace is a natural
part of the Nx adoption story. However, there is no easy built in way of
handling this while maintaining `git` history.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx import` is a new command which allows teams to merge code from other
repositories into a Nx workspace.
https://asciinema.org/a/oQiA9qOvA2z85AQvVJ5QRVTp1
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Otherwise, the migration will fail with an error.
<!-- 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 -->
When the host uses SSL, the remote proxies are not created on a secure
server.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When the host uses SSL, the remote proxies should be created on a secure
server
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27360
<!-- 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 the `ciWebServerCommand` depends on a target that exists on the e2e
project, the `dependsOn` is still added with `^` expecting the project
to be an implicit dep.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The migration should handle when e2e project depends on itself for the
`e2e-ci` command
## 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 -->
Migration is not correctly finding the intended target name to use for
the config file
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Migration should find the correct target name for the config file
## 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 -->
`withModuleFederation` is overwriting `config.optimization` rather than
merging it.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`config.optimization` should be merged
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27201
<!-- 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 -->
`webpack-dev-server` dependency is not up to date.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`webpack-dev-server` dependency is up to date
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27310
<!-- 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 connecting via NxCloudId, the resulting Id would not be written to
nx.json
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Correctly writes nxCloudId to nx.json after running `npx nx g
connect-to-nx-cloud`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- respect `pnpm` version declared in root `package.json`
- improve performances when installing node modules
- add troubleshooting instructions in `CONTRIBUTING.md` to help solve
common issue related to outdated `GLIBC` version
Previously the check would see if the version of storybook is less than
7 and would throw an error. This causes an issue when testing canary
releases of storybook since they are labeled 0.0.0-[pr-info...]
Update pleaseUpgrade text
One of the checks is to see if storybook is less than 7. The text is
updated so it matches for the very unlikely scenario that someone with
version 5 or lower runs this plugin.
<!-- 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
The storybook plugin throws and error if the storybook version [is less
than
7](https://github.com/nrwl/nx/blob/239f47c8d0eaf4df191acf1844b87e333b956e84/packages/storybook/src/executors/storybook/storybook.impl.ts#L17-L20).
```ts
const storybook7 = storybookMajorVersion() >= 7;
if (!storybook7) {
throw pleaseUpgrade();
}
```
When testing a canary release for storybook the version is 0.0.0-[pr
info] so when spinning up storybook it will display:
```
> nx run component-lib:storybook
NX
Storybook 6 is no longer maintained, and not supported in Nx.
Please upgrade to Storybook 7.
Here is a guide on how to upgrade:
https://nx.dev/nx-api/storybook/generators/migrate-7
```
## Expected Behavior
Storybook spins up when running a canary release. Modifying the version
check to not include v0 solves the problem:
```ts
const sbVersion = storybookMajorVersion();
const sbLessThan7 = sbVersion < 7 && sbVersion > 0;
if (sbLessThan7) {
throw pleaseUpgrade();
}
```
then running Storybook with that modification:
```
╭──────────────────────────────────────────────────────────────────────╮
│ │
│ Storybook 0.0.0-pr-28752-sha-a65743e5 for react-webpack5 started │
│ 307 ms for manager and 7.73 s for preview │
│ │
│ Local: http://localhost:4402/ │
│ On your network: http://192.168.4.41:4402/ │
│ │
╰──────────────────────────────────────────────────────────────────────╯
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27277
<!-- 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 running `nx list`, if a plugin has no capabilities (i.e.
`@nx/eslint-plugin`), it will show brackets with an empty list of
capabilities.
```shell
$ nx list
NX Installed plugins:
@nx/eslint (executors,generators)
@nx/eslint-plugin ()
@nx/js (executors,generators)
@nx/workspace (executors,generators)
nx (executors,generators)
```
https://asciinema.org/a/XxJjVyoIoQgjj8fsM6fb0TXQT
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When running `nx list`, if a plugin has no capabilities (i.e.
`@nx/eslint-plugin`), it won't show brackets with an empty list of
capabilities.
```shell
$ nx list
nx list
NX Installed plugins:
@nx/eslint (executors,generators)
@nx/eslint-plugin
@nx/js (executors,generators)
nx (executors,generators)
```
https://asciinema.org/a/CHPkcO6hRURZRuBRJxUSRayGx
## Related Issue(s)
N/A
<!-- 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
We communicate with sockets during graph construction. Its possible for
the assigned path to be too long and this can cause issues. The issues
present as a strange error with no helpful information.
## Expected Behavior
There is a helpful error message, and post-install is not interrupted
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27040
Allow usage of Jest v30 pre-release version in preparation for the
upcoming stable release.
Note that this PR is not intended to change any current generator for
creating/setting up projects with Jest 30. That will be done when Jest
v30 becomes stable.
<!-- 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 NXP-860 -->
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
We execute `execSync('./nx ...')` inside nx init
## Expected Behavior
We use `runNx`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
type(docs): fix typo in npm-workspaces.md
Someone's cat slept on their "G" key. `creggggggate` -> `create`
## Current Behavior
Typo exists:
> Does the "lint" script creggggggate any outputs? - Enter nothing
## Expected Behavior
Typo should not exist:
> Does the "lint" script ~~creggggggate~~ create any outputs? - Enter
nothing
## Related Issue(s)
N/A
Fixes #
N/A
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
updates
- Nx GitHub repository readme
- Generated readmes for all the available Nx presets (via CNW). Here's a
snapshot of the new readme for each preset that can be used:
https://github.com/juristr/nx_readme_updates/
---------
Co-authored-by: FrozenPandaz <jasonjean1993@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 -->
## 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 #
Change wrong number in nx-cloud docs which determine number of agents
for small changes which is 3 not 1
The workflow is:
```yaml
distribute-on:
small-changeset: 3 linux-medium-js
medium-changeset: 6 linux-medium-js
large-changeset: 10 linux-medium-js
```
but docs says:
`Now PRs that affect a small percentage of the repo will run on 1 agent,
.....`
Which is not matching the workflow and it should be 3 not 1
https://nx.dev/ci/features/dynamic-agents#dynamically-allocate-agents
<!-- 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 cleanup function is called **immediately** when the file is imported
if it is placed outside of the exported function in jest global setup
file.
<img width="1202" alt="Screenshot 2024-08-02 at 7 45 12 AM"
src="https://github.com/user-attachments/assets/caa9cc2b-9212-4c91-b557-d44e6ba7ae05">
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The cleanup func in jest global setup file, should be call inside the
default export function.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A!
<!-- 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)
https://github.com/nrwl/nx/discussions/23105#discussioncomment-9281248
Fixes #
---------
Co-authored-by: MilanKovacic <9189985+MilanKovacic@users.noreply.github.com>
The migration file is there but missing in `migrations.json`.
<!-- 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 -->
Currently, when you create an app we always show `nx connect` regardless
if the workspace has already setup Nx Cloud.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Now, we:
- show `nx connect` if you have no opted into Nx Cloud
- show a CTA to finish your setup if you have setup your workspace on Nx
cloud but have yet to claim it
- show a CTA to learn more if your workspace has been claimed in Nx
Cloud
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- 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 #
Same copy of target default is shared along projects and is mutated,
leading to wrong task graph. Occur only when running without daemon,
probably because the daemon communication cause cloning by unmarshalling
the object.
Fix by deepcloning `targetDefaults`
Fixes https://github.com/nrwl/nx/issues/27346
This PR adds `convert-to-inferred` generators to convert React Native an
Expo apps using executors to use the corresponding inference plugins.
Also:
1. Fixes casing for `@nx/react-native/plugin` so it is correctly set as
`upgradeTargetName` not `upgradeTargetname`
2. Migration for the above fix for existing projects
<!-- 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 inputs for `build-native-wasm` and other native tasks are not set
properly resulting in incorrect cache hits/misses.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The inputs for `build-native-wasm` and other native tasks are set
properly resulting in correct cache hits/misses.
## 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 -->
Current `napi-build` dependency causes some functions not to export
properly for wasm.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`napi-build` exports all functions properly.
## 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 #
The current `useLegacyNxPlugin` has two issues:
1. It doesn't pass the configuration object, but rather the compiler
instance.
2. It doesn't handle async correctly
This PR resolves both issues.
<!-- 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
Legacy plugins don't actually work.
## Expected Behavior
Legacy plugins work.
## 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 #
<!-- 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
Plugin messages timeout if they don't hear back in 5 minutes. This adds
timeouts to createNodes and other plugin APIs invoked during graph
construction, which didn't previously exist
## Expected Behavior
Increased timeout + easy configuration via env var
## 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 #
<!-- 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 -->
We don't have information about which CI providers that people are
using.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We collect information about which CI providers people are using so we
can use it to inform which CI provider we create better integration with
next.
## 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
-->
Instead of `nxCloudAccessToken`, users can now connect to nx-cloud with
`nxCloudId`. This value will also default the runner to the cloud
runner.
Also modified the `connect-to-nx-cloud` generator such that it hits a
new API endpoint to grab a workspace's nxCloudId instead of access
token. (This feature is gated).
## 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
There is a cache that maps target pattern -> dependency configuration,
but the dependency configuration contains more than just the target
name. This results in retrieving cached dependency configurations that
contain the wrong projects to run.
## Expected Behavior
The cache maps target pattern -> target names, which we can then map to
the full dependency configuration with the extra info we know.
## 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
We don't infer scripts if any info for that target is present in
project.json. This results in the target dissapearing if the user tries
to modify the inferred target by providing info in project.json, for
example by providing dependsOn or similar.
A minimal repro of the issue looks something like this:
> packages/foo/package.json
```json
{
"name": "foo",
"scripts": {
"build": "echo build"
}
}
```
> packages/foo/project.json
```json
{
"name": "foo",
"targets": {
"build": {
"dependsOn": []
}
}
}
```
Attempting to run `nx build foo` results in "Cannot find configuration
for task foo:build", as we remove the target for not having an executor.
## Expected Behavior
The target remains as it can run the script, so we have to infer the
script to begin with.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27258
<!-- 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 -->
A/B testing is being done on the message for the onboarding flow.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The onboarding flow will be the one which performed the best during A/b
testing:
## 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 -->
The generators is broken when run directly with `nx g
connect-to-nx-cloud`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The generator is not broken when running it directly via `nx g
connect-to-nx-cloud`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Fixing 3 issues when storing the page sections:
1. The heading of a node can be like this: `title: 'Angular Monorepo
Tutorial - Part 1: Code Generation' description: In this tutorial you'll
create a frontend-focused workspace with Nx`. We only want to keep the
`title` part.
2. Some headings have `{% highlightColor="green" %}`. We want to remove
that from the heading of the page section (and the link text)
3. There's an [error in `tags.json` where the path is
incorrect](https://github.com/nrwl/nx/blob/master/docs/generated/manifests/tags.json#L126).
We want to fix that on the fly, so that the embeddings script finds the
correct pages.
<!-- 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 -->
Our docs state that we're abstracting Webpack's ModuleFederationPlugin.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The docs state that we're abstraction `@module-federation/enhanced`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Link on Nx Cloud is broken. This ensures the link is fixed also for
OnPrem customers.
## 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#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## @nx-extensions/helm
This Nx plugin delivers comprehensive first-class support for Helm
charts, focusing on streamlining the processes of chart generation,
packaging, and publishing. By integrating Helm with Nx, the plugin
enhances workflow automation, reduces manual steps, and ensures
consistent deployment practices across projects.
**Goal/Issues Addressed**
The primary goal of this plugin is to simplify and standardize the
management of Helm charts within the Nx ecosystem. It addresses several
issues:
Automation: Automates the creation, packaging, and deployment of Helm
charts.
Consistency: Ensures uniform practices across different projects and
teams.
Efficiency: Reduces the manual effort required for managing Helm charts.
**Focus**
The plugin is focused on tooling and behavior:
Tooling: Provides generators and executors for Helm chart management.
Behavior: Enhances the developer experience by integrating Helm
operations into the Nx workflow.
**Features**
Generators: Create new Helm charts with standardized templates.
Executors: Package and publish Helm charts directly from the Nx
workspace.
**Usage**
While this plugin is newly developed, it is intended for use by
development teams who utilize Helm and Nx for their DevOps workflows.
**Author**
This plugin is authored by me
<!-- 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 -->
Nx Cloud is excluded from the options for a new workspace.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx Cloud is not excluded from the options for a new workspace.
## 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 -->
The Nx Cloud token is generated after the workspace and preset have been
generated. This makes it hard to use the Nx Cloud token for generating
the workspace and preset.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The Nx Cloud token is generated in the workspace creation. This makes it
easier to use the Nx Cloud token during the workspace creation process.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Old cache entries are not removed because the path to the cache is
wrong.
It throws a silent error `no such file or directory, scandir
'"PATH_TO_PROJECT/.nx/cache"/terminalOutputs'`
closed#27206
<!-- 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, in Next.js 14 the `fetch` API is cached by default, which we
do not want on the careers page.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Each visit to the careers page should do a fresh API call.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- fix(vite): preview should dependOn build
- fix(react): playwright should use vite preview
- fix(vue): playwright should use vite preview
- fix(web): playwright should use vite preview
- chore(testing): add e2e test
<!-- 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, `playwright` uses the `vite serve` command when setting up
the web server to run the e2e tests against.
The `vite preview` command/target should also depend on `vite build`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`playwright` should use the `vite preview` command when setting up the
web server
`vite preview` targets add a `dependsOn["build"]`
Ensure `serve-static` has a dependsOn: ['build']
Cypress should use the `ciBaseUrl` if it exists when running the
`e2e-ci` targets
Migrations for Playwright and Cypress to use serve-static and preview
correctly
## 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 #
<!-- 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
Pattern matched target defaults are not documented
## Expected Behavior
There is some documentation explaining target defaults w/ glob patterns
## 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 -->
The nx cloud access token is not written to nx.json during
`create-nx-workspace`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The nx cloud access token is written to nx.json during
`create-nx-workspace`
## 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 #
---------
Co-authored-by: Juri <juri.strumpflohner@gmail.com>
small PR to adjusts the position of the video button on the npm
workspaces tutorial.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
<img width="853" alt="Screenshot 2024-08-01 at 11 16 46"
src="https://github.com/user-attachments/assets/a3d0c559-a7f1-46a9-a1e7-2b2aae8bbc86">
## 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's an error that leaks through during `create-nx-workspace`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The error is ok and it is hidden during `create-nx-workspace`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…ent it
<!-- 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 -->
Target description is not shown in the PDV.
Also, being able to set a description in `project.json` is not in the
schema nor is it documented.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Target descriptions are shown in the PDV.
Also, being able to set a description in `project.json` is in the schema
and documented on
https://nx-dev-git-metadata-docs-nrwl.vercel.app/project-configuration#target-metadata
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/19355
<!-- 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 #
<!-- 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 -->
The onboarding message during `create-nx-workspace` is not ideal.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We are A/b testing some options for the `create-nx-workspace` onboarding
message.
## 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#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
[x] Run some kind of automated e2e tests in your repository
[x] Include `@nx/devkit` as a `dependency` in the plugin's
`package.json`
[x] List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## nx-github-pages
Provides an executor to publish built artifacts to github pages and a
configuration generator to set it up.
<!--
Describe what your plugin is and what is its goal or issues it
addresses. If you don't provide a description, we will not merge your
PR.
Is it focused on a technology, tooling or behaviour? Does the plugin
provide generators, executors or graph support?
Do you know who is already using the plugin? Mention who is the author
of the plugin.
-->
<!-- 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 -->
This feature is not yet documented...
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Document wildcard support in `dependsOn` field for project
configurations.
Note: Reading through the PR below that impls. this wildcard support, I
couldn't quite figure out if it was actually able to also work in case
of object syntax and whether this will also work for `targetDefaults`...
so if you know any better, please lemme know so I can update this PR 🙏
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
documents #19611
<!-- 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 #
Our assets are generated as flat assets in dist, which allows using
assets from workspace libs. This prevents users from having different
assets with the same filename (e.g. `foo/image.png` and
`bar/image.png`). This will error out in the dev server with conflicting
filenames.
We cannot use `[path][name]` because of assets that are outside of the
app folder (e.g. `../../libs/ui/src/assets/image.png`). Thus the best
option is to include hash.
Note: Also re-enabled the e2e tests for `react.test.ts` file since it is
now using Playwright instead of Cypress.
## Current Behavior
Assets with the same filename will error in dev-mode.
## Expected Behavior
Assets with the same filename works.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18272
<!-- 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 #
<!-- 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
Calling `updateProjectConfiguration` on a package json based project
fails
## Expected Behavior
Calling `updateProjectConfiguration` on a package json based project
works
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26530
<!-- 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
There is no option to exclude dependent tasks when running Nx.
## Expected Behavior
There is a flag, `--exclude-task-dependencies`, to exclude task deps
from running. This is inline with other tools:
- [dotnet
cli](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-build#:~:text=%2D%2Dno%2D-,dependencies,-Ignores%20project%2Dto)
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18053
Hello!
I fixing issue related to nx project with enhanced webpack config.
I created this repository to reproduce the bug:
https://github.com/NicolasBelliard/nx-enhance-example
## Current Behavior
When created an Nx repository with nx enhanced config, we faced the
current issue when we try to build the application.
```
> nx run nx-enhance:build
> webpack-cli build --node-env=production
[webpack-cli] TypeError: Cannot read properties of undefined (reading 'nodes')
at calculateProjectDependencies (/home/test/dev/nx-enhance/node_modules/@nx/js/src/utils/buildable-libs-utils.js:24:30)
at calculateProjectBuildableDependencies (/home/test/dev/nx-enhance/node_modules/@nx/js/src/utils/buildable-libs-utils.js:20:12)
at NxTsconfigPathsWebpackPlugin.handleBuildLibsFromSource (/home/test/dev/nx-enhance/node_modules/@nx/webpack/src/plugins/nx-typescript-webpack-plugin/nx-tsconfig-paths-webpack-plugin.js:37:111)
at NxTsconfigPathsWebpackPlugin.apply (/home/test/dev/nx-enhance/node_modules/@nx/webpack/src/plugins/nx-typescript-webpack-plugin/nx-tsconfig-paths-webpack-plugin.js:17:14)
at createCompiler (/home/test/dev/nx-enhance/node_modules/webpack/lib/webpack.js:78:12)
at create (/home/test/dev/nx-enhance/node_modules/webpack/lib/webpack.js:145:16)
at webpack (/home/test/dev/nx-enhance/node_modules/webpack/lib/webpack.js:153:47)
at WebpackCLI.f [as webpack] (/home/test/dev/nx-enhance/node_modules/webpack/lib/index.js:73:16)
at WebpackCLI.createCompiler (/home/test/dev/nx-enhance/node_modules/webpack-cli/lib/webpack-cli.js:1785:29)
at async WebpackCLI.runWebpack (/home/test/dev/nx-enhance/node_modules/webpack-cli/lib/webpack-cli.js:1877:20)
Warning: command "webpack-cli build --node-env=production" exited with non-zero status code
Process finished with exit code 1
```
## Expected Behavior
No error and the build is working.
## Related Issue(s)
https://github.com/nrwl/nx/issues/26303
When we generate a nest application and supply the `--docker` flag it
should generate a DockerFile.
<!-- 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, no DockerFile is created.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A DockerFile to be created.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#17343
We currently rely on the TS behavior of matching `d.ts` files based on
the `.js` file names. e.g. `foo.js` matches `foo.d.ts`. However, it
isn't working for all tools so we should explicitly set it.
Most modern packages are still setting it even though it is not
technically needed. e.g.
[Nuxt](https://unpkg.com/browse/nuxt@3.12.4/package.json)
Note: If both ESM and CJS are present, then prefer `*.esm.d.ts` files
since the generated types are in ESM format.
## Current Behavior
`exports` entries are missing `types` field
## Expected Behavior
`exports` entries have `types` field set
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18835
<!-- 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 -->
In Yarn and PNPM Workspaces, the `nxViteTsPaths`'s `resolveId` is not
called because Vite has already tried to resolve the module.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure the `nxViteTsPath`'s logic is run before vite's internal
resolver.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20520
<!-- 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 -->
Module Federation setups using `/*` wildcards in ts path mappings error
out as they cannot resolve the module.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`/*` ts path mappings should still allow modules to be resolved
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26765
<!-- 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. -->
"Hence we can easily import them into other libraries and our Angular
application. As an example, let's use the pre-generated
ProductsComponent component from our libs/products library."
It's a tutorial providing a React project example, I think "Angular" is
typing wrong
## Current Behavior
Hence we can easily import them into other libraries and our **Angular**
application. As an example, let's use the pre-generated
ProductsComponent component from our libs/products library.
## Expected Behavior
Hence we can easily import them into other libraries and our **React**
application. As an example, let's use the pre-generated
ProductsComponent component from our libs/products library.
This PR ensures that all dependencies are built before serving the Node
app.
<!-- 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
If users don't manually run `nx build <app>` first, then the
dependencies won't build because when `@nx/js:node` executor runs, it
uses `runExecutor` which skips dependencies.
## Expected Behavior
Set `dependsOn` on the `serve` target so run `<app>:build` first, which
would ensure dependencies are all built. Also add
`runBuildTargetDependencies: false` to the target options for
visibility, so users could toggle it on if they want to re-build deps
whenever there is a change (during watch). The option will slow things
down, so we still want it to be `false` by default.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18964
<!-- 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 #
The current `@nx/react:app` generator does not take the `--js` option
into account. There are two problems:
1. `index.html` includes `main.tsx` not `main.jsx`.
2. `.js` files with JSX are invalid in Vite, and must be named `.jsx`.
This PR adds a new option to the `toJS` devkit util to preserve `.jsx`
rather than renaming them to `.js`. The vast majority of non-Vite React
projects will use `.js` and not `.jsx` (e.g. Next.js, Expo, Remix, etc.)
so we just want to apply this change to Vite only for now.
In the future we could enhance React generators to support `--jsx`, for
example.
## 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#20810
Introduced a new AI section with dark/light image support. Refactored component exports from arrow functions to named functions for better readability and consistency. Included minor adjustments to class names and style properties.
This PR fixes an issue where our `withNx` function for Next.js is
compiled with inlined `workspaceRoot` (to support container
environments). On Windows, we write the `.nx-helpers/with-nx.js` with
the following:
```js
workspaceRoot: 'C:\Users\user\projects\app',
```
The `\u` character result in a Node error: `Invalid Unicode escape
sequence`.
The fix is to escape `\` as `\\`, so when the file is written, the path
is valid and does not cause unicode errors.
<!-- 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#18824
<!-- 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
No docs for new config flag
## Expected Behavior
Docs 🎉
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22259
<!-- 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
Some plugin docs don't make sense after project name and root changes
## Expected Behavior
They've been touched up
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#25191
<!-- 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
`documentation` is not cacheable. It is reran everytime someone tries to
push, including the following flow:
- git push, fails as docs changes found
- git commit -am "chore(repo): add docs"
- git push, runs full docs cycle again in pre-push hook
## Expected Behavior
`documentation` is cacheable, and avoids rerunning when no fs changes
are made
## 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 -->
The package manager is detected based off of the relative `cwd` which in
most cases is `''`. This incorrectly goes off of the `cwd` of the
command rather than the location of the `package.json` file being
modified.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The package manager is detected based off the absolute path of the
directory containing the `package.json` file being modified. So if this
is the root, it will detect the package manager at the root rather than
the `cwd`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/19831
<!-- 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 -->
having some command without npx before
````
nx .....
````
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Have npx on all command
````
npx nx .....
````
Co-authored-by: pikooli <>
<!-- 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 #
Taken from: https://github.com/nrwl/nx/pull/26560
## Currently
When you enter a space in the idea form it gets trimmed so users are
unable to add a proper sentence when submitting an idea.
## Expected
Users should be able to add spaces as they feel is necessary without
being restricted.
---------
Co-authored-by: Sarthak <130341942+Sarthak0085@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
<!-- This is the behavior we have today -->
agents.yaml are currently using a pinned version of v3.6
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
agents.yaml are using v4 of the workflow steps
## 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 -->
Plugins were not being loaded by vitest executor when calling
`startVitest` when using a vite config file with a custom name.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Correctly load the plugins found in the resolved config file, regardless
of the config file name
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22001
<!-- 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 -->
`time` crate is locked to a version which fails to compile.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`time` crate is updated to a version which does not fail to compile.
## 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#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 -->
The `host` and `remote` generators do not have an option to skip package
install.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add the `skipPackageJson` flag to the remote and host generators
## 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#8928
## Current Behavior
<!-- This is the behavior we have today -->
`axios@^1.6.0` is used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`axios@^1.7.2` is used
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26538
<!-- 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
* chore(repo): migrate workspace to Nx 15.8.5
* chore(gatsby): fix init generator after migration
* chore(repo): remove Jest snapshot format
---------
Co-authored-by: Philip Fulcher <philipfulcher@Philips-MacBook-Pro-2.local>
"mutantdino.resourcemonitor"// to monitor cpu, memory usage from the dev container
],
"settings":{
"debug.javascript.autoAttachFilter":"onlyWithFlag"// workaround for that issue: https://github.com/microsoft/vscode-js-debug/issues/374#issuecomment-622239998
"debug.javascript.autoAttachFilter":"disabled"// workaround for that issue: https://github.com/microsoft/vscode-js-debug/issues/374#issuecomment-622239998
}
}
}
},
// To improve disk performances when installing node modules
// See https://code.visualstudio.com/remote/advancedcontainers/improve-performance
@@ -49,15 +49,33 @@ The repo comes with a preconfigured `devcontainer.json` file (located in `.devco
If you open the repo in [Github Codespace](https://github.com/features/codespaces), it will also leverage this config file, to setup the codespace, with the same required tools.
> 💡 **Troubleshooting**
>
> If you are having issues when running Nx commands like `build`, `test`... related to the version of `GLIBC`,
> it probably means the version that is installed on the devcontainer, **is outdated** compare to the minimum version required by Nx tools.
>
> You can check currently installed version by running the following command, in a terminal within the container:
>
> `ldd --version`
>
> Then, try updating the base image used in [devcontainer.json](.devcontainer/devcontainer.json) and rebuild it, to see if it solved the issue.
>
> Current base image is `"mcr.microsoft.com/devcontainers/typescript-node:20-bookworm"` which is based on `Debian-12 (bookworm)`,
> which comes with `GLIBC v2.36` pre-installed (Nx tools currenlty requires `GLIBC v2.33` or higher).
## Building the Project
> Nx uses Rust to build native bindings for Node. Please make sure that you have Rust installed via [rustup.rs](https://rustup.rs)
> If you have VSCode + Docker, this can be automated for you, see [section](#development-workstation-setup) above
> 💡 Nx uses `Rust` to build native bindings for Node. Please make sure that you have Rust installed via [rustup.rs](https://rustup.rs)
> If you have `VSCode` + `Docker`, this can be automated for you, see [section](#development-workstation-setup) above
After cloning the project to your machine, to install the dependencies, run:
```bash
pnpm i
pnpm install
// or prefer...
pnpm install --frozen-lockfile // if you haven't changed any dependency
```
To build all the packages, run:
@@ -345,7 +363,7 @@ Including the issue number that the PR relates to also helps with tracking.
```plain
feat(angular): add an option to generate lazy-loadable modules
`nx generate lib mylib --lazy` provisions the mylib project in .eslintrc.json
`nx generate lib libs/mylib --lazy` provisions the mylib project in .eslintrc.json
Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.
Nx is a build system, optimized for monorepos, with plugins for popular frameworks and tools and advanced CI capabilities including caching and distribution.
to add Nx to your existing workspace to get faster task scheduling, caching and more. More [in the docs](https://nx.dev/getting-started/intro#try-nx-yourself).
## Learn about CI with Nx Cloud
[Nx Cloud](https://nx.dev/nx-cloud) connects directly to your existing CI setup, helping you scale your monorepos on CI by leveraging [remote caching](https://nx.dev/ci/features/remote-cache?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo), [task distribution across multiple machines](https://nx.dev/ci/features/distribute-task-execution?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo), [automated e2e test splitting](https://nx.dev/ci/features/split-e2e-tasks?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo) and [automated task flakiness detection](https://nx.dev/ci/features/flaky-tasks?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo)
Connect your existing Nx workspace with
```
npx nx connect
```
Learn more in the [Nx CI docs »](https://nx.dev/ci/intro?utm_source=nxrepo&utm_medium=readme&utm_campaign=nxrepo)
## Useful links
- [Our docs](https://nx.dev/docs)
- [Our blog](https://nx.dev/blog)
- [Our community discord, live stream,...](https://nx.dev/community)
"description":"Nx plugin to build OCI containers with Docker, Podman or Kaniko.",
@@ -452,7 +457,7 @@
{
"name":"@naxodev/nx-cloudflare",
"description":"Nx plugin for Cloudflare, in particular Cloudflare workers. It allows to generate build and run Cloudflare workers in your Nx workspace.",
@@ -32,7 +32,6 @@ We also have different audiences in mind when writing docs:
👦 Intermediate User
- They know how to create an Nx repo or add Nx to an existing repo
- They have heard the terms integrated and package-based
- They know what a project is and how to make one
- They understand how to run a task and the basics of caching
- They can launch the graph
@@ -94,14 +93,14 @@ Your content goes here.
{% /callout %}
```
#### Disclosure
#### Deep Dives
A disclosure can be used for less important information that is initially collapsed.
These are special callouts that are collapsed with the intention of containing more deep-dive information about the topic which isn't required to understand right away.
```markdown
{% disclosure title="string" %}
Your content goes here.
{% /disclosure %}
{% callout type="deepdive" title="string" %}
Your deep-dive content goes here.
{% /callout %}
```
#### Cards
@@ -417,6 +416,28 @@ Embed an Nx Graph visualization that can be panned by the user.
{% /graph %}
````
## Generating API Documentation
To generate API documentation for the codebase and update the menu for the docs on nx.dev, you can run:
```
nx documentation
```
This will happen automatically in a `git push` hook, so you'll be reminded if you forget.
### Generate API Documentation for Ocean Plugins
To generate API documentation for plugins in the ocean repository, run the `nx documentation` command with the `NX_OCEAN_RELATIVE_PATH` environment variable set to the relative path to your checked out copy of the ocean repo.
```
NX_OCEAN_RELATIVE_PATH=../ocean nx documentation
```
This will create generated API documentation in the `docs/external-generated` folder. This API will be merged into the normal `docs/generated` documentation when the docs site is built.
Because there are two separate output folders, if someone runs `nx documentation` without the `NX_OCEAN_RELATIVE_PATH` environment variable, the ocean documentation will not be overwritten. The ocean documentation will only be updated or deleted when someone explicitly chooses to do so.
As your repository grows, it becomes more challenging to organize and name the applications and libraries. This organization, when done right, feels intuitive and allows team members to easily find projects and understand how they work together. When done poorly, it results in a mess we eventually end up calling “the legacy software”. This article will show you different ways how you can prevent your repo from descending into chaos.
Our book [Enterprise Angular Monorepo Patterns](https://go.nx.dev/angular-enterprise-monorepo-patterns-new-book) presents an in-depth guide to assist you with naming and organization. If you still haven’t read this book, we warmly recommend you do. Don’t let the name fool you, though — the architecture guidelines explained in this book apply to any framework.
On large projects, you will most likely find multiple teams working on different parts of the solution. Those projects are usually split into logical domains, where each team focuses on a single domain. Each domain block can have a clear public API which other domains can use to consume the information.
But the code organization is just one piece of the puzzle. The physical organization does not prevent developers from consuming the domains or parts of those domains, that should otherwise be outside of their reach. Nx ships with `enforce-module-boundaries` ESLint rule that helps restrict that possibility.
## Understanding the default configuration
When you generate the first project in your workspace using one of our generators, one of the things you get for free is the full linter setup. The linter is preconfigured with a default ruleset that includes a set of best practices. Alongside the standard set of rules, the initial generated configuration includes a setup for `enforce-module-boundaries` rule.
```json5 {% fileName=".eslintrc.json" %}
{
// ... default ESLint config here
overrides: [
{
files: ['*.ts', '*.tsx', '*.js', '*.jsx'],
rules: {
'@nrwl/nx/enforce-module-boundaries': [
'error',
{
allow: [],
depConstraints: [
{
sourceTag: '*',
onlyDependOnLibsWithTags: ['*'],
},
],
enforceBuildableLibDependency: true,
},
],
},
},
// ... more ESLint overrides here
],
}
```
Let’s dissect what each of these properties does.
The `allow` array acts as a whitelist listing the import definitions that should be omitted from further checks. You can read more about it in the **Overriding the overrides** section below.
The `depConstraints` section is the one you will be spending most time fine-tuning. It represents an array of constraints, each consisting of `sourceTag` and `onlyDependOnLibsWithTags` properties. The default configuration has a wildcard `*` set as a value for both of them, meaning that any project can import (depend on) any other project.
> Note, the wildcard only applies to libraries. Applications and E2E applications cannot be imported. It wouldn’t make any sense. If you want to combine applications, you should use the [micro-frontends](/recipes/angular/dynamic-module-federation-with-angular) approach with the module federation.
The circular dependency chains such as `lib A -> lib B -> lib C -> lib A` are also not allowed. The self circular dependency (when lib imports from a named alias of itself), while not recommended, can be overridden by setting the flag `allowCircularSelfDependency` to true.
```json5 {% fileName=".eslintrc.json" %}
// ... more ESLint config here
"@nrwl/nx/enforce-module-boundaries": [
"error",
{
"allowCircularSelfDependency": true,
"depConstraints": [
// ...list of constraints
]
}
]
// ... more ESLint config here
```
Finally, the flag `enforceBuildableLibDependency` prevents us from importing a non-buildable library into a buildable one. You can read more on what buildable libraries are used for in [our docs](/concepts/buildable-and-publishable-libraries).
## Using tags to enforce boundaries
To best express the need for the boundaries and assist us through the explanation, we will be using the repository represented by the following graph:
Our repository consists of two applications — Store and Admin. Each of them is composed of several feature libraries — Products (for Store), Sales, and Invoices (for Admin). Also, both of these applications depend on the Core library, and every project in our repo depends on our Shared library. Using common sense, we would like to enforce certain boundaries:
- A shared or core library should not be able to depend on a feature library
- A feature library can depend on another feature library or a shared library
First, we will use the project configuration to annotate our projects with `tags`.
- Tags used to live in `nx.json` but were in the recent version moved closer to the project, so you can locate them now in your `project.json` or `workspace.json`
Let’s define the types of projects. We will use the following tags:
- `type:app` for application
- `type:feature` for feature library
- `type:util` for utility library
Your changed project configuration should now have the tags section defined.
```json5 {% fileName="project.json" %}
{
// ... more project configuration here
tags: ['type:app'],
}
```
Your enhanced graph will now look similar to this:
The above list of library types is not complete. You might add specific ones for E2E projects or UI component libraries. Using the naming format `type:*` is just a suggestion. Consider this being a hashtag on your favorite social app. You can use any prefix or format you feel fitting. The important thing is that it's readable and intuitive to all the members of your team.
Now, that we have marked all of our projects, we can continue to define the rules in the root `.eslintrc.json.`
We said that a feature library can depend on any other feature library, but there is a small catch. Our two apps could be built with a different framework so mixing feature libraries would not be possible. To avoid any future impediments, we don’t want to allow a feature library used in `Store` to depend on the feature library from `Admin` and vice versa. Additionally, only our apps should be able to load the `Core` library.
You may want to constrain what external packages a project may import. In our example above, we want to make sure projects in the `scope:store` does not import any angular packages, and projects from the `scope:admin` do not import any react library. You can ban these imports using `bannedExternalImports` property in your dependency constraints configuration.
We can now enhance our rule configuration by providing additional information.
```json5 {% fileName=".eslintrc.json" %}
{
// ... more ESLint config here
'@nrwl/nx/enforce-module-boundaries': [
'error',
{
// update depConstraints based on your tags
depConstraints: [
// ...previous project type related rules
{
sourceTag: 'scope:store',
onlyDependOnLibsWithTags: [
'scope:store',
'scope:shared',
'scope:core',
],
// this covers all @angular pacakges
bannedExternalImports: ['@angular/*'],
},
{
sourceTag: 'scope:admin',
onlyDependOnLibsWithTags: [
'scope:admin',
'scope:shared',
'scope:core',
],
// this covers react, but also react-router-dom or react-helmet
bannedExternalImports: ['react*'],
},
{
sourceTag: 'scope:core',
onlyDependOnLibsWithTags: ['scope:shared'],
bannedExternalImports: ['@angular/*', 'react*'],
},
{
sourceTag: 'scope:shared',
onlyDependOnLibsWithTags: ['scope:shared'],
bannedExternalImports: ['@angular/*', 'react*'],
},
],
},
],
// ... more ESLint config here
}
```
Using the wildcard `*` to match multiple projects e.g. `react*` we can save ourselves the effort of manually specifying every single project we want to ban.
## Restricting transitive dependencies
Our solution doesn’t contain only internal projects but also depends on various external NPM packages. These external dependencies are explicitly declared in our `package.json`. Unfortunately, a package is rarely an island. They often consist of a tree of transitive dependencies branching out leading to thousands of packages being installed in your `node_modules` folder. Although we have control over what version or which direct dependency we install, we have no control over what versions of what packages this dependency depends on. The transitive dependencies are often the source of our app's vulnerabilities. We can also never guarantee those dependencies will be there. Just by simply running `npm install` parent may get updated to a patch or minor version that would wipe out one of the transitive dependencies or replace it with one with breaking changes.
Therefore it’s wise not to allow developers to import transitive dependencies in their projects. Our ESLint plugin provides a simple flag to turn this restriction on.
```json5 {% fileName=".eslintrc.json" %}
{
// ... more ESLint config here
'@nrwl/nx/enforce-module-boundaries': [
'error',
{
// ... more rule config here
banTransitiveDependencies: true,
},
],
// ... more ESLint config here
}
```
If you now try to import a transitive dependency, your linter responds with an error. This flag is disabled by default for now, but we highly recommend you enable it.
## Overriding the overrides
Sometimes, we just need to override this configuration for a given project. The scenario for this might be testing or during the development, if we are unsure yet how a certain project will be tagged. While we strongly encourage you to plan your architecture carefully and never override the boundaries configuration, you still have an option to bale out and override it.
Monorepos are often viewed only from the technical side, but they also bring a shift in human resources organization. Teams that were once isolated, now have to work together on the same solution.
Having a clean separation of concerns and well-defined cohesive units helps us scale our organization more easily and gives us more confidence in our architecture. not only does Nx provide tools to speed up the overall performance, but it provides tooling to enforce the organizational constraints in an automated way.
In this post, we listed several strategies which you can use to restrict your packages from being misused or use unplanned external resources. Use them thoroughly and on time, before things go out of hand.
> Prefer a visual presentation over text? Then check out this talk recording by Juri Strumpflohner: [https://www.youtube.com/watch?v=pER_Ak1yUaA&t=687s](https://www.youtube.com/watch?v=pER_Ak1yUaA&t=687s)
Nx is a smart, extensible build framework to help you architect, test, and build at any scale — integrating seamlessly with modern technologies and libraries while providing a robust CLI, computation caching, dependency management, and more.
## One Million Weekly Downloads 🎉
Nx reached a major milestone this week of one million weekly downloads. Nx has been working to push monorepos forward for a long time, and this milestone is a reflection of work between us and the Nx community to grow and expand in this space.
When operating with a monorepo, some level of configuration is needed to provide context about the tools and structure for inferring information about projects. Nx has traditionally done this with 2 files, the **nx.json** that contains global configuration for the Nx CLI, and the **workspace.json** that contains references to projects within your workspace.
With the latest release of Nx and add-nx-to-monorepo 2.0, there is only the **nx.json** configuration file added to your existing monorepo, with the project information done through analyzing your workspace for existing projects. This allows you to **incrementally adopt** Nx into your monorepo to run tasks, cache computations, and more.
```shell
npx add-nx-to-monorepo
```
> Victor Savkin demoed the flexibility of Nx by migrating Meta’s (Facebook) React repository: [video link](https://youtu.be/XLP2RAOwfLQ)
Learn more in our guide of [adding Nx to an existing workspace](/recipes/adopting-nx/adding-to-monorepo) and the config inside the [**nx.json**](/reference/project-configuration)**.**
## Custom Workspace Presets 🎨
Nx provides many presets by default to support many different ecosystems. Nx for monorepos is like VSCode, where plugins allow you to extend the functionality of your monorepo to fit your ecosystem or platform of choice. To make it easier for scaffolding a pre-defined setup, we’ve introduced the ability to use custom presets when creating Nx workspaces with a provided npm package.
Nicholas Cunningham just joined Nrwl and already implemented this new Nx feature! In the following video, [Juri Strumpflohner](https://twitter.com/juristr) walks you through the process of creating a new Nx Plugin with a custom preset.
This allows you to enhance the initial experience for new workspaces directly for your organization, and allows the Nx Plugin community to offer more tailored experiences. Please try out the new feature and [let us know](https://github.com/nrwl/nx) how we can improve it!
## Dedicated TypeScript and JavaScript support with @nrwl/js
Nx has always shipped with great TypeScript support. In version 13.4 we improve it even further by releasing a brand new package: `@nrwl/js` .
This is particularly useful if you have framework-agnostic TS/JS packages within an existing Nx workspace but also for those scenarios where you want to build and publish a TS/JS-based library to some package registry. The setup is very lightweight, but still provides all benefits you’d expect from an Nx-based setup such as Jest, ESLint, Prettier etc.
Read all the details on [our new TypeScript guide](/getting-started/intro) or check out the video walkthrough below.
Tailwind is a utility-first CSS framework packed with classes that can be composed to build any design, directly in your markup. If you’ve used Tailwind with Angular applications previously, it's supported out of the box with Nx. We’re continually looking to improve the developer experience of using Tailwind in Angular applications and libraries. We already added support to the Angular plugin for Nx, and have added a new generator to configure Tailwind in **existing** apps and buildable/publishable libs, allowing you to set up and configure Tailwind without manual steps. The ability to configure new apps and libs is also supported, with support for Tailwind V2 and the latest V3 release.
```shell
nx g @nrwl/angular:app my-app --addTailwind
```
Read more about Angular and Tailwind in our [docs](/nx-api/angular/generators/setup-tailwind).
### Other Highlights 🗒
- Added SWC support for compiling JavaScript libraries and React apps/libs when building projects
- Added migration support Create React App version 5
- Updated the Angular framework to version 13.1
- Update support for Cypress to version 9
- Added additional SCAM generators for Angular for pipes and directives.
- Improved developer experience for using Module Federation with Angular v13
## How to Update Nx
Updating Nx is done with the following command, and will update your Nx workspace dependencies and code to the latest version:
```shell
nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
nx migrate --run-migrations
```
## Explore More
- Get our [free basic Nx workspaces course on YouTube](https://youtu.be/2mYLe9Kp9VM)!
- Purchase our premium video course on advanced practices for Nx workspaces: [here](https://nxplaybook.com/p/advanced-nx-workspaces)!
Follow us [on Twitter](https://twitter.com/NxDevTools), and subscribe to the [YouTube Channel](https://youtube.com/nrwl_io?sub_confirmation=1) for more information on [Angular](https://angular.io/), [React](https://reactjs.org/), Nx, and more!
Nx is a smart, extensible build framework to help you architect, test, and build at any scale — integrating seamlessly with modern technologies and libraries while providing a robust CLI, computation caching, dependency management, and more.
### New Terminal Output 💅
Folks that have been following along in our journey for quite some time know already that at Nx we strive for the best possible DX. The current terminal output was always something we haven’t been super happy with, especially if you run some of the commands that trigger the execution of multiple tasks (e.g. affected commands, run-many etc). This is why we’re even more excited about this feature: the new dynamic Nx terminal output is now the default for everyone.
It clearly separates the terminal output into an upper part where all the completed tasks and their corresponding execution time are listed and a lower part where the currently running tasks show up. Of course, errors are always shown immediately and therefore easy to spot.
There are a few things to note here (and which kinda emphasize our love with details & dev ergonomics 😉)
- **Off in CI —** On CI you’ll still see the full output.
- **The full terminal output is still cached —** this is purely UI cosmetic. We still cache the entire terminal output. Hence, if you run the build of a single project that has previously been cached as part of a run-many command, you will see still the full output.
Thanks to [James Henry](https://twitter.com/mrjameshenry) for working on this feature!
### Nx keeps getting faster and faster 🚀
Performance is a feature, and we take it seriously with Nx. We landed a number of different performance improvements over the last couple of minor versions, ranging from optimizing how we store & restore our cache to improving the Nx workspace analysis and boot time. With v13.5 we’ve seen some Nx operations being
- 1.8x — 2.3x faster in the [Interstellar repo](https://github.com/vsavkin/interstellar)
- about 2x faster on some large client repositories
And we will not rest 😉.
### Performance Profiling with Nx 🧐
When running an Nx command there might potentially be many tasks running at different times, in parallel, and using different processes. Optimizing those runs or better understanding where things go wrong might be a hard and cumbersome process. Being able to visualize things usually helps.
That’s why we introduced the ability to profile and visualize Nx commands in the Chrome Devtools.
Use the `NX_PROFILE=<filename>` environment variable attached to your Nx CLI command:
```shell
NX_PROFILE=profile.json nx build cart
```
It’ll produce a JSON file which you can then open with Chrome’s devtools. [Read more about it on the Nx Docs](/troubleshooting/performance-profiling).
Thanks [Jason](https://twitter.com/FrozenPandaz) for working on this feature!
### React Native now supports Environment Variables
Whenever you set up React Native support within an Nx workspace, it should now automatically come with the [react-native-config](https://github.com/luggit/react-native-config) package installed. That allows you to have a `.env` file in the React Native app folder which can then be loaded from within your React Native application.
You can find all the details on the [Nx docs](/recipes/react/react-native).
Thanks [Emily Xiong](https://twitter.com/xiongemily) for implementing this!
### Improvements to the Project Graph Visualization
The project graph is always a nice feature to show off in videos, talks, and blog posts. But if done naively, it just remains that. We always wanted it to be more than that. As your workspace grows, your project graph visualization should become more useful, rather than a mess to look at. This is why we kept adding features for filtering, zooming, highlighting, focusing on specific nodes, incrementally expanding the view by using the proximity feature and more.
In v13.5 we now also store the current filter status in the URL. That makes it easy to pinpoint a certain view and share it with a co-worker. Actually, this could just be the beginning of some more interesting features when we think about CI and visualizations 🤔.
Here’s our deployed live example of the above screenshot: [https://nrwl-nx-examples-dep-graph.netlify.app/?focus=products-home-page](https://nrwl-nx-examples-dep-graph.netlify.app/?focus=products-home-page)
Thanks [Philip Fulcher](https://twitter.com/PhilipJFulcher) for adding this feature!
There’s one more thing: As developers, we like to be as efficient as possible. We wanted to help by saving you some keystrokes. The project graph visualization can now be launched with
```shell
nx graph
```
`nx dep-graph` is registered as an alias and will continue to work 🙂.
### New improvements to our Angular plugin
There have been a number of improvements to our Angular plugin ( `@nrwl/angular` ) :
- Option to skip the Angular Module creation when generating new libraries by passing `--skipModule`
- Support for multiple state slices when using the Nx Angular Data Persistence utilities. Thanks [David](https://medium.com/u/6e7f9350fcdf?source=post_page-----c407bb1c963a--------------------------------) for this community contribution !([#8216](https://github.com/nrwl/nx/pull/8216))
- New Angular Nx workspaces now use v2 of the workspace configuration (Nx’s format of the `angular.json` )
- Lots of improvements to the Angular SCAM generator
## How to Update Nx
Updating Nx is done with the following command, and will update your Nx workspace dependencies and code to the latest version:
```shell
nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
nx migrate --run-migrations
```
## Explore More
- Get our [free basic Nx workspaces course on YouTube](https://youtu.be/2mYLe9Kp9VM)!
- Purchase our premium video course on advanced practices for Nx workspaces: [here](https://nxplaybook.com/p/advanced-nx-workspaces)!
Follow us [on Twitter](https://twitter.com/NxDevTools), and subscribe to the [YouTube Channel](https://youtube.com/nrwl_io?sub_confirmation=1) for more information on [Angular](https://angular.io/), [React](https://reactjs.org/), Nx, and more!
**A problem I try to solve:** I got this awesome idea, not only do I want to create a web app, but I also want to create a mobile app for it. Usually creating web and mobile apps require totally different tech stacks, and it is pretty hard to share code. This article shows how I added a React web app and a React Native mobile app in the same monorepo using Nx, and how I optimized codeshare between the two.
I am mostly a web developer, so let’s start with the web app first: [https://xiongemi.github.io/studio-ghibli-search-engine](https://xiongemi.github.io/studio-ghibli-search-engine). It is a search engine for movies and characters under Studio Ghibli:
> Note, if you’re using VSCode you might want to try [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) for a more visual experience of running such commands.
As a result of running the above command, you should now have two new folders under the `apps` directory: `studio-ghibli-search-engine-mobile` and `studio-ghibli-search-engine-mobile-e2e`
Note that there is no code shared between `studio-ghibli-search-engine-mobile` and `studio-ghibli-search-engine-web`. However, our goal is to reuse some of the functionality that we have previously written for the web version on our new React native version of the app.
## Code that Could NOT be Shared
Even though our goal is to share as much as possible between our React web app and the React Native app, there are parts that simply cannot be shared.
### UI
We have to rewrite all the UI components for the mobile app. Unlike [Cordova](https://cordova.apache.org/) or [Ionic](https://ionicframework.com/), React Native is NOT a webview. The JavaScript we wrote got interpreted and converted to mobile native elements. Hence we cannot simply reuse UI HTML elements written for the React web app.
Here’s a quick list of libraries we’ve used for the React web app and a corresponding React Native counterpart library we can use.
**Routing**
- [react-router-dom](https://reactrouter.com/docs/en/v6/getting-started/overview) for web
- [@react-navigation/native](https://reactnavigation.org/) for mobile
**Material Design Library**
- [@mui/material](https://mui.com/) for web
- [react-native-paper](https://callstack.github.io/react-native-paper/) for mobile
Besides the above React Native libraries, there are some core utility libraries that need to be installed:
For the React Web app, we use [redux-persist](https://github.com/rt2zz/redux-persist), which persists the redux store in [`localstorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). However, `localstorage` is not supported by React Native.
For the web, the variable `persistConfig` passed to persistStore from redux-persist is:
```typescript
importstoragefrom'redux-persist/lib/storage';
constpersistConfig={
key:'root',
storage: storage,
whitelist:['search','films','people'],
transforms:[transformEntityStateToPersist],
};
```
However, for the mobile, we need to install the library [`@react-native-async-storage/async-storage`](https://github.com/react-native-async-storage/async-storage):
On the React web app, we use [connected-react-router](https://github.com/supasate/connected-react-router) to put the router state into the Redux store. However, the [History API (windows.history)](https://developer.mozilla.org/en-US/docs/Web/API/History_API) is not supported by React Native. As an alternative, we can use `createMemoryHistory`.
For the web app, the history is:
```typescript
import{createHashHistory,History}from'history';
consthistory: History=createHashHistory();
```
For the mobile app, the history is:
```typescript
import{createMemoryHistory,History}from'history';
consthistory: History=createMemoryHistory();
```
To make our code more re-usable we could slightly refactor the creation of the root reducer with [connected-react-router](https://github.com/supasate/connected-react-router), such that it takes the `history` object as an argument:
When you develop on the web, the easiest way to pass ahead state or information, in general, is to leverage the URL query parameters. In our search app example, we can simply have something like `?search=searchText`.
We can use [react-router-dom](https://v5.reactrouter.com/web/guides/quick-start) to push a new history entry.
Although the mobile app URLs are not visible, we can still pass parameters. Note that we have to use a different package `@react-navigation/native` though.
To type checking with typescript for react-navigation, we need to create a type `RootStackParamList` for mappings of route name to the params of the route:
```typescript
exporttypeRootStackParamList={
[AppRoutes.search]:undefined;
[AppRoutes.results]:{search: string};
};
```
We also need to specify a global type for your root navigator:
Nx comes with a set of different options for [handling environment variables](/reference/environment-variables). In our workspace, we have a simple `.env` file at the workspace root:
```text
NX_REQUEST_BASE_URL=://ghibliapi.herokuapp.com
```
This works nicely for our React web build, but it doesn’t for our React Native application. This is because React Native and React apps use different Javascript bundlers. React Native uses [Metro](https://facebook.github.io/metro/) and React uses [Webpack](https://webpack.js.org/). Therefore, when we try to access `process.env.NX_REQUEST_BASE_URL`, we get `undefined`.
To solve this, we can use the [react-native-config](https://github.com/luggit/react-native-config) library
```shell
# npm
npm install react-native-config --save-dev# yarn
yarn add react-native-config --dev
```
Here’s an example of how to set up [react-native-config](https://github.com/luggit/react-native-config): [https://github.com/luggit/react-native-config#setup](https://github.com/luggit/react-native-config#setup).
After that, we can have a simple utility function to retrieve the environment variables in our app.
```typescript
importConfigfrom'react-native-config';
exportfunctiongetEnv(envName: string){
returnprocess.env[envName]||Config[envName];
}
```
To access the environment variable `NX_REQUEST_BASE_URL`, we can then simply use the above function:`getEnv(‘NX_REQUEST_BASE_URL’)`.
### Fetch With HTTP
On the web, you most probably lean on the [fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) to make network requests. On iOS, however, you’ll get an error saying: `TypeError: Network request failed`.
It turns out that React Native does not allow HTTP requests by default: [https://stackoverflow.com/questions/38418998/react-native-fetch-network-request-failed](https://stackoverflow.com/questions/38418998/react-native-fetch-network-request-failed).
To fix this, for iOS, open `apps/studio-ghibli-search-engine-mobile/ios/StudioGhibliSearchEngineApp/Info.plist` and add the request URL to `NSExceptionDomains` under `NSAppTransportSecurity`:
```xml
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>localhost</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
<key>ghibliapi.herokuapp.com</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
</dict>
</dict>
```
Similarly, for Android, open `apps/studio-ghibli-search-engine-mobile/android/app/src/main/res/xml/network_security_config.xml`, and add the request URL to this config file:
It seems like there are quite a few customizations that need to be done for React Native apps. However, the majority of non-UI code could be reused.
## Code that Could be Shared
All the business logic code that is not UI could be shared. For this example, I got 3 libraries in my monorepo and all of them could be shared:
- models: types and interface definitions
- services: services that interact with API
- store: redux store
With Nx, it requires zero configuration to share the above library code. Even though when I created these libraries for a web app, I used commands like `nx generate @nrwl/react:lib store`, I could still use them directly in my react native mobile app.
For example, I need to create a film page to display film details with film id passed in as a parameter:
Note I could import from `@studio-ghibli-search-engine/models`, `@studio-ghibli-search-engine/services` and `@studio-ghibli-search-engine/store` directly.
Now when I run `nx dep-graph`, it shows the dependency graph below where all these 3 libraries are shared between web and mobile:
For this example project, to create the mobile app, it took me some time to rewrite the entire UI. However, I do not need to make any changes to the above libraries.
_Screenshots of Mobile App (left: iOS, right: Android)_
## Conclusion
In this article, we ended up building both, a React-based web application and a corresponding React Native app in the same repository using Nx.
Nx’s architecture promotes the separation of concerns, splitting things into `apps` (which are technology-specific) and `libs` which can be technology-specific or technology-independent. That allows us to easily have our common business logic in a technology-independent library which in turn (thanks to Nx’s setup) be easily linked to both, our React web and React Native mobile app.
Although there are UI-specific differences we need to account for, that simply comes with one being a web tech stack and the other being a native app, we were still able to share big chunks of the technology-independent business logic of our application. That ultimately helps with maintenance and having feature parity across different platforms.
_(Note, the repository with the code for this article is linked at the very top)_
We are very excited to announce our support for Expo with our new package `@nrwl/expo`. In addition to the React Native support, with this release of `@nrwl/expo`, you will be able to easily develop mobile apps in the monorepo. If you use Expo in a monorepo then Nx is the tool for you.
This blog will show you how to create a one-page app to display a poem:
When I just started to try out Expo, the first questions came to my mind were “what is the difference between Expo and React Native” and “when to choose Expo and when to choose React Native”? In short, Expo is a set of tools built on top of React Native. You can read it more at [https://stackoverflow.com/questions/39170622/what-is-the-difference-between-expo-and-react-native](https://stackoverflow.com/questions/39170622/what-is-the-difference-between-expo-and-react-native).
Now I have created an app with Expo, to me, the most significant differences are developer experience and the build process.
For a managed Expo project, notice that it only has a `src` folder; whereas for a React Native project, besides the `src` folder, it also contains the `android` and `ios` folder. For a managed Expo project, developers do not need to worry about maintaining code for iOS and Android. However, you can still write customized native code for Expo, you can use Expo with [bare workflow](https://docs.expo.dev/introduction/managed-vs-bare/#bare-workflow) after running the command `expo eject`.
Moreover, Expo provides [Expo Application Services(EAS)](https://docs.expo.dev/eas/) to build and distribute your app. React Native developers can bundle and build locally using Android Studio or Xcode. However, with EAS Build, it will build on a hosted service. Of course, there is potentially a fee involved: [https://expo.dev/pricing](https://expo.dev/pricing).
**Something to note:** [@nrwl/expo](https://www.npmjs.com/package/@nrwl/expo) and [@nrwl/react-native](https://www.npmjs.com/package/@nrwl/react-native) cannot exist in the same monorepo due to dependency version conflicts. Expo usually tails the latest React Native by a few versions, whereas [@nrwl/react-native](https://www.npmjs.com/package/@nrwl/react-native) tries to align with the latest React Native version.
Now we got the app running, let’s create our first page. In this example, we are going to use the [React Native Paper](https://callstack.github.io/react-native-paper/) as the material design library. To install:
```shell
# npm
npm install react-native-paper --save
# yarn
yarn add react-native-paper
```
Then, let’s create our first component. This component simply displays a poem on the page.
First, to add a component file under the app, run the below command:
```shell
nx g @nrwl/expo:component poem-of-the-day --directory=components
```
Now you should see the components under apps/components:
To see it in the real device, run `nx publish poetry-app`.
Awesome! Now you have built your first page. However, notice this page only displays a static poem. The next step is to integrate with the API. In this example. We are going to use PoetryDB: [https://github.com/thundercomb/poetrydb](https://github.com/thundercomb/poetrydb).
## Create a Workspace Library
To create a library that gets a random poem from the API, run the command:
```shell
nx generate @nrwl/expo:library services
```
This should generate a services folder under libs:
Now you want to build and possibly publish your app. To build the standalone app, you can use the Expo build. First, you need to create an Expo account. You can do it at [https://expo.dev/signup](https://expo.dev/signup) or using the command line:
```shell
npx expo login
```
Then you can run the build command:
```shell
# iOS
nx build-ios poetry-app
# Android
nx build-android poetry-app
```
You can monitor your builds after logging in at [https://expo.dev/](https://expo.dev/):
With Nx, we can create as many libraries as we want to handle different concerns. It would be very handy to share and reuse libraries or have multiple apps in the same monorepo.
I hope you found this useful, and we look forward to hearing your [feedback](https://github.com/nrwl/nx-labs/issues).
If you’re new to Nx and want to learn more, visit [our docs](/getting-started/intro)**.**
_(Note, the repository with the code for this article is linked at the very top.)_
This app is also available in the app store, just search “Poem of the Day”:
Android:
[Poem of the Day](https://play.google.com/store/apps/details?id=com.exiong.poetryapp)
_In this article, I’d like to specifically talk about developer tooling, why it is so massively important and how you might have missed out on Nx as your main React CLI for kickstarting new awesome projects._
It is awesome to be a JavaScript developer nowadays. The JavaScript ecosystem has evolved a lot in recent years. For the better! Speed has become a major focus, both from the framework perspective of running the app in production, as well as the speed of developing, testing, and building JavaScript/TypeScript from a developer tooling point of view. Frameworks and libraries such as Next.js, Astro, Qwik and Remix (just to name a few) have brought some great innovations to push the web even further.
While speed is of major importance, developer ergonomics shouldn’t be left behind. Both of them greatly contribute to the overall productivity and also developer happiness 🙂. Let’s see how Nx can help with that.
This article walks you through how to setup a new Nx monorepo workspace with React. If you rather prefer starting with a single-project setup (also named “standalone”) then you might want to have a look at this tutorial (including video):
Regardless of whether you’re a seasoned developer or someone new just getting started with React: the last thing you want to have to deal with is to manually set up all the tooling to actually get started and be productive. You want to be able to focus on the actual task, like learning React or kicking off that new shiny project.
Still, we definitely want to **have good defaults set up for us**. Things like the latest build tooling, tooling for writing unit tests as well as e2e tests, code quality tools like linters, and we definitely also don’t want to argue about tabs vs spaces or spend time formatting our code: Prettier can help with that.
Taking the time to set up a starter kit or template would work. But it is time-consuming, requires a lot of knowledge, and especially needs maintenance to update the tools over time. That rarely works out well in the long run, unless this is your job.
## Nx — from a bird’s eye view
What you usually want is a CLI, a command-line interface that helps you develop and deal with the underlying build infrastructure, something that sets you up with modern up-to-date tooling and also keeps those updated!
Nx comes with such a CLI, it is widely adopted by the Angular, React and Node community currently being downloaded more than 1.3 million times a week. Nx is [fully open source](https://github.com/nrwl/nx) (MIT licensed), baked by [Nrwl](/company) and the [community](https://go.nx.dev/community).
From a bird’s eye view, Nx comes with
- Code generators to generate new projects, configuration but also components, Redux setup, routes…
- Out of the box support for modern tools such as TypeScript, Webpack, Babel, SWC, Jest, Cypress, ESLint, Prettier, Storybook and more
- It keeps tooling up to date via dedicated migration commands
- Speed! Nx uses local computation caching that can be extended with Nx Cloud (which is basically free) to remote caching and DTE (Distributed Task Execution).
But let’s have a deeper look at how Nx works exactly.
## Using Nx
Let me give you an overview of the most used functionality that Nx gives you such that you get a good understanding of whether it might suit your needs.
## Creating a new Nx React project
Open your favorite terminal window and type:
```shell
npx create-nx-workspace@latest myorg
```
> _Note, I’m using_ `_npx_` _to not have to install the Nx CLI globally. If you want to, you totally can:_ `_npm i nx -g_`
`myorg` is the scope of your Nx workspace. Think of it as your NPM scope in case you’d publish an npm package. In the case you create libraries in this new Nx workspace (more about that later), it would be used to import those, like
```typescript
import{someFunc}from'@myorg/somelib';
```
What you’ll get is a setup wizard that guides you through creating your application. We would most likely choose “React” in this case.
As part of this process, you’ll be asked to pick an “Application name”. This is simply the application Nx is going to generate for us to get started: `happynrwl` would be a nice name 🙂.
You should end up with a new Nx workspace and our `happynrwl` React app in the `apps/` folder.
> _Note I prefix the commands with_ `_npx_`_, which is just a way to use the local_ `_nx_` _binary from the_ `_node_modules_` _folder of our workspace. Also, this way we don’t have to install Nx globally. If you prefer doing that, run_ `_npm install -g nx_`_._
Going to [http://localhost:4200](http://localhost:4200/) should show the running React app located in `apps/happynrwl`.
_Output folder assets when building the React app_
Nx has another nice feature that basically comes for free: [computation caching](/concepts/how-caching-works). For every command Nx runs, it computes a unique hash that contains information about the involved source code, environment variables and the command itself. Next time the same conditions are met, the command is not executed again, but rather pulled out of a cache. As you can imagine, this drammatically speeds up things.
If you’re curious and want to learn more, check out the docs page on [computation caching](/concepts/how-caching-works) and how to leverage [Nx Cloud](/nx-cloud) to store the cache remotely for sharing it with your team members. Also, Nx Cloud pricing recently changed, which makes it basically free for everyone.
## Code Generators!
One of the core parts of Nx is code generators. As the name already suggests, code generators generate source code and configuration. That can range from a single React component file to an entire project with all that is needed. You basically already saw them in action when you created the initial project setup. But there’s more to explore! Every Nx plugin (e.g. `@nrwl/react`, `@nrwl/next`,...) come with their own set of generators. All of them are invoked with the `npx nx generate` or short `npx nx g` command.
Let’s for instance generate a new component for our React application:
```shell
npx nx generate @nrwl/react:component HelloWorld
```
This generates a new component in our `happynrwl` application
> _Note, you can also use_ `_nx g @nrwl/react..._` _as a shorthand for_ `_generate_`_. Also, if you attach_ `_--dry-run_` _to the end of the command it will just simulate the run without touching the file system._
Many of these generators come with a rich set of flags. For example, passing `--routing` to our component generator from before, generates a component with routes already set up, adds `react-router-dom` to the `package.json` and executes a `npm install`.
**How do we find all these generators though?** There are different options:
- **Nx documentation** — use the search function there or just navigate the docs. All the reference pages are structured like `nx.dev/packages/<packagename>`. As an example for React that would look like: [/nx-api/react](/nx-api/react).
-`npx nx list` - lists a set of installed plugins as well as other available plugins that can be installed. To get a list of generators for a specific plugin - say for the `@nrwl/react` plugin - run `npx nx list @nrwl/react`. Similarly, you can then run `npx nx g @nrwl/react:lib --help` to get help for a particular generator
However, the absolute easiest way to explore the potential and even use Nx if you are not the “terminal type of person” is [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)! I’ll go a bit deeper into that in a later section.
## State of the Art Tooling Preconfigured
When setting up a new React project (that also holds for Angular, Node, Next.js,…), you do not only get the React project, but also a set of tools preconfigured that help you stay productive and produce higher quality code. These are
- TypeScript
- ESLint
- Jest
- Cypress
- Prettier
The Nx core team closely collaborates with these open source projects to not only make sure they integrate seamlessly with the React setup but also to keep them updated over time as those tools evolve. In fact, by using [automated code migrations](https://egghead.io/lessons/javascript-update-your-nx-workspace-with-nx-migrations) updating your Nx workspace will automatically also update those tools and the corresponding config files for you.
Let’s have a closer look.
## TypeScript as a first-class citizen!
The Nx core team strongly believes in the benefits of TypeScript (in fact, check out the [new Nx and TypeScript setup](/getting-started/intro)). As such, by default every project is automatically set up and configured to use TypeScript, making sure builds, as well as IDEs, are able to properly pick up TypeScript definitions. All without you having to worry about it.
Now, if you really want to use pure JavaScript you totally can. Just pass the `--js` when running a generator. Read [more on the docs](/recipes/tips-n-tricks/js-and-ts).
## ESLint preconfigured!
Every new Nx workspace comes with [ESLint](https://eslint.org/) already preconfigured. Having proper linting in place is a great way to help contribute to overall better code quality by statically analyzing your source code and finding potential issues early in the process.
Every project generated by Nx comes with a `.eslintrc.json` file. That configuration extends from an ESLint plugin `@nrwl/nx/react` , containing a set of best practices rules, and at the same time allows you to add further rules that are specific to your needs.
Linting can be run similarly to the other commands:
```shell
npx nx lint happynrwl
```
## Jest preconfigured!
Similar to the linting setup, every project in an Nx workspace has a test runner preconfigured already. By default, Nx comes with [Jest](https://jestjs.io/).
At the root of every project, there’s a `jest.config.js` which already comes with proper transformers to support TypeScript and TSX/JSX. If you need to further customize how Jest should behave for this project, this is the place to do that.
Obviously, you can pass parameters to customize the Jest run, like
-`--watch` for interactive mode
-`--t` to execute tests that match a given pattern
-`--testFile="apps/happynrwl/src/app/hello-world/hello-world.spec.tsx”` to run a specific file
- …
If you happen to use [VSCode](https://code.visualstudio.com/), the easiest way however is to install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) and leverage its code lens feature to run and debug Jest tests:
_Using VSCode extensions to run Jest tests directly via Code Lens support_
## Cypress preconfigured!
[Cypress](https://www.cypress.io/) has revolutionized e2e testing by making it more developer-friendly. Who likes to write tests after all. That just gets even worse if the DX sucks. Cypress successfully tackled that by listening and addressing the pain of existing e2e testing solutions.
Whenever you generate a new project in an Nx workspace, you have the option to automatically also create a Cypress-based e2e project alongside it. In our case, it is called `happynrwl-e2e`.
_Cypress e2e app generated by Nx along-side the main React app_
The awesome part of this is that you don’t have to configure anything at all. No need to
- make sure TypeScript runs smoothly with Cypress
- set up linting for our e2e project (yes writing good quality test code is just as important)
- spinning up our development server manually first that serves our React app such that we are able to load it in our Cypress tests environment
Just execute
```shell
npx e2e happynrwl-e2e
```
You can also pass `--watch` to run it interactively with the Cypress test runner such that the tests get re-executed whenever we change our source.
## Don’t argue over code formatting — use Prettier!
Are you a `tabs` or `spaces` person? Use semicolons or not? What about trailing commas? We all know that we devs can have some strong opinions on this 😅. But honestly, there are probably more important things to focus on. Luckily [Prettier](https://prettier.io/) can help a ton with these issues. It is opinionated with just very few configuration options and just takes away the burden of formatting the code.
When you set up a new Nx workspace, it has Prettier already preconfigured. The best way is to integrate it with your code editor such that formatting is run on every save of a file. Alternatively, you can also run
```shell
npx nx format
```
## Nx Console — A dedicated VSCode extension for Nx
Nx really is an advanced CLI based development tool. But regardless of whether you are a command line person or not, if you happen to use [VSCode](https://code.visualstudio.com/) make sure you install the [Nx Console extension](/getting-started/editor-setup) from the [marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console).
> _For_ [_Webstorm_](https://www.jetbrains.com/webstorm/) _there are two community extensions that can be used:_ [_nx-webstorm_](https://plugins.jetbrains.com/plugin/15000-nx-webstorm) _and_ [_Nx Console Idea_](https://plugins.jetbrains.com/plugin/15101-nx-console-idea)_._
Once you have the extension installed, you can click its icon in the VSCode Activity Bar (1) which reveals the Nx Console UI.
- (2) is the panel where you see a fixed command “Generate” to invoke the Nx generator for creating new projects, libraries etc as we mentioned before. In addition you see a list of available commands to run.
- (3) shows additional commands that are commonly used in an Nx workspace. Feel free to click and explore them.
- (4) shows a list of projects in your workspace. We really just have our React app and Cypress e2e application, but potentially you could add more. See [Nx applications and libraries](/concepts/decisions/project-size) for more.
Let’s take the example of generating a new React component, just as we did before, but this time using Nx Console. This is how you’d do that:
_Detail form shown by Nx Console to generate a new React component_
Whenever you change something in the form (1), you’ll automatically see a dry-run in the console that opens below (2). That shows what would happen if you run the command and is equivalent of adding the `--dry-run` flag whenever you’d run the command on the terminal. Once you’re ready, hit the “Run” button (3), or click the copy symbol (4) to copy the full command into your clipboard s.t. you can then paste it into your terminal.
As you can see this approach is also really powerful for exploring different commands and their corresponding options.
Besides running generators, Nx Console also adds [VSCode Code Lens](https://code.visualstudio.com/blogs/2017/02/12/code-lens-roundup) abilities to the configuration files that help you navigate more quickly across the workspace. This is particularly useful if you happen to add more [apps and libraries](/concepts/decisions/project-size) to the workspace at some point.
_Nx Console Code Lens support to navigate easily among config files_
## Evergreen Workspace Setup
One of the advantages of using Nx over — say CRA or a custom starter template — is that your **Nx workspace is evergreen**. What do I mean by that: by now we all know how fast the frontend space is moving, and so are the corresponding devtools. Today you might be using [Rollup](https://rollupjs.org/) to build your libraries, tomorrow you use [swc](https://swc.rs/), [vite](https://vitejs.dev/) or [esbuild](https://esbuild.github.io/). Same with [Webpack](https://webpack.js.org/). Webpack 5 has been around for a while already, and still, a lot of projects are stuck at v4.
Just to mention an example: when upgrading Nx to v13, all Nx users automatically got migrated to Webpack 5.
This is possible with Nx’s [migrate command](/nx-api/nx/documents/migrate) that allows you to keep up to date with your framework in a mostly automated fashion. Whenever you upgrade Nx, you run
```shell
npx nx migrate latest
```
Running this command, Nx
- analyzes the current packages
- fetches the latest Nx packages and plugins (or whatever version was specified in the migration command)
- creates a `migrations.json` file containing all migration scripts that need to be executed
- updates the `package.json` to the new package versions
The `migrations.json` file can be inspected and potentially modified. Once it is ready, running the following command executes the migration:
```shell
npx nx migrate --run-migrations=migrations.json
```
These migrations not only update the `package.json` version. They also update corresponding configuration files and even source code by leveraging ASTs to query and manipulate files.
It is not even only about upgrading the frameworks such as React or Angular themselves, though. A common pain point is their integration with other tools, such as Jest, Storybook, ESLint etc. The Nx core team closely collaborates with these communities to make sure that a particular combination of versions works and is tested before migrating your workspace.
Here are some common questions developers have. Have some more? Feel free to ping me on Twitter ([@juristr](https://twitter.com/juristr)), the official Nx account ([@NxDevtools](https://twitter.com/nxdevtools)) or in the [Nx community Discord](https://go.nx.dev/community).
## Q: How can I customize how my project is built and served?
Every Nx project comes with a `project.json` which contains the basic setup of targets (example: `build`, `serve`, `test`, `lint`,..) that can be run against the project.
Here’s the `project.json` for our `happynrwl` React application. I clipped out the non-relevant parts here:
```json5
{
...
"targets": {
"build": {
"executor": "@nrwl/web:webpack",
...
"options": {
"compiler": "babel",
"outputPath": "dist/apps/happynrwl",
"index": "apps/happynrwl/src/index.html",
"baseHref": "/",
"main": "apps/happynrwl/src/main.tsx",
"polyfills": "apps/happynrwl/src/polyfills.ts",
"tsConfig": "apps/happynrwl/tsconfig.app.json",
"assets": [
"apps/happynrwl/src/favicon.ico",
"apps/happynrwl/src/assets"
],
"styles": ["apps/happynrwl/src/styles.css"],
"scripts": [],
"webpackConfig": "@nrwl/react/plugins/webpack"
},
"configurations": {
"production": {
...
}
}
},
"serve": {
...
},
...
},
"tags": []
}
```
As you can see, all these “targets” (`build`, `serve`,...) have a so-called `options` property that allows you to configure how the target behaves. The actual configuration is abstracted behind the “[Nx Executor](/concepts/executors-and-configurations)”, in our case `@nrwl/web:webpack`. You can find the details of how to configure that on the Nx docs in the CLI reference for the `@nrwl/web` package: [/nx-api/webpack/executors/webpack](/nx-api/webpack/executors/webpack).
To read more about how the `project.json`, its executors, and configuration options are structured, check out the official docs: [/reference/project-configuration](/reference/project-configuration).
> _Note, Nx is also able to just pick up NPM scripts registered in the_ `_package.json_` _of your project root. This scenario is most useful if you’re adding Nx to an existing monorepo (see_ [_add-nx-to-monorepo_](https://www.npmjs.com/package/add-nx-to-monorepo)_). Read more here:_ [_/reference/project-configuration_](/reference/project-configuration)
Nx’s extensibility and customizability have really no limits, allowing it to really adapt to your needs. Here are some resources to learn more if you need some advanced features.
- Control the entire workspace setup with [custom presets](/nx-api/plugin)
## Q: Can I customize my Webpack config used to build my React app?
As mentioned previously, the underlying build machinery is usually hidden by a so-called [Nx Executor](/concepts/executors-and-configurations). As we have seen you can customize its behavior via the corresponding `options` property. By abstracting the underlying build tool, Nx is able to fulfill its evergreen promise as mentioned previously and allows to seamlessly upgrade workspaces to the latest versions of the build tooling that is being used.
If the available `options` are not enough, you can further customize the Webpack configuration using the `webpackConfig` property:
```json5
{
...
"targets": {
"build": {
"executor": "@nrwl/web:webpack",
...
"options": {
...
"webpackConfig": "@nrwl/react/plugins/webpack"
},
...
},
...
},
"tags": []
}
```
By default it links to `@nrwl/react/plugins/webpack`, but you can point to your own custom file in the Nx workspace. The file needs to look like the following:
// invoke the Nrwl specific config to preserve the original
// behavior
config = fromNrwlReact(config); // add your own customizations HERE return config;
}
module.exports = getWebpackConfig;
```
Notice how the default Nrwl provided Webpack configuration is invoked first to not lose the default behavior, followed by your own customizations.
## Q: Why is there an “apps” folder? Can I change it?
Sure! Nx allows to host multiple applications and libraries in a single workspace: a monorepo scenario basically. In fact, even in our simple setup we have two applications: `happynrwl` and the corresponding e2e application, `happynrwl-e2e`.
In a default setup Nx generates an `apps` folder for hosting applications, and `libs` folder for hosting libraries. Read more about [“Apps and Libs” on the Nx docs](/concepts/decisions/project-size).
You can change this setup in `nx.json` by adjustijng the `workspaceLayout` property which has an `appsDir` and `libsDir` configuration.
```json5
{
...
"workspaceLayout": {
"appsDir": "apps",
"libsDir": "libs"
},
...
}
```
## Q: Is there a way to migrate from CRA?
Absolutely. Check out this guide on the Nx docs that has all the details (including a video walkthrough): [/recipes/adopting-nx/adding-to-existing-project](/recipes/adopting-nx/adding-to-existing-project)
## Q: This looks like a lot 🤯. Do I really need it from the get go?
Agreed. Luckily Nx is plugin based, so you can start with the bare minimum (see using [Nx without plugins](/getting-started/intro)) and then slowly add them as you need them. Similarly you can add Nx to an existing workspace (say a Yarn workspace) by using the [add-nx-to-monorepo](https://www.npmjs.com/package/add-nx-to-monorepo) package.
From my own experience, what usually happens is that teams start light and then over time end up with a similar stack, but hand-woven and therefore loosing out on a lot of the benefits Nx comes with.
## Q: Isn’t Nx just for monorepos?
Nx has been designed to support monorepo scenarios, and it really shines at scale. However, a lot of the features I’ve been mentioning in this article, such as generators, out of the box setup of best practices development tools, automated migrations and more make it an excellent choice, even if your intention is not to create a monorepo.
From my experience, I’ve often seen teams start with a single application, which then over time gets company by other apps, in the form of React applications, also Node based backends or even a React Native application. Mainly because adding new applications is easy and the possibility to [share functionality (even across platforms)](/blog/share-code-between-react-web-react-native-mobile-with-nx) is appealing.
> _If you’re interested in monorepos or want to learn more about it, check out_ [_https://monorepo.tools_](https://monorepo.tools/)_._
## Q: Isn’t Nx just for Angular projects?
This is a common but understandable misconception. Although Nx was heavily inspired by the Angular CLI initially, it is now a completely independent build system and CLI with first-class support for Angular, React, Node, Next.js, TypeScript and more. And with tons of [community plugins](/community) that extend Nx beyond that.
## Conclusion
Congrats, you made it to the end of this article. By now you should have gotten a pretty good overview of what Nx is about, its strengths and how it can be useful in your next React project. If you still got questions or are hesitant to adopt Nx, [reach out to me on Twitter](https://twitter.com/juristr)!
Where to go from here?
- [Nx Official Discord Server](https://go.nx.dev/community)
- [follow me on Twitter](https://twitter.com/juristr)
- [follow Nx on Twitter](https://twitter.com/nxdevtools)
- subscribe on the [Nx Youtube channel](https://youtube.com/c/Nrwl_io)
- join more than 200+ developers and [take the free Egghead course](https://egghead.io/courses/scale-react-development-with-nx-4038) on how to scale React development with Nx.
It has been a while since our last release blog post [which was on Nx 13.5](/blog/new-terminal-output-performance-improvements-in-nx-13-5). A lot has happened since then. So here we go!
## Housekeeping and “core” cleanup
We keep optimizing the Nx core. This round we started doing some housekeeping and cleanup that will allow us to move more quickly in the future and add new features more easily. In particular we now have a single package `nx` that contains all the core and CLI related functionality that have previously been in `@nrwl/cli` and `@nrwl/tao`. This also results in a reduce number of packages you need to install in any Nx workspace. In fact, if you run `add-nx-to-monorepo` - our easy migration command for [adding Nx to Yarn/NPM workspaces](/recipes/adopting-nx/adding-to-monorepo) - you should now see a single `nx` package and not have any `@nrwl/*` packages at all.
## Nx Daemon on by default
One of the core features of Nx is the calculation of the project graph. It is the basis for most other features in Nx like the [affected commands](/ci/features/affected), computation caching and calculation and topological sorting of parallelizing tasks [during DTE](/ci/features/distribute-task-execution). This is a I/O heavy operation. Whenever you change a file, the project graph needs to be re-calculated which involves reading the source files, analyze imports from other packages’ source files and external libraries.
Such a crucial and central feature like the project graph need to be as fast as possible. That’s the reason why we introduced the Nx Daemon, which is started automatically and runs in the background, watching for file changes and asynchronously recomputes and caches the project graph. As a result, whenever Nx runs an operation that requires the project graph, it is already there and ready to be used, without adding any additional delay to the operation that needs to be executed.
Read more on the docs: [/guides/nx-daemon](/concepts/nx-daemon)
## Nx Cloud opt-in now points to “Yes” by default
When you set up a new Nx workspace with `create-nx-workspace` the question about opting into Nx Cloud will be pointed on “Yes” by default now.
_Nx Cloud opt-in when setting up a new Nx workspace_
## Build and run Nx Plugins locally in your Nx workspace
Nx can be used in a wide range of scenarios, from small open source projects, startup environments to massive enterprise monorepos. This is thanks to its modular plugin based architecture consisting of
- Nx core which provides the fundamental features such as the dependency graph calculation, computation caching and task execution
-`@nrwl/*` plugins which are those actively maintained by the Nx core team
- [Community plugins](/community)
This illustration should give you a rough idea. obviously some of the plugins may be built on top of others, leveraging common functionality. An example is the [@nrwl/js](/nx-api/js) plugin which not only can be used as a standalone plugin but also builds the basis for of many others by providing core JavaScript/TypeScript features.
You can just use the [Nx core without any plugins](/getting-started/intro) to get started and later decide to add more plugins such as `@nrwl/react` or `@nrwl/js` etc depending on your specific use case.
As you can see, plugins are at the very core and for quite some time now we’ve had a [fully featured Devkit and Nx Plugin package](/extending-nx/intro/getting-started) to create your own. And the community followed: have a look at [all the community Nx plugins that are available out there](/community).
And we keep improving. Starting with Nx 13.10 you can now use Nx plugins to automate your local workspace. Install `@nrwl/nx-plugin` into your Nx workspace and generate a new plugin:
This creates a new library with a pre-configured setup to develop a Nx plugin. Similarly to other libraries you can now use those in your local Nx target configurations.
```json5
{
root: 'apps/demo',
sourceRoot: 'apps/demo/src',
projectType: 'application',
targets: {
mybuild: {
executor: '@myorg/workspace-extensions:build',
outputs: ['{options.outputPath}'],
options: {
outputPath: 'dist/apps/someoutput',
},
},
},
}
```
Note the `executor` definition of the `mybuild` target. It was never easier to create custom workspace executors.
And it doesn’t stop at the executors level. The local plugin setup comes with a generator setup too, which can be invoked just like
```shell
npx nx g @myorg/workspace-extensions:<generator-name>
```
where `@myorg` is your Nx workspace name you defined and `workspace-extensions` the plugin library name we’ve chosen. You are free to choose whatever suits you best. This new setup opens up a wide range of new possibilities including defining default workspace generators.
[Subscribe to our Youtube Channel](https://youtube.com/nrwl_io) for some upcoming tutorials and walkthroughs around this topic.
## Project Graph Visualization
We keep improving our project graph and make it more and more useful for visually exploring your Nx workspace. You can now click on an edge and list the files that cause it which can be extremely valuable during debugging.
_Improved Project Graph visualization showing information about the edges that connect nodes_
And this is just a sneak peak of what’s coming in Nx v14, so stay tuned!
## New “notDependOnLibsWithTags” Linter option
Having a decent monorepo setup is not always just about speed but also to have features in place that help you keep your code-base healthy and maintainable in the long run. The Nx module boundary lint rules are an example for that.
Read more about it in this article: [blog/mastering-the-project-boundaries-in-nx)
So far you have only been able to specify which tags a library is allowed to depend on using the `onlyDepndOnLibsWithTags` property. This made it cumbersome to define in some situations. Now you have a brand new property `notDependOnLibsWithTags`
```json5
{
// ... more ESLint config here "@nrwl/nx/enforce-module-boundaries": [
## Automatic Lint rule fixes for self circular dependencies and wrong imports across library boundaries
Whether by accident or by letting your IDE auto-add the import. It often happens that the path that is being used is via the library’s TS path mapping through the `index.ts` entry point. This leads to a circular dependency when also `tslib-c-another.ts` is exported via the `index.ts`. Nx’s module boundary lint rule correctly highlights this as can be seen in this screenshot.
_Self circular dependency issue within a Nx based library_
Adjusting these circular self references is easy, but can be cumbersome to find the correct imports and time consuming if you have hundreds of libs that might be affected by this. In the latest version of Nx we shipped a fix implementation for these lint rules, such that you can now conveniently add `--fix` to auto-adjust the imports:
```shell
npx nx lint tslib-c --fix
```
This will analyze your imports, find the correct file and adjust them accordingly:
Nx 13.10 introduces support for the latest React v18 release such that users can benefit from the latest features React has to offer. Check out our latest blog post on [“The React CLI you always wanted but didn’t know about”](/blog/the-react-cli-you-always-wanted-but-didnt-know-about) to learn more how to use Nx for React development.
## React Native gets Storybook support
We’ve drastically improved our support for React Native within Nx workspaces. Check out our latest blog posts on
- [Share code between React Web & React Native Mobile with Nx](/blog/share-code-between-react-web-react-native-mobile-with-nx)
- [Introducing Expo Support for Nx](/blog/introducing-expo-support-for-nx)
We are happy to announce that in addition to the before mentioned improvements, the React Native integration in Nx now also supports Storybook. Just use
or use Nx Console to get some more help in generating the Storybook setup.
## Ability to show all prompts when creating a new Nx workspace
By default when you create a new Nx workspace with `create-nx-workspace` you will see a couple of questions that help you find the correct setup for your needs. However, we just show a couple of the possible options, to not overwhelm you.
If however you’re curious, you can now append `--allPrompts` to get all possible questions asked 🙂
```shell
npx create-nx-workspace@next myorg --allPrompts
```
Alternatively you can browse the [API docs on the Nx website](/nx-api/nx/documents/create-nx-workspace) to find out more.
## Deliver the best possible TypeScript experience with `@nrwl/js`
You might have noticed our new `@nrwl/js` package we released a couple of months ago.
[We have big plans with this one](https://github.com/nrwl/nx/discussions/9716), not only making it the foundation for many of our other packages that need TypeScript compilation and support, but also the goto package for the best possible TypeScript experience.
## Nx Console Improvements
Here are some of the highlights in the latest Nx Console release.
## Nx Targets of VSCode Command Menu
You can now open the VSCode Command menu (Cmd + Shift + P or Win + Shift + P) and enter “Nx: Run Target” to invoke the Run Target menu which allows to choose the target to run as well as the project to execute the target on.
_Commands can be invoked from the VSCode Command menu_
## Run Target View now in sync with workspace commands
While initially the “Generate and Run Target” panel was a static list of the usual Nx targets, it is now a dynamically generated list based on your actual workspace commands. Hence, also your custom defined targets will automatically show up.
_Nx Console dynamically reads Nx targets from your Nx workspace now_
## Prompts for Angular CLI users
Nx Console has out of the box support to also be used on plain Angular CLI projects. With the latest version of Nx Console, Angular CLI users will receive a prompt about decorating their CLI setup with Nx to benefit from the improved performance brought by computation caching and Nx Cloud.
Besides delivering awesome features, we keep improving our docs. They are essential to help discover new features and better understand existing ones. In the last weeks we’ve improved the navigation support, allowing you to navigate to a specific package with `/packages/<package-name>` such as [/nx-api/react](/nx-api/react) listing executors and generators that come with that Nx package, also improving the API docs of the individual executor options including a live embedded editor playground to experiment with different configuration setup.
Check out Benjamin Cabanes’ tweet with some short videos:
Updating Nx is done with the following command, and will update your Nx workspace dependencies and code to the latest version:
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
npx nx migrate --run-migrations
```
## Exciting?
Then wait for Nx v14 to land 😉.
- Check out the [release changelog](https://github.com/nrwl/nx/releases/tag/13.10.0)
- Follow us [on Twitter](https://twitter.com/NxDevTools), and
- subscribe to the [YouTube Channel](https://youtube.com/nrwl_io?sub_confirmation=1) for more information on [Angular](https://angular.io/), [React](https://reactjs.org/), Nx, and more!
In my previous [blogs](/blog/share-code-between-react-web-react-native-mobile-with-nx) _(see links at the end)_, I wrote about how to develop Nx React Native applications. However, as developers, we are constantly searching for ways to make the developer experience better.
This blog will show how to add Storybook to Nx React Native applications. With Nx, you don’t need to go through [this long guideline](https://storybook.js.org/tutorials/intro-to-storybook/react-native/en/get-started/) to set up the Storybook, you can quickly get it running.
Example Repo: [xiongemi/studio-ghibli-search-engine](https://github.com/xiongemi/studio-ghibli-search-engine)
First, you need to add `@nrwl/storybook` to your existing Nx React Native workspace:
```shell
# npm
npm install @nrwl/storybook --save-dev
# yarn
yarn add --dev @nrwl/storybook
```
Then you need to generate the storybook configuration for your app or lib:
```shell
nx g @nrwl/react-native:storybook-configuration **<your app or lib>**
```
As shown in the example below, 3 folders got generated:
-`.storybook` at workspace root
-`.storybook` in your app or lib
-`storybook` in your app (Note: this folder is for creating the Storybook UI component. It will only be created for the app, you will not see this for lib.)
Note: the storybook can only be viewed inside an app. To view the storybook for lib in the workspace, you need to first set up the storybook for an app in the workspace.
Then run the command:
```shell
nx storybook **<your lib>**
```
This should update the `.storybook/story-loader.js` with stories in your lib.
Then just run the command to start your app, you should see the storybook for your lib.
## Troubleshooting
### Error: Couldn’t find a navigation object
If you are using the library `@react-navigation/native` and you are using hooks like `useNavigtion` and `useRoute` inside your component, you are likely to get the below error:
Now, this error should go away and you should see your component in your storybook.
If your component is using the `useRoute` hook and expecting certain routing parameters, then you need to customize the mock `NavigationDecorator` for your component. For example, below is a component that is expecting an id from the route parameters:
The simple solution is to mock the store. First, you need to install the library [redux-mock-store](https://github.com/reduxjs/redux-mock-store) and its typing:
If you use an async action (for example, an action created using `createAsyncThunk` from `@reduxjs/toolkit`), you would likely run into the below error: Actions must be plain objects.
Here are how to use Storybook with Nx React Native and some common errors you may run into. With Nx React Native, you can quickly view Storybook with a toggle option in Debug Menu. It allows developers to interact and test with components during development.
### Where to go from here?
- [Step by Step Guide on Creating a Monorepo for React Native Apps using Nx](/blog/step-by-step-guide-on-creating-a-monorepo-for-react-native-apps-using-nx)
- [Share code between React Web & React Native Mobile with Nx](/blog/share-code-between-react-web-react-native-mobile-with-nx)
- [join the Nx Official Discord Server](https://go.nx.dev/community)
- [follow Nx on Twitter](https://twitter.com/nxdevtools)
- subscribe to the [Nx Youtube channel](https://youtube.com/c/Nrwl_io)
A lot happened since we released Nx version 13 back in October 2021. Nx has roughly a 6-month major release cycle and so that time has come again: I’m happy to announce the **release of Nx v14**.
Those last 6 months have been incredible and Nx probably got the biggest boost ever in terms of simplicity, features, and speed. We even made Nx more beautiful. Join me to explore some of the biggest highlights and what makes v14 so incredible.
> _Nx is open source, so feel free to browse the_ [_repo_](https://github.com/nrwl/nx) _and_ [_changelog_](https://github.com/nrwl/nx/releases/tag/14.0.0) _by yourself 🙂_
**💡Did you have a chance to watch Nx Conf Lite 2022 last Friday?** Many of the new features have been discussed there, and more. You can watch the [entire stream on Youtube](https://youtu.be/iIZOfV0GFmU). All the single talk videos will be released over the next weeks too, so make sure you subscribe and switch on notifications 🙂: [https://youtube.com/nrwl_io](https://youtube.com/nrwl_io)
## Over 1.6 Million Downloads per week 🎉
We hit a major milestone with Nx v13 when we reached 1 million weekly downloads back in December 2021. Only 3 months later, we’re already over 1.6 million per week and growing fast!
Nx also outgrew Lerna in February in weekly downloads. Up until that point, [Lerna](https://lerna.js.org/) was considered the go-to choice when it comes to JS-based monorepos. But just recently, they made it [even more evident](https://github.com/lerna/lerna/pull/3092) that Lerna has been and is [largely unmaintained](https://github.com/lerna/lerna/issues/2703).
We saw that coming and made it easy for people to migrate to Nx.
```shell
npx add-nx-to-monorepo
```
There’s a detailed guide helping with some of the doubts and misconceptions which commonly come up with Lerna users: [https://lerna.js.org/](https://lerna.js.org/)
The future for monorepo tools looks bright as the awareness of monorepos, especially in the JS ecosystem, has grown a lot in recent months. Nx is doing great compared to those tools. But this movement excites us and we are more than ever committed to keep pushing forward and making Nx even better.
We made a lot of improvements in Nx core since v13 that can roughly be categorized into: making Nx faster, simpler and improved dev ergonomics. Let’s explore some of the highlights there
## Making Nx even faster!
Being as fast as possible is a key design principle in Nx. Back in December we [tweeted about our speed benchmarks](https://twitter.com/victorsavkin/status/1471582667212738562?s=20&t=fZQ82vUXMztNXFRMmuYQTw) and we keep running them against our releases to see how we compare.
Turns out the latest Nx v14 release is considerably faster than Nx v13:
- Nx v13: 1.587 seconds
- Nx v14: 0.259 seconds
You can check and run the benchmarks by yourself: [https://github.com/vsavkin/large-monorepo](https://github.com/vsavkin/large-monorepo)
How can Nx be so fast? One thing we did introduce after v13 and [recently enabled by default](/blog/what-is-new-in-nx-13-10) is the **Nx Daemon**. There is a fixed amount of computation that needs to happen in every workspace and which increases as the workspace grows. In order to still keep operations fast, we can now use the Nx Daemon to precompute a lot of the operations in the background. Then whenever some Nx operation is triggered, they can directly benefit from that.
> **_Running into a performance issue?_** _Try to debug it by using_ `_NX_PERF_LOGGING=true_` _in combination with your Nx command:_ `_NX_PERF_LOGGING=true nx build crew_`_. Alternatively, you can also have Nx generate a_ `_profile.json_` _and import it into Chrome Devtools._ [_Read more about that here_](/troubleshooting/performance-profiling)_._
While a lot of the above improvements help with local development, one of the biggest pain points of having a large monorepo can be CI times. This is where **distributed task execution (DTE)** makes all the difference\*_._\* Nx Cloud’s DTE understands which commands your CI is running, how many agents are typically being used, and how long a given task typically takes. It leverages that information along with task dependencies to create an execution plan that prioritizes builds of shared libraries first to unblock upstream builds. This results in a more even utilization of CI agents, optimizing the overall running time of your CI.
Over time, Nx Cloud’s DTE learns about your workspace, keeping metrics about running times to allow the best possible distribution of a given task with the given amount of agents. This comes with Nx Cloud.
> _Note, if you are a large enterprise, you might want to look into the_ [_Nx Private Cloud_](/enterprise) _offering which allows to self-host Nx Cloud within your own infrastructure._
Also see this example repository with some more information: [https://github.com/vsavkin/interstellar](https://github.com/vsavkin/interstellar)
## Simplifying Nx
Nx follows a modular plugin architecture. There is the core part of Nx which has the main logic around managing the project graph, computation caching, hashing and more. On top of that we have a series of Nx provided plugins for some of the most common frameworks and libraries out there, like [TypeScript/Javascript](/nx-api/js), [Angular](/nx-api/angular), [React](/nx-api/react) & [React Native](/nx-api/react-native), [Next.js](/nx-api/next), [Nest.js](/nx-api/nest), [Node](/nx-api/node) and many more, not to forget about [all the community plugins](/community). We also have a [labs project section](https://github.com/nrwl/nx-labs) which is our incubator for potentially new, natively supported Nx plugins.
This modular structure allows you to just use [Nx core without plugins](/getting-started/intro). An ideal approach if you want to add Nx to an [existing Lerna/Yarn/NPM/PNPM workspace](/recipes/adopting-nx/adding-to-monorepo). With v14 we made it even simpler s.t. now you only have a single `nx` package in your dependencies with the core setup.
From there you can go ahead and add new plugins as you need them, thus gradually enhancing the capabilities of your Nx workspace.
Nx is also able now to directly pick up your `package.json` scripts which are common in NPM/Yarn workspaces. Read more here: [/reference/project-configuration](/reference/project-configuration)
## Terminal Output
Developer experience is highly important to us. And that doesn’t stop at the terminal output which is something we developers constantly interact with throughout our entire workday. We, therefore, put a lot of love for the details into how we present our terminal output, improving it in a way to show all completed tasks towards the top, while information about the current progress is shown below
_(here executed by skipping the cache to show some progress running_ 🙂*)*
We now even filter out the build of dependent projects. Say you build the `react` project in your workspace which depends on 11 other projects. Nx needs to first incrementally build those 11 dependent projects, which it does now in a very subtle way by just reporting the overall progress at the top of the terminal output, while the main `react` project build output is printed just as normal.
Obviously, all errors would be reported properly, and on CI this behavior is disabled by default. If you want to disable it, you can always set `NX_TASKS_RUNNER_DYNAMIC_OUTPUT` to false.
## “Local Plugins” for your Nx Workspace
[Check out our previous release post](/blog/what-is-new-in-nx-13-10) where we went into some of the details on how local plugins work. But in a nutshell, you can now generate a plugin into an existing Nx workspace:
Now normally you would develop it there, and then publish it to npm s.t. others can install it into their Nx workspaces. Since one of our recent versions of Nx, we now also allow you to directly use them in the same Nx workspace, without the need to pre-compile or publish your plugin.
```json
{
"root":"apps/demo",
"sourceRoot":"apps/demo/src",
"projectType":"application",
"targets":{
"mybuild":{
"executor":"@myorg/workspace-extensions:build",
"outputs":["{options.outputPath}"],
"options":{
"outputPath":"dist/apps/someoutput"
}
}
}
}
```
This can be a game changer for automating your Nx workspace.
## Automating CI Setup
Ever struggled with setting up CI? Especially in a large monorepo? We got your back now, with the new `--ci` generator that we introduced in Nx v14.
This sets you up with an automated CI workflow that properly uses the Nx affected command together with the power of [Nx Cloud’s distributed task execution](/ci/features/distribute-task-execution).
You can also use the `--all` flag when generating a new workspace, for seeing all the available options, including to setup CI.
## nx-cloud record
The [Nx Cloud GitHub app](https://github.com/apps/nx-cloud) is so useful for not having to go to your CircleCI logs and try to find the entry you’re searching for. Instead all the executed targets nicely show up as a comment in your PR.
Until now, you had to have a task that is being executed through Nx Cloud. But what about those workspace utility scripts, like checking the commit format etc. You can now use `nx-cloud record` for those, like
```shell
npx nx-cloud record -- npx nx format:check
```
and they will automatically show up in the Nx Cloud viewer. 🤫 you don’t even have to have Nx Cloud installed in the workspace.
## Module Federation for Faster Builds
For many workspaces it is enough to leverage [Nx affected commands](/ci/features/affected), [computation caching](/concepts/how-caching-works) and [distributed task execution](/ci/features/distribute-task-execution).
However, if you have a huge monorepo, this might not be enough. You can add incremental builds and benefit from caching, but still, you might run into the issue of the final linking process taking a long time, which can hardly be optimized further. Unless you can split up your app into smaller pieces. No, we’re not talking about micro frontends necessarily (more on that in the next section). Rather we can leverage Webpack’s Module Federation support.
We added dedicated generators to create a new module federation setup for Angular and React:
```shell
# React
nx g @nrwl/react:host shell --remotes=shop,cart,about
#a Angular
nx g @nrwl/angular:host shell --remotes=shop,cart,about
```
By specifying the `implicitDependencies` in Nx ([see docs](/reference/project-configuration)) Nx knows what the relation between the various apps is, even though there are not direct imports
Combining this with the power of Nx Cloud distributed caching, you can now serve your shell project
```shell
npx nx serve shell
```
and all the other remotes are statically served from the cache. Your entire infrastructure is working, without you having to worry about building and serving all of the separate remotes. As you can imagine this speeds up local serve times by an order of magnitude.
If you want to work on one of the remotes, simply explicitly pass their name using `--devRemotes` flag and it will be served just normally with the Webpack dev server, with all the features you’re used to.
```shell
npx nx serve shell --devRemotes=cart,shop
```
This can be a game-changer when building huge apps. Stay tuned for more content around this as we’re really just getting started.
We recommend this approach if you want to speed up local serve and build times, but you still deploy the application as a whole.
Read more on our docs: [/concepts/module-federation/faster-builds-with-module-federation](/concepts/module-federation/faster-builds-with-module-federation)
## Micro Frontend Architecture with Nx
As mentioned in the previous section, Nx v14 comes with out-of-the-box for Webpack Module Federation. The Micro Frontend architecture builds on top of that and adds the ability for independent deployability. While Module Federation enables faster builds by vertically slicing your application into smaller ones, the MFE architecture layers _independent deployments_
on top of federation. Teams should only choose MFEs if they want to deploy their host and remotes on different cadences.
Read more on our docs: [/concepts/module-federation/micro-frontend-architecture](/concepts/module-federation/micro-frontend-architecture)
## Dark mode for Project Graph as well as path tracking
You asked for it, the community responded. [Luís Carvalho](https://github.com/Lcarv20) - a first time contributor - worked together with Nx core team members Philip and Ben to deliver dark mode for the project graph visualization!!
In version 13.4 we released a brand new dedicated package for developing pure JavaScript/TypeScript packages: `@nrwl/js`
We kept improving it, adding SWC support (including an easy migration between TSC → SWC using an Nx generator) and we’re currently looking into automated publishing support.
Read all the details on our docs: [/getting-started/intro](/getting-started/intro)
## React
Nx v14 ships with React 18 support for React DOM and React Native. The latter has seen some drastic improvements since Nx v13, adding [guides on how to create a monorepo for React Native](/blog/step-by-step-guide-on-creating-a-monorepo-for-react-native-apps-using-nx) apps with Nx as well as how to [share code between a React Web and React Native app](/blog/share-code-between-react-web-react-native-mobile-with-nx). We also added Storybook support to React Native. Read all about that in [our recent blog post](/blog/use-storybook-with-nx-react-native).
In addition to that, Expo and Expo Application Service support has been added which has lead already to some drastic speed improvements with some of our clients.
Finally, it is the first version which ships the built-in module federation support for React as we’ve mentioned a couple of sections above. Check out the React package docs page and search for the `host` and `remote` generator: [/nx-api/react](/nx-api/react)
## Angular
There have been a lot of highlights for the Nx Angular plugin since v13. Here are some:
- Support and migrations for Angular 13 (Angular v14 coming soon. We will release that as a minor upgrade in Nx once the Angular team releases v14)
- Tailwind CSS support (generators, added support to library executors). Read [our blog detailed post](/blog/set-up-tailwind-css-with-angular-in-an-nx-workspace).
- Single Component Application Modules (SCAM) generators for components, directives and pipes ([see our docs](/nx-api/angular))
- Improved Angular CLI to Nx migration support. We invested quite some time refactoring our current migration support from the Angular CLI which not only will allow us to implement more migration scenarios in the future but it also provides better error messages and hints during the migration process. This also allowed us to add support for multi-project Angular CLI workspaces which can now be seamlessly migrated. Multi-application Angular CLI workspace support will be added soon.
Finally, similar to React also Angular gets built-in support for Webpack Module federation and hence also Microfrontends within Nx. See the sections about Module Federation and Microservices for more info and links to the docs.
## Improved docs
Docs are hard! But we keep investing and a lot of work has gone into making docs more organized and even more interactive.
Check out our previous release blog posts for all the details:
- [Single File Monorepo Config, Custom Workspace Presets, Improved Tailwind Support, and more in Nx 13.4!](/blog/single-file-monorepo-config-custom-workspace-presets-improved-tailwind-support-and-more-in-nx-13)
- [New Terminal Output & Performance Improvements in v13.5](/blog/new-terminal-output-performance-improvements-in-nx-13-5)
- [What’s new in Nx v13.10?](/blog/what-is-new-in-nx-13-10)
## How to Update Nx
Updating Nx is done with the following command, and will update your Nx workspace dependencies and code to the latest version:
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
npx nx migrate --run-migrations
```
## Exciting?
We already started working on v15. You can [find the roadmap on our GitHub repository](https://github.com/nrwl/nx/discussions/9716). There are some exciting things coming up, like
- “Negative” Configuration
- React Server Side Rendering and Server Components support
- React Native + Detox
- Cypress v10 migration and Cypess Component Testing
- ...
Make sure you don’t miss anything by
- Following us [on Twitter](https://twitter.com/NxDevTools), and
- Subscribe to the [YouTube Channel](https://youtube.com/nrwl_io?sub_confirmation=1) for more information on [Angular](https://angular.io/), [React](https://reactjs.org/), Nx, and more!
- Subscribing to [our newsletter](https://go.nx.dev/nx-newsletter)!
> _We,_ [_Nrwl_](/company)_, the company behind Nx, are taking over the stewardship of Lerna.js, the popular JS monorepo tool._ [_Here’s the official announcement on the Lerna repo_](https://github.com/lerna/lerna/issues/3121)_. We are thrilled and committed to helping the Lerna community move forward!_
## Who is Nrwl?
We (Nrwl) are the company behind Nx ([GitHub](https://github.com/nrwl/nx)) and we have been founded by two ex-Googlers and Angular core team members [Jeff Cross](https://twitter.com/jeffbcross) and [Victor Savkin](https://twitter.com/victorsavkin). Experiencing a large-scale monorepo in action at Google, gave them a lot of insights into the advantages and productivity gains for software teams as well as the features and tooling support that is required to make monorepos work, especially at a large scale. When they left Google, they decided to bring such a tool to the masses, but with a clear goal of
- building it in the open as an open-source product and
- making it approachable and easy to use by focusing on great DX
This is when Nx started.
We think we are the best fit for helping the Lerna community continue and thrive because we have a good combination of real-world experience with open source community work. As part of Nrwl, we work with some of the world’s biggest companies, helping them improve productivity and ship great quality software through monorepos. In addition, Jeff and Victor have a lot of knowledge of managing a big open source project such as Angular when they were at Google and obviously at Nrwl from managing Nx as an open-source project with its quickly growing community.
Long story short, Nrwl ❤️ open source and community work, and we are thrilled to work with the Lerna community!
## What’s the story about Lerna being dead?
_(Spoiler: It is not dead, we took over stewardship_ 😀*. But apart from that, here’s the whole story)*
- August 2020 — Issue is being opened [mentioning that Lerna is largely unmaintained](https://github.com/lerna/lerna/issues/2703)
- April 2022 — A [PR gets merged](https://github.com/lerna/lerna/pull/3092) that properly highlights the fact of Lerna being unmaintained at the very top of the repository README. This made the “Lerna is dead” discussions flare up again.
- May 2022 — Lerna got resurrected: Nrwl takes over
While that last PR didn’t really change the fact that Lerna has been in that state for the past years already, it just made it more apparent and also how many still rely on Lerna today.
And this is not to blame its contributors at all. They did an amazing job. However, Open Source can be a tough place, especially if it is not backed by a large community and/or company that helps make the work sustainable in the long run. Taking the weight of maintaining such a widely used tool, and then mostly for free, is a huge one. Burnout is real folks, so take care. And we’ve had lots of such open-source examples in the past years.
## Nrwl is taking over: now what?
Lerna has definitely pioneered the JS monorepo space, however, the tooling space has progressed a lot in recent years. Some of its features are now baked into NPM, YARN, PNPM, and Lerna [lacks many other important monorepo features](https://monorepo.tools/#tools-review) such as computation caching to mention one example.
Nx can fill in many of these gaps. When the first discussions about Lerna being unmaintained came up in 2020, we implemented a set of features, allowing for easy migration from [Lerna/NPM/Yarn/PNPM workspaces to Nx](/recipes/adopting-nx/adding-to-monorepo). In addition, some recent [improvements in Nx](/blog/nx-v14-is-out-here-is-all-you-need-to-know) make this even easier, allowing it to basically co-exist in any of these workspaces. This can be done for instance by leveraging [Nx’s powerful task scheduling capabilities](/getting-started/intro) while still continuing on relying on Lerna’s publishing process. Maintaining now both projects, Lerna & Nx, puts us in the unique position of allowing us to work on some seamless integration between the two.
With Nx, we are known to have a clear roadmap shared with the community of what our next 6 months’ focus will be (here’s an [example of our roadmap for v15](https://github.com/nrwl/nx/discussions/9716)). As we get our hands dirty on Lerna’s codebase in the coming weeks, we are going to define a set of action items, prioritize them and elaborate a proper roadmap as well, which we will share with the community as soon as we have a more concrete plan. Since we know many organizations still depend on Lerna or may not be able to migrate away soon, some of our immediate to mid-term actions will be to **provide critical bug fixes and security updates to the project** and regularly release those to NPM.
## Stay tuned for more!
We think Lerna’s and Nx’s future is bright and we are excited to help move the monorepo space forward, more than ever before!
Make sure you don’t miss anything by
- Following us [on Twitter](https://twitter.com/NxDevTools)
- Subscribing to our [YouTube Channel](https://youtube.com/nrwl_io?sub_confirmation=1)
- Subscribing to [our newsletter](https://go.nx.dev/nx-newsletter)!
**_TL;DR:_**_We released a new beta version of Lerna and it happens that it is now 5.3 times faster than Turbo 👀…by turning on a flag. Keep reading to learn more._
> _ICYMI: A couple of weeks ago we (Nrwl) announced that we take over stewardship of Lerna. Read all about it in our_ [_recent blog post_](/blog/lerna-is-dead-long-live-lerna)_.
> We also just released Lerna v5 as a first maintenance release:_ [_Read more here_](https://github.com/lerna/lerna/releases/tag/v5.0.0)_._
For folks that want to migrate to Nx, we always had a dedicated [Nx and Lerna](/recipes/adopting-nx) docs page that shows you how you can easily integrate the two. However, we felt we could do better and allow you to get all the speed benefits that come from Nx’s task scheduling abilities, without needing to change nearly anything in your Lerna workspace.
We just published Lerna v5.1 which introduces a `useNx` flag. Adding that makes Lerna to be on par with Nx in terms of speed, and is significantly faster than other tools.
Comparing Lerna with and without the flag isn’t really an apples-to-apples comparison because one comes with caching abilities, while before, Lerna didn’t have that at all. But just to give you an idea: enabling Nx on your existing Lerna workspace can **speed it up in the range of 2–10 times**, depending on the repo setup.
But let’s do some more real “apples-to-apples” comparison of Lerna’s speed with `useNx` enabled. For benchmarking Nx we have set up a repo in the past which we regularly use to measure the speed of new Nx releases with other similar tools on the market such as [Lage](https://microsoft.github.io/lage/) and [Turborepo](https://turborepo.org/): [https://github.com/vsavkin/large-monorepo](https://github.com/vsavkin/large-monorepo). We now added Lerna+Nx (Lerna with `useNx` enabled) to that repo to measure the impact.
Here’s a gif of running the benchmark of Lerna+Nx and Turborepo:
**Lerna+Nx is 5.3 times faster** than Turborepo 🚀.
As always, you can reproduce the benchmark by yourself by going to the [benchmark repo](https://github.com/vsavkin/large-monorepo). The readme includes all the details on how to run it on your own machine. We verified it in detail, but if for some reason we got something wrong, please reach out!
## What do I need to do to upgrade?
First of all, upgrade to Lerna v5.1. That release comes with the ability to delegate task running to Nx. Next you need to add Nx as a dependency: `npm i nx --save-dev`
Finally, add the following to your `lerna.json`.
```json5 {% fileName="lerna.json" %}
{
...
"useNx": true
}
```
That’s mostly it. You can continue using the usual Lerna commands, but at this point Lerna would delegate its operations to Nx underneath.
To get more out of it, you might want to create a small `nx.json` file (or run `npx nx init` to generate one) for going into some more details on configuring the cacheable operations:
```json5 {% fileName="nx.json" %}
{
extends: 'nx/presets/npm.json',
tasksRunnerOptions: {
default: {
runner: 'nx/tasks-runners/default',
options: {
cacheableOperations: ['build'],
},
},
},
}
```
Note that `useNx` is opt-in and set to `false` by default. Also, if someone is worried about the license, Nx has been open source from the very beginning, using the MIT license.
## How does this work under the hood?
So how does this work on a technical level. So far Lerna (`lerna run` to be more specific) has been delegating the task scheduling to `p-map` or `p-queue`. Meanwhile though, the industry has advanced and tools like Nx are much more powerful and efficient in their task orchestration and in addition also support caching.
With the change we made in Lerna 5.1 we are adding Nx (MIT licensed) as a third option in addition to the already existing `p-map` and `p-queue`. By having `nx` installed and configured (as mentioned in the previous section), Lerna can now delegate its `lerna run` command to Nx directly. All of this is done in a backwards-compatible way: every `lerna run` command will work but will be significantly faster and can optionally even be distributed across multiple machines without any config (more about that in the next section).
## What’s more?
By having Nx integrated, you not just get faster builds but also some other Nx’s features for free!
[**Nx Project graph**](/features/explore-graph) — By running `npx nx graph` you get the visualization of the graph. You can interactively explore what your workspace looks like and the relationships between the packages. We actually used this same graph on the Lerna repo itself, which helped us to get a better understanding of how the repo is structured when we took over the maintenance. Here’s an example of filtering the lerna packages to understand what `@lerna/exec` is about and how it relates to other packages in the repo.
**Distributed caching** — Right now when you enable `useNx` in your existing Lerna repo, you will get local caching, meaning the cache sits in a local folder on your machine. You get much more value out of it when you start distributing and sharing it with your teammates but especially in CI. This can be done by adding Nx Cloud, which comes with a no-credit card, 500 hours free / month offer which is more than what most workspaces need. Adding that is easy and can be done by adding `@nrwl/nx-cloud` to your root-level `package.json` and then by running:
```shell
npx nx connect-to-nx-cloud
```
**Distributed task execution** — Distribution of the cache is one thing, but the real speed improvements come from also [distributing the task execution](/ci/features/distribute-task-execution) to speed up your CI. Having the Nx project graph and as well as the cache and historical data about previous runs, Nx Cloud DTE is able to maximize the CI agent utilization by evenly distributing tasks based on their (historical) duration as well as based on their topological order. In addition, the DTE process makes sure to properly move cached assets between the agents. Setting up DTE is straightforward, read more on our [Nx Cloud docs](/ci/features/distribute-task-execution). Hint: we also have a CI generator in Nx (you need the `@nrwl/workspace` package) that allows you to generate your CI setup using a single command: `npx nx generate @nrwl/workspace:ci-workflow --ci=github`
**Lerna roadmap** — We also just published a roadmap of the next steps for the Lerna repository. Check it out here: [https://github.com/lerna/lerna/discussions/3140](https://github.com/lerna/lerna/discussions/3140)
## Conclusion
This is the first beta which we are trying out on some projects already. We aren’t worried about task orchestration, caching or distribution — all of those are done by Nx, which has been around for 5 years and is solid. We are trying to see if there is something in the integration that is confusing. We hope to release s stable version by mid-June.
Please have a look, upgrade your repo and [open an issue](https://github.com/lerna/lerna/issues) if you run into some weird behavior with the new `useNx` enabled. But not only that, feel free to ping us on the [@NxDevTools](https://twitter.com/nxdevtools) account with your success stories too. We'd love to hear 😃.
In this article we’re going to have a deep dive into setting up a new monorepo using [PNPM workspaces](https://pnpm.io/workspaces) that hosts a Remix application as well as a React-based library. We will learn how to run commands with PNPM, how to run them in parallel and finally we’re going to add Nx for a more sophisticated task scheduling, including command caching and more.
**Important:** If you are already familiar with the setup and configuration of a new PNPM workspace, feel free to skip to the part where we add Nx later in the article.
To get started, let’s make sure you have PNPM installed. The [official docs have an installation page](https://pnpm.io/installation) with detailed instructions. I also recommend using something like [Volta](https://volta.sh/) in particular if you have to deal with multiple different versions of NPM/PNPM and node versions.
Let’s create a new folder named `pnpm-mono`, cd into it and then run `pnpm init` to generate a top-level `package.json`. This will be the root `package.json` for our PNPM monorepo.
```shell
❯ mkdir pnpm-mono
❯cd pnpm-mono
❯ pnpm init
```
It is probably also handy to initialize a new Git repository such that we can commit and backup things as we progress in the setup:
```shell
git init
```
At this point let’s also create a `.gitignore` file to immediately exclude things like `node_modules` and common build output folders.
```.gitignore {% fileName=".gitignore" %}
node_modules
dist
build
```
## Setting up the Monorepo structure
The structure of a monorepo might vary depending on what you plan to use it for. There are generally two kinds of monorepo:
- **package centric** repositories which are used for developing and publishing a cohesive set of reusable packages. This is a common setup in the open source world and can be seen in repositories such as [Angular](https://github.com/angular/angular), [React](https://github.com/facebook/react), [Vue](https://github.com/vuejs/vue) and many others. Those repos are characterized by most commonly having a `packages` folder and which are then commonly published to some public registry such as [NPM](https://npmjs.com/).
- **app centric** repositories which are used mainly for developing applications and products. This is a common setup in companies. Such repos are characterized in having an `apps` and `packages` or `libs` folder, where the `apps` folder contains the buildable and deployable applications, while the `packages` or `libs` folder contains libraries that are specific to one or multiple applications that are being developed within the monorepo. You can still also publish some of these libs to a public registry.
In this article we’re going to use the “app centric” approach, to demonstrate how we can have an application that consumes packages from within the monorepo.
Create an `apps` and `packages` folder within `pnpm-mono`:
```
❯ mkdir apps packages
```
Now let’s configure PNPM to properly recognize the monorepo workspace. Basically we have to create a `pnpm-workspace.yaml` file at the root of the repository, defining our monorepo structure:
```yaml {% fileName="pnpm-workspace.yaml" %}
packages:
# executable/launchable applications
- 'apps/*'
# all packages in subdirs of packages/ and components/
- 'packages/*'
```
## Adding a Remix application
We should now be ready to add our first application. For this example I picked [Remix](https://remix.run/) but you can really host any type of application in here, it won’t really matter.
> _Info: We use the normal_ [_Remix installation & setup procedure_](https://remix.run/docs/en/v1) _here which you can find on their docs page._
Since we want to have the app within the `apps` folder, we need to `cd` into it:
```shell
cd apps
npx create-remix@latest
```
You will be asked for an app name. Let’s just go with “my-remix-app” which we’ll be using for the rest of this article. Obviously feel free to use a different one. In addition, the Remix setup process is also going to ask you a couple of questions that customize the exact setup. The particular options are not really relevant for our article here, so feel free to choose whatever best suits your needs.
You should have now a Remix app, within the `apps/my-remix-app` folder or whatever name you chose. Remix has already a `package.json` with corresponding scripts configured:
```json
{
"private": true,
"sideEffects": false,
"scripts": {
"build": "remix build",
"dev": "remix dev",
"start": "remix-serve build"
},
...
}
```
Usually, in a monorepo you want to run commands from the root of the repository to not have to constantly switch between folders. PNPM workspaces have a way to do that, by passing a `filter` argument, like:
```shell
pnpm --filter <package-name> <command>
```
Now it happens (at the writing of this article) that Remix’s default `package.json` doesn't have a `name` property defined which PNPM wants to run the package. So let's define one in the `apps/my-remix-app/package.json`:
```json
{
"name": "my-remix-app",
"private": true,
"sideEffects": false,
...
}
```
You should now be able to serve your Remix app in dev-mode by using:
Now that we have our app set up, let’s create a library package that can be consumed by our application.
```shell
cd packages
mkdir shared-ui
```
Next, let’s create a `package.json` with the following content (you can also use `pnpm init` and adjust it):
```json
{
"private": true,
"name": "shared-ui",
"description": "Shared UI components",
"scripts": {},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {},
"devDependencies": {}
}
```
Note, we declare it as `private` because we don't want to publish it to NPM or somewhere else, but rather just reference and use it locally within our workspace. I also removed the `version` property since it is not used.
As the technology stack I’ve chosen to go with [React](https://reactjs.org/) (so we can import it in Remix) and [TypeScript](https://www.typescriptlang.org/) (because it can almost be considered a standard nowadays). Let’s install these dependencies from the root of the workspace:
```shell
pnpm add --filter shared-ui react
pnpm add --filter shared-ui typescript -D
```
By passing `--filter shared-ui` to the installation command, we install these NPM packages locally to the `shared-ui` library.
> _Info: Be aware that this might potentially cause version conflicts if the React/TypeScript version used by the library package and the consumer (e.g. our app) differs. Adopting a_ [_single version policy_](https://opensource.google/documentation/reference/thirdparty/oneversion)_, where you move the packages to the root of the monoreopo, is a possible solution for that._
Our first component will be a very simple `Button` component. So let's create one:
For sake of simplicity we just use the TypeScript compiler to compile our package. We could have some more sophisticated setup for bundling multiple files together etc with something like [Rollup](https://rollupjs.org/guide/en/) or whatever you prefer using, but that’s outside the scope of this article.
To create the desired compilation output create a `packages/shared-ui/tsconfig.json` file with the following configuration.
> _In a monorepo it is good practice to extract the common config part into a higher-level config (e.g. at the root) and then extend it here in the various projects. This to avoid a lot of duplication across the various monorepo packages. For the sake of simplicity I kept it all in one place here._
As you can see the `outDir` points to a package-local `dist` folder. So we should add a main entry point in the `shared-ui` package's `package.json`:
```json
{
"private": true,
"name": "shared-ui",
"main": "dist/index.js"
}
```
Finally, the actual build consists of deleting some residual folders from the previous output and then invoking the TypeScript compiler (`tsc`). Here's the complete `packages/shared-ui/package.json` file:
```json
{
"private": true,
"name": "shared-ui",
"description": "Shared UI components",
"main": "dist/index.js",
"scripts": {
"build": "rm -rf dist && tsc"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"react": "^17.0.2"
},
"devDependencies": {
"typescript": "^4.6.4"
}
}
```
Use the following command to run the build from the root of the PNPM workspace:
```shell
pnpm --filter shared-ui build
```
If the build succeeds, you should see the compiled output in the `packages/shared-ui/dist` folder.
## Consuming our shared-ui package from the Remix app
Our `shared-ui` library is ready so we can use it in the Remix application hosted within the `apps` folder of our repository. We can either manually add the dependency to Remix's `package.json` or use PNPM to add it:
This adds it to the dependency in the `apps/my-remix-app/package.json`:
```json
{
"name": "my-remix-app",
"private": true,
"sideEffects": false,
...
"dependencies": {
...
"shared-ui": "workspace:*"
},
...
}
```
`workspace:*` denotes that the package is resolved locally in the workspace, rather than from some remote registry (such as [NPM](https://npmjs.com/)). The `*` simply indicates that we want to depend on the latest version of it, rather than a specific one. Using a specific version really just makes sense if you're using external NPM packages.
To use our `Button` component we now import it from some Remix route. Replace the content of `apps/my-remix-app/app/routes/index.tsx` with the following:
If you now run the Remix app again you should see the button being rendered.
```shell
pnpm --filter my-remix-app dev
```
If you happen to get the following error, then it is because you need to build `shared-ui` first
```shell
Error: Cannot find module '/Users/juri/nrwl/content/pnpm-demos/pnpm-mono/apps/my-remix-app/node_modules/shared-ui/dist/index.js'. Please verify that the package.json has a valid "main" entry
at tryPackage (node:internal/modules/cjs/loader:353:19)
at Function.Module._findPath (node:internal/modules/cjs/loader:566:18)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object.<anonymous> (/Users/juri/nrwl/content/pnpm-demos/pnpm-mono/apps/my-remix-app/app/routes/index.tsx:1:24)
at Module._compile (node:internal/modules/cjs/loader:1105:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
```
To build that, run
```shell
pnpm --filter shared-ui build
```
Why? This is due to the symlinks PNPM creates in order to be able to reference and resolve local dependencies. By adding `shared-ui: "workspace:*"` to Remix's `package.json` you instruct PNPM to add a symlink to Remix's `node_modules` folder.
_PNPM creates a symlink in the local node_modules folder to be able to import local packages_
## Running commands with PNPM
PNPM comes with handy features to run commands across the monorepo workspace. We have already seen how to scope commands on single packages using the `--filter` :
```shell
pnpm --filter my-remix-app dev
```
You can also run a command recursively on all the packages in the workspace using the `-r` flag. Imagine for instance running the build for all projects.
```shell
pnpm run -r buildScope: 2 of 3 workspace projects
packages/shared-ui build$ rm -rf dist && tsc
└─ Done in 603ms
apps/my-remix-app build$ remix build
│ Building Remix app in production mode...
│ The path "shared-ui" is imported in app/routes/index.tsx but shared-ui is not listed in your package.json
│ Built in 156ms
└─ Done in 547ms
```
Similarly you can parallelize the run by using `--parallel`
```shell
pnpm run --parallel -r buildScope: 2 of 3 workspace projects
apps/my-remix-app build$ remix build
packages/shared-ui build$ rm -rf dist && tsc
apps/my-remix-app build: Building Remix app in production mode...
apps/my-remix-app build: The path "shared-ui" is imported in app/routes/index.tsx but shared-ui is not listed in your package.json dependencies. Did you forget to install it?
apps/my-remix-app build: Built in 176ms
apps/my-remix-app build: Done
packages/shared-ui build: Done
```
## Speeding up with Nx
PNPM workspaces come with some basic facilities for running tasks on the monorepo packages, even in parallel. As the monorepo grows, you might want to have a more sophisticated approach that allows to
- run tasks on only the packages that changed
- advanced caching based on file contents to not run anything that has already been computed previously
- remote distributed caching to speed up your CI
This is exactly where Nx can help. It is optimized for monorepo scenarios and comes with an advanced task scheduling mechanism. We still rely on the package installation and package linking mechanism that PNPM workspaces provide us, but use Nx instead to run our tasks in the most efficient way.
## Installing Nx
Since Nx will be used for running operations across the entire monorepo workspace we’re going to install it at the root level `package.json`.
```shell
pnpm add nx -D -w
```
That’s it.
## Running tasks with Nx
Nx uses the following form to run your commands:
```shell
npx nx <target> <project>
```
`target` is the NPM script in this specific case you want to execute.
Let’s try to run the build for our `shared-ui` package using the following command:
NX Successfully ran target build for 2 projects (1s)
```
> _Note I’m prefixing the commands with_ `_npx_` _which runs the Nx executable in the_ `_node_modules_` _folder. In this way I don't have to install_ `_nx_` _globally. If you prefer doing that, feel free to do so._
## Configure Caching
One of the main benefits of adding Nx to our PNPM workspace is **speed via caching**. [Computation caching](/concepts/how-caching-works) is a feature where different inputs (source files, env variables, command flags, etc.) are collected and a hash computed & stored in a local folder. Next time you run the command again, Nx looks for a matching hash, and if it finds one it just restores it. This includes restoring the terminal output as well as build artifacts (e.g. JS files in `dist` folders).
Not all operations are cacheable, only side-effect free ones are. For example, if you run an operation with the same inputs, it reliably always has to produce the same output. If as part of that operation you call some API for instance, it wouldn’t be cacheable because the result of that API might vary given the same input parameters.
In order to enable caching, let’s configure our cacheable operations. To do that we create an `nx.json` at the root of our workspace with the following content
```json {% fileName="nx.json" %}
{
"tasksRunnerOptions": {
"default": {
"runner": "nx/tasks-runners/default",
"options": {
"cacheableOperations": ["build", "test"]
}
}
}
}
```
Note the `cacheableOperations` array where we specify `build` and `test` . You can add more such as linting.
Having enabled this, if we now run our Remix app build the first time it is executed just as normal and we’ll see it takes roughly 1s.
remix buildBuilding Remix app in production mode...
The path "shared-ui" is imported in app/routes/index.tsx but shared-ui is not listed in your package.json dependencies. Did you forget to install it?
Built in 163ms
NX Successfully ran target build for project my-remix-app (9ms)
Nx read the output from the cache instead of running the command for 1 out of 1 tasks.
```
You can also see that from the terminal output mentioning “existing outputs match the cache, left as is” as well as at the end “Nx read the output from the cache instead of running the command for 1 out of 1 tasks.”
Having caching in place can drastically improve command execution times. It also gets even more useful if the cache is remotely distributed so that it can be shared with CI as well as other developer machines. In the case of Nx this can be done by enabling [Nx Cloud](/ci/features/remote-cache), which comes with 500 hours saved/month for free (no credit card required) and unlimited hours for open source projects.
## Fine-tuning the caching
By default the caching mechanism takes [all project-level files as an input](/concepts/how-caching-works). We might want to distinguish though which files are being considered based on the target that we execute. Example: you might not want to invalidate the cache for the `build` task if only spec files for unit testing got changed.
To illustrate this on our example, run `npx nx build my-remix-app` twice, such that the caching gets activated. Next, change the `README.md` of the Remix project (`apps/my-remix-app/README.md`). If you re-run the Remix app build the cache will be invalidated due to the change of the README file. This might definitely not be a desirable operation.
We can fine-tune the caching by adding a `targetDefaults` node in the `nx.json` and define that the default `input` for the `build` target should exclude `*.md` files.
```json
{
"tasksRunnerOptions": {
"default": {
"runner": "nx/tasks-runners/default",
"options": {
"cacheableOperations": ["build", "test"]
}
}
},
"targetDefaults": {
"build": {
"inputs": ["!{projectRoot}/**/*.md"]
}
}
}
```
With this change, MD files would not be considered as part of the cache input whenever you run the `build` task.
> _Note that all path globs are_ **_relative to the root of the workspace_**_. This avoids confusion as the inputs could also be defined at the project level in the_ `_package.json_` _(_[_more here_](/reference/project-configuration)_). You can use the interpolation variables_ `_{projectRoot}_` _and_ `_{workspaceRoot}_` _do distinguish whether the path should be targeting the project specific files or workspace level files._
## Reusing Cache Input Globs
You can also go a step further as you might re-use this glob for excluding markdown files also for a hypothetical `test` target. You can do so by extracting the glob into a `namedInputs` property:
```json
{
"tasksRunnerOptions": {
...
},
"namedInputs": {
"noMarkdown": ["!{projectRoot}/**/*.md"]
},
"targetDefaults": {
"build": {
"inputs": ["noMarkdown", "^noMarkdown"]
},
"test": {
"inputs": ["noMarkdown", "^noMarkdown"]
}
}
}
```
By adding `^` in front of the `namedInput` we indicate that this should also apply for changes in any dependencies of the project.
We have seen previously that when running our Remix dev server, but not having compiled the dependent `shared-ui` package first, we got an error when running our Remix app.
```
Error: Cannot find module '/Users/juri/nrwl/content/pnpm-demos/pnpm-mono/apps/my-remix-app/node_modules/shared-ui/dist/index.js'. Please verify that the package.json has a valid "main" entry
at tryPackage (node:internal/modules/cjs/loader:353:19)
at Function.Module._findPath (node:internal/modules/cjs/loader:566:18)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object.<anonymous> (/Users/juri/nrwl/content/pnpm-demos/pnpm-mono/apps/my-remix-app/app/routes/index.tsx:1:24)
at Module._compile (node:internal/modules/cjs/loader:1105:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
```
To fix it, we had to manually build `shared-ui` first. Normally you want to avoid this, which is exactly why Nx comes with a `targetDefaults` definition (often also denoted as the "build pipeline").
We can define such task dependencies in `nx.json` at the root of the workspace in the `targetDefaults` property.
As the first dependency we want to define that whenever we run the `build` target on a project, all the `build` targets of its dependent projects should be executed first. We can express that by adding an additional `dependsOn` property to the `build` task definition:
```json
{
"tasksRunnerOptions": {
...
},
...
"targetDefaults": {
"build": {
...
"dependsOn": ["^build"]
}
},
}
```
Similar as we have seen in the definition of the `inputs`, the `^` here denotes that the target should be run on all dependent projects. If you remove the `^`, then the target would be invoked on the same project. That can be useful if you have a `prebuild` step that always needs to be invoked.
Next, we also want to define a targetDefault for our Remix `dev` command, such that first the `build` on all dependent packages (e.g our `shared-ui`) is run.
```json
{
"tasksRunnerOptions": {
...
},
...
"targetDefaults": {
"build": {
...
"dependsOn": ["^build"]
},
"dev": {
"dependsOn": ["^build"]
}
}
}
```
Here’s the entire `nx.json` file again as a reference point:
```json
{
"tasksRunnerOptions": {
"default": {
"runner": "nx/tasks-runners/default",
"options": {
"cacheableOperations": ["build", "test"]
}
}
},
"namedInputs": {
"noMarkdown": ["!{projectRoot}/**/*.md"]
},
"targetDefaults": {
"build": {
"inputs": ["noMarkdown", "^noMarkdown"],
"dependsOn": ["^build"]
},
"dev": {
"dependsOn": ["^build"]
}
}
}
```
If we now run `npx nx build my-remix-app` we can see that Nx first runs tasks on dependent projects, and only then runs the command we invoked.
_Nx highlights dependent projects being built, but it keeps the main attention to the current task at hand without distracting_
## Running just what changed
In addition to providing caching, Nx also allows to just run what changed in a given branch with respect to a base branch by using the so-called [“affected command”](/ci/features/affected).
```shell
npx nx affected:<target>
```
You can use any target you have defined in your workspace. For example
- `npx nx affected:build`
- `npx nx affected:test`
- `npx nx affected:lint`
- `npx nx affected:publish`
**How does this work?** Nx builds a project graph based on the structure and dependencies among packages in your monorepo workspace. Let’s assume the following hypothetical graph:
Whenever we run the affected commands on a branch, Nx compares all the commits and relative changes with the base branch. By default that is `main`, but you can fine-tune that in the `nx.json` file:
```json
{
"affected": {
"defaultBase": "main"
}
}
```
If `lib2` gets changed in our feature branch, running tests against the workspace using `affected:test` would only run tests for `lib2` and `appB`.
Be aware however, if we run `affected:build` and we defined a dependency in our `nx.json` indicating that dependent projects need to be built first as well (see section "Defining task dependencies"), then `affected:build` would build
- `lib3`
- `lib2`
- `appB`
It would not build `lib1` or `appA` though.
## Additional features
Besides speed and task scheduling improvements, we also get some additional features by adding Nx to our PNPM workspace. Let’s explore some:
## Want to automate the creation of packages?
Once you have a good setup for a package, you obviously want to replicate that as you create new ones. The usual approach: copy & paste and then remove all stuff that's not needed.
That's tedious and potentially error prone. Nx has a concept of "generators", basically code scaffolding which allows you to generate new packages in the monorepo rather than copy & pasting old ones.
Running tasks in parallel with PNPM results in quite a messy terminal output. The logs are hard to parse as the messages from the different commands being executed in parallel are interleaved.
```shell
pnpm run --parallel -r buildScope: 2 of 3 workspace projects
apps/my-remix-app build$ remix build
packages/shared-ui build$ rm -rf dist && tsc
apps/my-remix-app build: Building Remix app in production mode...
apps/my-remix-app build: The path "shared-ui" is imported in app/routes/index.tsx but shared-ui is not listed in your package.json dependencies. Did you forget to install it?
apps/my-remix-app build: Built in 176ms
apps/my-remix-app build: Done
packages/shared-ui build: Done
```
When using Nx to run tasks you get a dynamic terminal that shows just what is necessary and most relevant to the current command that has been executed. Running the same parallel build task results in the following output when using Nx:
_Terminal output of Nx dynamically showing the parallel tasks being computed as well as the ones that already succeeded_
## Project Graph Visualization
```shell
npx nx graph
```
This launches an interactive visualization of the workspace’s project graph with some advanced capabilities of filtering, debugging your workspace structure and more.
Among the core features of Nx is the ability to save computation time by applying different strategies. Scroll to the end of the article for some more info, but first, **how much time is actually being saved?**
## How much time is being saved?
This is how much got saved so far (data from August 16th, 2022). Pretty crazy!
- **Last 7 days:** 5 years 4 months 2 days 2 hours 32 minutes 46 seconds
- **Last 30 days:** 23 years 8 months 25 days 8 hours 57 minutes 19 seconds
- **Since the beginning of Nx Cloud:** 200 years 10 months 13 days 19 hours 37 minutes 57 seconds
## The Effect on the Environment
Calculating the CO2 emissions can be tricky. It really depends on what machines are being used to run the computation saved by Nx Cloud. We gave it a try by using [https://green-algorithms.org/](https://green-algorithms.org/).
[See all the details](https://green-algorithms.org//?runTime_hour=46752&runTime_min=0&appVersion=v2.2&locationContinent=North+America&locationCountry=United+States+of+America&locationRegion=US&coreType=CPU&numberCPUs=2&CPUmodel=Xeon+E5-2683+v4&memory=4&platformType=cloudComputing&provider=aws)
[See all the details](https://green-algorithms.org//?runTime_hour=207462&runTime_min=0&appVersion=v2.2&locationContinent=North+America&locationCountry=United+States+of+America&locationRegion=US&coreType=CPU&numberCPUs=2&CPUmodel=Xeon+E5-2683+v4&memory=4&platformType=cloudComputing&provider=aws)
[See all the details](https://green-algorithms.org//?runTime_hour=1760505&runTime_min=0&appVersion=v2.2&locationContinent=North+America&locationCountry=United+States+of+America&locationRegion=US&coreType=CPU&numberCPUs=2&CPUmodel=Xeon+E5-2683+v4&memory=4&platformType=cloudComputing&provider=aws)
## Help me out! A Primer on how Nx saves computation
Nx has various strategies to help you reduce computation time, locally and on CI. Here’s a very short overview of the strategies Nx applies with some links for further reading.
### Affected Commands
Example: Run tests only for changed projects in a given PR.
```
nx affected:test
```
[Nx affected commands](/ci/features/affected) allow you to only run commands against projects that changed with respect to a baseline. Usually, this is applied in PRs processed by your CI system. Nx analyzes the Git commits and identifies all projects that got changed with respect to a base branch (usually `main` or `master`). It then makes sure to run the given command only for those projects as well as all projects depending on them since they might be affected by the change too.
This helps save computation by reducing the set of projects that need to be processed.
### Local Computation Caching
Nx comes with a so-called [computation caching](/concepts/how-caching-works) feature. For every cacheable operation, Nx takes a set of input parameters, computes a hash and stores the result.
Whenever a hash matches, the computation is not run, but rather the previous result is restored. This can dramatically speed up things and avoid running any computation that has already been run previously.
### Distributed Remote Caching (with Nx Cloud)
By default, the Nx computation cache is stored locally (usually within the `node_modules/.cache/nx` folder). The real benefits come from sharing it with others, that being your co-workers or CI agents.
[Nx Cloud](/nx-cloud) allows to distribute the Nx computation cache across machines.
Connecting an existing Nx workspace to Nx Cloud can be done with
```
nx connect-to-nx-cloud
```
[More on the docs](/ci/features/remote-cache). Nx Cloud comes with [500 hours of computation time saved per month](/pricing) which is plenty for most workspaces. If you go over, you can buy more, or in the worst case, caching simply stops until the next month.
## Bonus! Lerna can do this too!!
[Nrwl](/company), the company behind Nx, recently [took over stewardship of Lerna](/blog/lerna-is-dead-long-live-lerna). Meanwhile, Lerna 5.4 just got released which features a nice integration with Nx, allowing existing Lerna users to keep using the very same commands, but still benefit from the improved task scheduling and caching abilities Nx comes with.
How to enable it? [Read more on the Lerna docs](https://lerna.js.org/docs/features/cache-tasks)
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
· [VSCode extension for Lerna workspaces](#vscode-extension-for-lerna-workspaces)
· [Lerna Repair](#lerna-repair)
· [Lerna and Prettier](#lerna-and-prettier)
· [Migrating to Lerna v6](#migrating-to-lerna-v6)
· [Lerna is using Nx now. Can I keep using my Lerna commands?](#lerna-is-using-nx-now-can-i-keep-using-my-lerna-commands)
· [Are you maintaining an OSS repository using Lerna?](#are-you-maintaining-an-oss-repository-using-lerna)
## Lerna continues to evolve
If you already know this, feel free to skip ahead. But surprisingly many still haven’t heard that **Lerna is back**, far from obsolete or deprecated and is getting brand new features. We from [Nrwl](/company) are the creators of Nx and given our long history in the monorepo space, we offered to [take over stewardship of Lerna](/blog/lerna-is-dead-long-live-lerna) when it was declared “dead” in April 2022.
Since we took over, in May 2022, it has been an absolute rollercoaster. We launched [a brand new website](https://lerna.js.org/), updated the content of the docs, and [made Lerna 10x faster](/blog/lerna-used-to-walk-now-it-can-fly). And now, **Lerna v6 is out!**
## Fast Lerna with caching by default
Up until Lerna v4, either the `p-map` or `p-queue` npm packages have been used to delegate the task scheduling. With [v5.1](/blog/lerna-used-to-walk-now-it-can-fly) we introduced `nx` as an additional mechanism to schedule tasks. The advantage? Nx has caching built-in, which **also gives Lerna caching support**, making it lightning fast. A recent benchmark test resulted in **Lerna being 2.5x faster than Lage** and around **4x faster than Turbo** (as of Oct 2022; [test it out by yourself](https://github.com/vsavkin/large-monorepo)).
So far you had to enable “Nx support” by setting the `useNx` flag in `lerna.json`:
```
// lerna.json
{
...
"useNx": true
}
```
We’ve been testing this opt-in for the last couple of months and got tons of amazing feedback from companies and open source projects. As a result, **with v6 all Lerna workspaces have the useNx set to**`**true**`**by default** even if you don't have it in your Lerna config file. If you don't want to use it, you can disable it by setting the flag to false.
To experience fast caching, ensure you have a `nx.json` file at the root of your Lerna workspace where you define the cacheable operations. Check out [the docs for more details](https://lerna.js.org/docs/features/cache-tasks). Here's an example configuration file:
```json
{
"tasksRunnerOptions":{
"default":{
"runner":"nx/tasks-runners/default",
"options":{
"cacheableOperations":["build","test"]
}
}
}
}
```
Note that you can also run..
```shell
npx lerna add-caching
```
..to automatically generate a `nx.json` configuration file based on your existing Lerna workspace.
## Remote caching with Lerna
By using Nx as the task scheduler for Lerna it inherits all the capabilities Nx comes with. That not only just includes local caching, but also the possibility of having **remote caching** and **distributed task execution**.
Remote caching allows you to distribute your local cache with your co-workers and your CI system. This is done via [Nx Cloud](/nx-cloud). But distributed caching is just one aspect. Nx Cloud also comes with a “run view” that visualizes your CI run with easy grouping and filtering capabilities, but in particular, it comes with the ability to distribute your tasks dynamically across multiple machines. All by optimizing for the best parallelization and machine utilization.
..in your Lerna workspace, which will guide you through a couple of questions and set you up with an [Nx Cloud](/nx-cloud).
Read more [on the docs](https://lerna.js.org/docs/features/cache-tasks#distributed-computation-caching).
## Defining a task pipeline
When running tasks in a monorepo environment, you want to maximize the parallelization, but **still account for potential dependencies among tasks**. For example, assume you have a Remix application that depends on some `shared-ui` library. You want to ensure that `shared-ui` is built before either building or serving the Remix application.
With Lerna v6 you can do so in the `nx.json` file by defining the `targetDefaults`:
```
// nx.json
{
...
"targetDefaults": {
"build": {
"dependsOn": ["^build"]
},
"dev": {
"dependsOn": ["^build"]
}
}
}
```
In this case, whenever you run either `build` or `dev`, Lerna would first run the `build` task on all the dependent packages.
[Read more on our docs](https://lerna.js.org/docs/concepts/task-pipeline-configuration).
## Lerna add-caching command
If you don’t have caching or your task pipeline set up just yet, no worries. We wanted to make it as easy as possible by providing a dedicated command:
```shell
npx lerna add-caching
```
This will scan your workspace, find all your `package.json` scripts and then guide you through the **configuration of both, your cacheable operations as well as your task pipeline**.
You are obviously always free to create the `nx.json`by hand.
## PNPM support for Lerna
In the past, Lerna didn’t properly support PNPM. We fixed this in v6. Now whenever you use Lerna in combination with PNPM, we make sure to detect packages based on the `pnpm-workspace.yaml`, to enforce `useWorkspaces: true` , we update the `pnpm-lock.yaml`
accordingly when using `lerna version` and we also added proper support for the `workspace:` protocol that PNPM uses.
You can now finally use one of the fastest package managers in combination with a new fast Lerna experience. Also, make sure to check [out our docs for all the details](https://lerna.js.org/docs/recipes/using-pnpm-with-lerna).
## Dynamic terminal output
When running tasks in parallel across a large number of projects, it can become quite difficult to follow along in the terminal with what got built and where tasks failed. That’s why the new Lerna version comes with a dynamic terminal output that only shows what is most relevant at a given moment.
Note that you would still see all of the output as usual on CI.
## VSCode extension for Lerna workspaces
Lerna now has a [dedicated VSCode extension](https://lerna.js.org/docs/features/editor-integrations) to help you navigate your monorepo. This allows you to run commands directly from the context menu (by right-clicking on a project):
Or visualize a project and its relationships with other projects in the workspace.
You will also get intelligent autocompletion in configuration files. Here’s an example of Nx console providing context-based information when editing the `nx.json` task dependencies.
Lerna v6 comes with a built-in `lerna repair` command. Running this command will automatically fix your Lerna configuration. For instance, in Lerna v6, there's no need to have `useNx: true` in your `lerna.json` since that will be the new default going forward. Running `lerna repair` fixes this.
This allows you always to have the most up-to-date Lerna setup and it will become even more powerful as we keep adding migrations in the future.
## Lerna and Prettier
Prettier is part of the standard toolchain of every developer nowadays. In Lerna v6 we added a feature to detect whether Prettier is set up in the workspace. If so, we automatically apply it to all files that get updated by running the `lerna version` command. No more follow-up commits just to fix the file formatting!
## Migrating to Lerna v6
Migrating from Lerna v5 to v6 is non-breaking. We increased the major because we changed some defaults and wanted to be cautious about that and communicate it properly.
Similarly, if you’re still on v4 and want to migrate to v6 it should be pretty straightforward and not be breaking in most cases.
Just update the Lerna package version to the latest and then run..
```shell
npx lerna add-caching
```
..to enable and configure caching for your workspace.
## Lerna is using Nx now. Can I keep using my Lerna commands?
Absolutely! One of the key advantages of the new integration of Lerna with Nx is that you can keep using your existing Lerna commands without migrating them to a new syntax. They will now just be a lot faster.
You can read more about that [on our docs](https://lerna.js.org/docs/lerna-and-nx).
## Are you maintaining an OSS repository using Lerna?
If you are an OSS maintainer and you use a Lerna workspace, let us know!
Ping the Lerna team [on Twitter](https://twitter.com/lernajs) or ping [me directly](https://twitter.com/juristr). We’d love to have a look and help with the migration, look at the repository and make sure it is configured in the best optimal way in terms of monorepo setup and features like caching.
That said, as an open-source maintainer you also get unlimited free computation caching with Nx Cloud. So we’d love to set you up with that.
I’m excited to let the Nx Community know about our first round of outside financing, led by [Nexus Venture Partners](https://nexusvp.com/) and [A16z](https://a16z.com/), with several amazing angel investors. We’ve raised a seed round of $8.6M to scale the growth of open source Nx, [Nx Cloud](/nx-cloud), and [Nx Enterprise](/enterprise). With this new capital, we’re able to allocate significantly more resources to rapidly evolving our open source and commercial products to help development teams **ship faster at any scale**.
When Victor Savkin and I left Google to start this company in December 2016, we saw a big gap between how enterprises were building software and how companies like Google were building software. So in 2017, we released the first version of our developer toolkit, Nx, which focused on enabling monorepo-style development for large software teams. Nx has continued to evolve and grow in adoption since then, at more than 5x year-over-year in npm downloads to now 12M+ monthly downloads! We’re proud that the world’s top brands depend on Nx to help their development teams iterate faster on critical products.
[Nx Cloud](/nx-cloud) has also seen a significant uptake in adoption, thanks in large part due to the addition of [Distributed Task Execution](/ci/concepts/parallelization-distribution) last year. With the combination of Distributed Task Execution and Distributed Caching, Nx Cloud is having a massive impact on the time it takes to validate and merge pull requests, drastically reducing product time-to-market. There are now more than 100k connected Nx Workspaces on nx.app. With Nx Cloud, Nx and Lerna workspaces can drastically reduce build times by letting Nx Cloud manage task cache distribution, and optimal distribution of tasks across many machines using Nx’s deep understanding of project relationships and task timings. We’ve determined that Nx and Nx Cloud have [saved over 250 years of compute time](/blog/helping-the-environment-by-saving-two-centuries-of-compute-time) since we started measuring.
Our most significant commercial innovation in the past year has been [Nx Enterprise](/enterprise), which allows companies to deploy Nx Cloud on their own infrastructure. Some of the world’s leading brands are relying on Nx Enterprise to help their developers get products and features to market significantly faster. One repository powered by Nx Enterprise is saving over 40,000 hours per month of compute time thanks to Distributed Caching and Distributed Task Execution, drastically reducing the time it takes to validate and merge pull requests.
_Monorepo.tools, by Nx in collaboration with other monorepo projects_
With Nx and Lerna under our stewardship, we now maintain [more than 75% of leading JavaScript monorepo tooling](https://npmtrends.com/@bazel/typescript-vs-@microsoft/rush-vs-@nrwl/tao-vs-lerna-vs-turbo). We’re sharing this space with some other great teams, who are all pushing the state of the art forward. We developed the site [monorepo.tools](https://monorepo.tools/) in collaboration with these teams to spread the monorepo love and help developers decide which tool is right for them.
## Why Outside Funding?
Victor Savkin and I originally decided not to raise funding when starting the company, to give ourselves space to experiment with different business models and find product-market fit. We’ve revisited the idea of funding from time to time, but our consulting business has provided more than enough income to sustain the company’s growth. It wasn’t until Nx Cloud and Nx Enterprise started growing at a much more rapid pace that we decided we could provide a lot more value, more quickly to our community and customers by taking on some partners and capital to help us with our next phase of growth.
We couldn’t be more excited to partner with our co-lead investors, [Nexus Venture Partners](https://nexusvp.com/) and [Andreesen Horowitz (a16z)](https://a16z.com/). Both firms have deep expertise in developer tooling and strongly believe in our vision of helping development teams scale. We’re excited to have them bring their own unique talents, experience, and resources to help us execute on that vision. Abhishek Sharma from Nexus has tremendous commercial open source experience, and has been excited about Nx for years. A16z is a powerhouse with an extremely talented enterprise infrastructure team led by Martin Casado and Jennifer Li, alongside amazing partners including, Satish Talluri, and Yoko Li. We’re also excited to be joined by many angels, including Tom Preston-Werner, Matt Biilmann, and several other notable CEOs, founders and technologists.
_Most of the Nx team at Nx Conf in Tempe, AZ, October 2022_
We are only scratching the surface of how we can help teams scale their development, and we’re drastically increasing our R&D time to move even faster on new innovations in build performance and team scaling. Fortunately, we already have a world-class team of top engineers who’ve helped us build Nx and Nx Cloud, while also helping our customers succeed with Nx. With this new capital, our engineers are able spend significantly more R&D time building industry-changing products and features, while continuing to work with and learn from our Nx Cloud and Nx Enterprise customers.
We’ll be sharing more exciting announcements soon, so make sure to follow our journey on [@NxDevTools](https://twitter.com/nxdevtools)!
In case you missed it, we raised $8.6 million a couple of weeks ago. Here’s the official blog post from our CEO Jeff: [/blog/from-bootstrapped-to-venture-backed](/blog/from-bootstrapped-to-venture-backed)
It is exciting for us as we can now have more employees focused on pushing Nx and Nx Cloud forward, which will significantly boost development speed!
For most of our workforce, working on Nx and Nx Cloud was only part of their “20% project”. Yet we released terrific features over the last years and have seen tremendous growth with Nx (which brings us to the next section)
## 3 million downloads per week
2022 has been a particularly crazy but successful year for us. And Nx’s growth confirms that we’re on the right track:
- January: Nx crosses 1 million downloads per week
- June: Nx crosses 2 million downloads per week
- November: Nx crosses 3 million downloads per week
One of our most loved features also just got more powerful: the Nx graph!
Nx already visualizes your project graph, mapping the dependencies different projects have on one another through imports and exports in your code. But your tasks also have a graph. Your task can either depend on another target on the same project, let’s say you have a `prebuild`
and a `build` target. Whenever you run `build`, you want to run `prebuild` first. Similarly, if your project depends on other projects, you might want to make sure to build them first as well. This is called a [task pipeline](/concepts/task-pipeline-configuration) and can be defined in `nx.json` as follows:
```json5 {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
"dependsOn": ["prebuild", "^build"]
}
}
}
```
This example is pretty straightforward, but such pipelines can become much more involved.
Therefore, let me introduce you the **task graph**. You might already be used to seeing the project graph after running the `nx graph` command. But there's now a dropdown in the corner that enables you to switch to the task graph. Select a target from the "Target Name dropdown" to filter the list of projects to only those with that target. Click on a project to show that target's task graph.
You can add another project as well, showing what the task graph looks like for a command that runs tasks for multiple projects like `nx run-many` or `nx affected`. Click on the `Group by project` checkbox to group related tasks by their project, and click on a task to see what executor it uses.
Nx is widely known as [THE developer tool](https://monorepo.tools/) people look at when it comes to implementing monorepos in the frontend space. However, a lot of the unique features that Nx ships (in particular when it comes to implementing [Integrated Monorepos](/deprecated/integrated-vs-package-based)) can be beneficial even outside of the typical monorepo scenario. In particular, Nx plugin features such as code generation, pre-configured build tooling setup, and battle-tested integration with best practices tools (e.g. Cypress, Jest, ESLint, Vite, …).
But one stands out most prominently: the **ability to easily modularize** your codebase.
A lot of our users adopt Nx for precisely this reason. They have a large app and want to break it into smaller pieces while still having the comfort of deploying it as a single one.
In 15.3 we are therefore making **standalone projects** a first-class feature. Suppose you now create a new workspace with `npx create-nx-workspace` alongside the usual monorepo options. In that case, you will now see two more options for scaffolding a standalone React or Angular application (we will add more in the future).
In a standalone project setup, you don’t have the typical `apps` and `libs` structure you might be accustomed to if you have been using Nx in the past. Instead, the app lives directly at the root of your workspace. The structure looks similar to the following:
```text
e2e/
src/
cypress.config.ts
project.json
...
src/
app/
main.tsx
...
public/
index.html
project.json
tsconfig.spec.json
tsconfig.app.json
tsconfig.json
vite.config.ts
nx.json
package.json
```
The critical part here is that you can still have multiple nodes. Even in this example, we have the app itself at the root of the workspace and a nested `e2e` project for that application (using Cypress).
To modularize your application, you can add libraries as you would do in a more traditional integrated Nx monorepo setup, but you can now have those alongside your application. Either create them directly at the root-level or group them in one or more root-level folders. In the example below, I have a `features` as well as `utils` folder, both of which can host multiple libraries.
```text
e2e/
...
src/
app/
main.tsx
...
features/
feature1/
feature2/
utils/
...
index.html
...
nx.json
package.json
```
It is really up to you how you want to structure them.
Think of it as a supercharged development tool, providing powerful generators, features like [module boundary rules](/blog/mastering-the-project-boundaries-in-nx) and obviously the ability to run tests, linting, building on individual libraries. Not to forget about Nx’s powerful caching ability. And if you’re ready for a “real” monorepo because you want to add multiple applications, there will be paths for you to “upgrade” to that structure.
## Integrated Vite and Vitest support is here!
Finally! We talked about it; now it is here! Official Vite and Vitest support for Nx-based integrated monorepos and standalone app projects! That adds the Vite community into the Nx family, and we’ve been chatting with core members there recently, and we love it!
So before we dive into this: if you are using a package-based monorepo with Nx, you could already use Vite or whatever other technology you want. Nx does just the task scheduling there, running your `package.json` scripts efficiently. Whatever those scripts do "internally" is up to you.
But if you power an integrated setup, you’d want more support via a dedicated Nx plugin. And there has already been a [Nx community plugin](/community) created by the folks from [https://nxext.dev/](https://nxext.dev/). Given the high demand for Vite support, we (the Nx core team) started to look into creating and maintaining our own. We reached out to the out [Dominik Piper](https://mobile.twitter.com/dominik_pieper) and [Jordan Hall](https://mobile.twitter.com/JordanHall_dev) from the NxExt team and they were on board from the beginning! We got lots of helpful input, while designing the new Vite plugin. Huge shoutout to them!!
`@nrwl/vite` (just like `@nrwl/webpack`) is a package that can be integrated as part of other packages. Right now, we're prioritizing our React setup. If you generate a new Nx workspace and choose the new "Standalone React app" version, you will get a React application powered by Vite and Vitest.
Similarly, you can add a new Vite-powered React app to an existing Nx workspace using the `vite` bundler option:
This new setup gives you an easy jumpstart as it does all the configuration for you:
- React with Vite
- Tests with Vitest
- Making sure it nicely works with TypeScript (both in src and spec files)
Open the application’s `project.json` to inspect the setup:
```json
{
"name": "viteapp",
...
"projectType": "application",
"targets": {
"build": {
"executor": "@nrwl/vite:build",
...
},
"serve": {
"executor": "@nrwl/vite:dev-server",
"defaultConfiguration": "development",
...
},
"test": {
"executor": "@nrwl/vite:test",
"outputs": ["{projectRoot}/coverage"],
"options": {
"passWithNoTests": true
}
},
...
}
}
```
Furthermore, there’s a `vite.config.ts` at the project root level, which you can further customize to your needs. It is already pre-configured to seamlessly work in a monorepo scenario and has the Vitest setup. Just run `npx nx serve` or `npx nx build` or `npx nx test` to serve, build or test your standalone React app.
If you are currently using the NxExt based Vite plugin, or even a Webpack based Nx React setup, you can easily transition to the new Vite plugin by just running the following generator:
```shell
npx nx g @nrwl/vite:configuration
```
This will adjust the NxExt Vite plugin configuration to match the one provided by our core team. Check out our docs for more info: [/nx-api/vite/generators/configuration](/nx-api/vite/generators/configuration)
You can also find all the details about the new Vite package on our docs: [/nx-api/vite](/nx-api/vite)
## Adopting Nx has never been easier
Many developers don’t necessarily start with a greenfield project, but rather have an existing reality where they want to use Nx. We’ve been improving this process of adopting Nx over this year to the point where it has never been easier than now!
Regardless of whether you have
- an existing package-based monorepo setup using NPM/Yarn or PNPM workspaces
- an existing Lerna workspace (for this you probably want to consult the [Lerna docs](https://lerna.js.org/upgrade) for some awesome feature updates)
- a Create-React-App (CRA) application
- a Angular CLI standalone application
- or really any other form of project
You can just run
```shell
npx nx@latest init
```
Running this command will install the `nx` package, and then analyze your existing project structure and correctly identify whether it is a monorepo workspace or some standalone project, whether it's a CRA app or whether you're coming from the Angular CLI. Based on that, you'll get a couple of questions asked and then your workspace gets configured to run it with Nx.
Check out our docs for all the details on
- [adding Nx to an existing monorepo](/recipes/adopting-nx/adding-to-monorepo)
- [adding Nx to any non-monorepo setup](/recipes/adopting-nx/adding-to-existing-project)
- [migrating your CRA project to Nx](/recipes/adopting-nx/adding-to-existing-project)
- [migrating your Angular CLI app to Nx](/recipes/angular/migration/angular)
Oh..you’re wondering why you would want to add Nx to an existing non-monorepo project? Then keep reading 👇
Adding Nx to a single application? Why would that be useful? Well, most apps have multilple scripts in their `package.json`, which includes building, testing, linting your app and potentially much more. Nx can cache these! Obviously it is just app-level caching (since you didn't modularize it with libraries), but imagine your CI setup running these:
```shell
npx nx build
npx nx test
npx nx lint
npx nx e2e
```
If your change just modified a couple of “spec files”, then there’s no point on running `build` or `e2e` again, but just `test` and potentially `lint`. Nx can restore the results of the other operations from the cache.
To add Nx to an existing standalone project, all you need to run is
```shell
npx nx@latest init
```
This process will ask you a few questions about which operations are cacheable. We optimized it so that you don’t necessarily have to use `nx` to run your build, linting or serving your app. You can keep using `npm run build` or `npm start`. This is because Nx wraps your scripts in the `package.json`. Notice how `build` and `lint` are wrapped because they are cacheable operations.
```json
{
...
"scripts": {
"build": "nx exec -- vite build",
"lint": "nx exec -- eslint \"src/**/*.ts*\"",
...
"dev": "vite",
"start": "vite --open",
},
"devDependencies": {
...
"nx": "15.3.0"
}
}
```
Read more on our docs: [/recipes/adopting-nx/adding-to-existing-project](/recipes/adopting-nx/adding-to-existing-project)
Most of the tasks in a workspace run against a specific project, like building or testing it. That’s why they live in the corresponding `package.json` or `project.json`. But sometimes you have workspace-wide commands which you want to run through the "Nx pipeline" to get the benefits of caching.
Assume you already have a script called `docs` in your root-level `package.json`.
```json5
// package.json
{
name: 'myorg',
scripts: {
docs: 'node ./generateDocsSite.js',
},
}
```
To allow it to be cached and to be run with Nx, all you need to do is add the follow `nx` property to your `package.json`:
```json5
// package.json
{
"name": "myorg",
"scripts": {
"docs": "node ./generateDocsSite.js"
}
"nx": {}
}
```
You can then run it with
```shell
npx nx docs
```
As the next steps you might obviously want to add `docs` to the [cacheable operations](/ci/reference/config) and [fine-tune it's cache inputs](/recipes/running-tasks/configure-inputs).
Read more about it on our docs: [/recipes/running-tasks/root-level-scripts](/recipes/running-tasks/root-level-scripts)
Nx can automatically detect your scripts in `package.json`. But if you have an integrated setup using Nx plugins, they usually come with a `project.json` . There you have targets like `build`, `test`, `lint` etc.. and they mostly look as follows:
```json5 {% fileName="project.json" %}
{
"name": "demoapp",
...
"targets": {
"build": {
"executor": "@nrwl/vite:build",
"outputs": ["{options.outputPath}"],
"defaultConfiguration": "production",
"options": {
"outputPath": "dist/demoapp"
},
...
},
"serve": {
"executor": "@nrwl/vite:dev-server",
...
},
...
}
}
```
The task itself is handled by an [Nx executor](/extending-nx/recipes/local-executors) that comes with the plugin, in this case `@nrwl/vite:build` to build a Vite project.
To add a custom command, like invoking a node script, Nx has the so-called [“run-commands”](/recipes/running-tasks/run-commands-executor). So far you had to wrap those commands as follows:
```json5 {% fileName="project.json" %}
{
"name": "demoapp",
...
"targets": {
"prebuild": {
"executor": "nx:run-commands",
"options": {
"command": "echo 'hi'"
}
},
"build": {
...
},
...
}
}
```
For simple commands this was a huge overhead, so we simplified it to just this:
```json5 {% fileName="project.json" %}
{
"name": "demoapp",
...
"targets": {
"prebuild": {
"command": "echo 'hi'"
},
"build": {
...
},
...
}
}
```
Simple, isn’t it! Obviously the expanded form is still there and also useful for when you need more options, run multiple commands or features such as argument forwarding.
You can read all about it on our docs: [/recipes/running-tasks/run-commands-executor](/recipes/running-tasks/run-commands-executor)
## Coming up
Wow, what a launch! But more features are on the way in the coming weeks that didn’t make it for this release. Super excited about these, which most prominently include
- Workspace watching
- Lock-file pruning
- Nx Cloud integration into Nx Console
Follow us [on our socials](https://twitter.com/nxdevtools) and on [Youtube](https://www.youtube.com/@nxdevtools) to make sure to see it when we announce them!
## How to Update Nx
Updating Nx is done with the following command and will update your Nx workspace dependencies and code to the latest version:
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
npx nx migrate --run-migrations
```
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
Nx just had a massive release 2 weeks ago with Nx 15.3 — if you missed it be sure to check out [our article](/blog/nx-15-3-standalone-projects-vite-task-graph-and-more) featuring some huge improvements including Vite support, Standalone Angular and React presets, and a Task Graph visualization!
But over the past couple of weeks, we’ve been able to land quite a few awesome features, so we’re going back at it again releasing Nx 15.4 today, including:
- [Vite 4.0 Support](#vite-40-support)
- [Nx Watch](#nx-watch)
- [Webpack-less Cypress Support for Our React Standalone preset](#webpackless-cypress-support-for-our-react-standalone-preset)
- [Server-Side Rendering support for Module Federation for both Angular and React Applications](#serverside-rendering-support-for-module-federation-for-both-angular-and-react-applications)
- [Running Multiple Targets in Parallel for Multiple Projects](#running-multiple-targets-in-parallel-for-multiple-projects)
- [Interactive Prompts for Custom Preset](#interactive-prompts-for-custom-preset)
As the [Vite launch article](https://vitejs.dev/blog/announcing-vite4.html) mentions, we are investing in the Vite ecosystem, and now officially support a first-party Vite plugin. Nx 15.4 continues this investment with timely support for Vite 4, and we’re excited to be a part of the Vite ecosystem and a part of bringing more value to our devs through Vite support!
Projects already using our [@nrwl/vite plugin](/nx-api/vite) will be automatically upgraded to Vite 4 when they upgrade to the latest Nx version with the `nx migrate` command, and we've also simplified the configuration required to support Vite.
We’ve also spent some effort into making the conversion of existing projects to use Vite simpler, including:
- the ability to choose which targets you want to convert
- enhanced `vite.config.ts` file configuration
- better DX with detailed messages during conversion
- [better documentation around converting using our generator](/nx-api/vite/generators/configuration)
- [adding a guide to our docs for converting manually](/recipes/vite/configure-vite)
You can check out more details about our Vite plugin including how to add Vite and Vitest to your existing Nx workspace by visiting our docs at [nx.dev/nx-api/vite](/nx-api/vite)
## Nx Watch
{% youtube src="https://youtu.be/0eVplUl1zBE" /%}
Nx 15.4 includes a new feature to support file-watching with Nx! Here’s how it works:
Syntax:
```shell
nx watch [projects modifier option] -- [command]
```
Example:
```shell
nx watch --all -- nx build $NX_PROJECT_NAME
```
For the projects modifier option:
- you can use `--all` for all projects in the workspace
- or you can filter down to specific projects with the `--projects=[comma separated list of project names]` option that can be used in conjunction with a `--includeDependentProjects` option as well
The `nx watch` command will support the variables `$NX_PROJECT_NAME` and `$NX_CHANGED_FILES`. This feature opens the door for nice developer workflows where we can provide an out-of-the-box mechanism for Nx to run relevant tasks on save, and we’re excited to see our users get their hands on this feature.
Personally, I’m excited to use the following command:
We added a React Standalone preset in 15.3 to support single react application workspaces with Nx, and in 15.4, we’ve added back in Cypress for this preset.
With Nx 15.4, a standalone React application will be created with an e2e directory preconfigured and optimized for running Cypress with the command `npx nx e2e e2e` as soon as your initial workspace is generated.
## Server-Side Rendering support for Module Federation for both Angular and React Applications
Now you can get the benefits of both Server Side Rendering and Module Federation for your applications, which will improve page loads, Search Engine Optimization, and build times!
Our existing `host` and `remote` Module Federation generators have an added `--ssr` flag that will enable Server-Side Rendering by generating the correct server files.
We’ve also added a new executor to allow you to serve the host server locally, along with all remote servers from a single command.
Learn more about this new feature [in our docs](/recipes/react/module-federation-with-ssr)!
## Running Multiple Targets in Parallel for Multiple Projects
Nx 15.4 includes updates to the `nx run-many` command, allowing you to add multiple whitespace-separated targets, as well as globs in the `projects` option, for example:
```shell
npx nx run-many --target test build lint
```
^ this would run all `test`, `build`, and `lint` targets in your workspace, and you can now filter this down to select projects via globbing:
```shell
npx nx run-many --target test build lint --projects "domain-products-*"
```
^ this will now run all `test`, `build`, and `lint` targets for all projects in your workspace that start with "domain-products-".
## Interactive Prompts for Custom Preset
Last but not least, we’ve added support for interactive prompts for Custom Presets!
In Nx, [presets](/extending-nx/recipes/create-preset#create-a-custom-plugin-preset) are special code generation scripts that can be used to create a brand new Nx Workspace, using our `create-nx-workspace` command.
For instance, I happen to know [Shai Reznik](https://twitter.com/shai_reznik) at [builder.io](https://builder.io/) has been working on a qwik plugin for Nx, and since the [qwik-nx](https://www.npmjs.com/package/qwik-nx) plugin that he’s published includes an [Nx generator called “preset”](https://github.com/qwikifiers/qwik-nx/blob/main/packages/qwik-nx/generators.json#L33), I can run the command:
```shell
npx nx create-nx-workspace –preset=qwik-nx
```
As we can see, the preset option matches the name of the published npm package.
This custom preset feature has been around for a while, but as of 15.4 we’ve added support for these custom presets to interactively prompt the user following the initial installation step!
This should open up some powerful functionality for plugin and package authors to parameterize their code generation scripts with Nx, and we’re excited to see folks like [Shai](https://twitter.com/shai_reznik), [builder.io](https://builder.io/), and [qwik](https://qwik.builder.io/) leverage this new feature!
## That’s it for this release.
Follow us on our socials and on [Youtube](https://www.youtube.com/channel/UCF8luR7ORJTCwSNA9yZksCw) to make sure to see more news and releases as we announce them!
You can find [full changelogs for the release](https://github.com/nrwl/nx/releases/tag/15.4.0) on github.
## How to Update Nx
Updating Nx is done with the following command and will update your Nx workspace dependencies and code to the latest version:
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
npx nx migrate --run-migrations
```
## Learn more
- [🧠 Nx Docs](/getting-started/intro)
- [👩💻 Nx GitHub](https://github.com/nrwl/nx)
- [💬 Nx Official Discord Server](https://go.nx.dev/community)
[Module Federation](https://webpack.js.org/plugins/module-federation-plugin/) is a technology provided by [Webpack](https://webpack.js.org/) that enables modules to be federated across different origins at runtime. This means that Webpack will simply ignore these modules at build time, expecting them to be available to be fetched across the network at runtime.
This technology has enabled a much cleaner approach to Micro Frontend Architecture but also is employable as a strategy to implement incremental builds for large applications, reducing overall build times. This can lead to faster feedback cycles and less money spent on CI workflows.
Nx offers great out-of-the-box support and developer experience for Module Federation for Angular and React. You can learn more about it from the resources below:
📄 [Module Federation Recipes on Nx](/recipes/module-federation)
📺 [Speed up your Angular serve and build times with Module Federation and Nx](https://www.youtube.com/watch?v=JkcaGzhRjkc)
However, until now, it has only supported Client-Side Rendering (CSR). Essentially it worked only for Single Page Applications (SPAs). While this is still valuable, it is becoming ever more apparent that Server-Side Rendering (SSR) is becoming the de-facto standard for building web applications, due to the multitude of benefits it provides.
> [What is server-side rendering: definition, benefits and risks](https://solutionshub.epam.com/blog/post/what-is-server-side-rendering)
Since [version 15.4](/blog/nx-15-4-vite-4-support-a-new-nx-watch-command-and-more), Nx now offers Module Federation with support for SSR! 🎉
Now we can get both, the benefits of Module Federation and SSR in our Nx Workspaces!
## How it works
A traditional SSR application is rendered on the server. It receives the requested route from the browser, Angular evaluates that route, and the server generates the HTML and sends it back to the browser.
With Module Federation and SSR, it takes that concept and the concept of MF to allow portions of the app to be run on their own server. The host server will receive the route and if it’s a route pointing to a remote, it will ask the remote to process the route, then send the rendered HTML to the browser.
This gives us full power of SSR but also still allowing us to break our build into multiple smaller builds. It also means that we _could_ redeploy the remote server with new changes without having to redeploy the host server, allowing for independent deployability of features within the overall application.
## Example
Let’s walk through how to set this up with Nx for Angular. We will generate a host application (dashboard) and a remote application (login).
```shell
npx create-nx-workspace@latest myorg
```
You’ll be prompted for the type of workspace you want to create, and the preset to use.
Answer with the following:
✔ Choose what to create · integrated
✔ What to create in the new workspace · apps
✔ Enable distributed caching to make your CI faster · No
> _You will also be prompted whether to add Nx Cloud to your workspace. We won’t address this in this article, but it is highly recommended to use this along with Module Federation to allow for the cache of your remote applications to be shared amongst teammates and CI, further improving your build times. You can learn more about Nx Cloud here:_ [_https://nx.app_](https://nx.app/)_._
When your workspace is created, run `cd myorg`.
Next, we will need to install the [Official Nx Angular Plugin](/nx-api/angular):
```
npm install @nrwl/angular
```
Once this is installed, we only need one command to scaffold out our full Module Federation with SSR architecture:
```shell
npx nx g host dashboard --remotes=login --ssr
```
We will see in the terminal that this generates a bunch of files. What it actually creates is:
Two applications with Angular Universal (SSR)
Webpack Configuration for Browser and Server with Module Federation
We can serve our dashboard (host) application, along with our login (remote) application, by simply running the command:
```shell
npx nx serve-ssr dashboard
```
This will build the browser and server bundles of our login application, then run the login using node.
The login application will be run without any file watchers, meaning that if you make a change to the code for the login application, it will not be reflected automatically. More on this later.
> Note: Nx will cache the build of the browser and server bundles for the login application. If you were to run the command again, it would simply use the cache rather than actually rebuilding the application! 🔥.
Once this is complete, it will then build and run the server for the dashboard application, _with_ file watchers, allowing it to pick up changes to the code.
You should see a success message like this in the terminal:
```
Compiled successfully.
\*\* Angular Universal Live Development Server is listening on http://localhost:4200, open your browser on http://localhost:4200 \*\*
```
Let’s open a new tab in our browser, and open Network tab in the DevTools. After this, navigate to [http://localhost:4200](http://localhost:4200/). You should see the following:
We can see that the server returned the fully rendered HTML for the page!
Angular Universal will switch to CSR after the initial page load, which means if we were to click on the `login` link, it would use CSR to render that page. The Angular Module that is resolved and rendered still lives on the remote server, but Module Federation will still resolve this correctly! 🔥
But to see where the real magic happens, let’s manually navigate the browser to [http://localhost:4200/login](http://localhost:4200/login). You should see that in the Network tab, the fully rendered HTML for the login page has been returned!
Despite the code for that page living on a different, remote, server, the host server composed it correctly and was still able to return the correct HTML for that route, thanks to Module Federation!
And that’s it! It’s super simple to get Module Federation and SSR up and running with Nx!
## Serving the login application and watching for changes
If you’re working on the login application, and are iteratively checking the results of your changes, you’ll want the server to rebuild when you make your change. You can easily enable that by using the `devRemotes` flag::
```shell
npx nx serve-ssr dashboard --devRemotes=login
```
## Learn More
🧠 [Nx Docs](/getting-started/intro)
👩💻 [Nx GitHub](https://github.com/nrwl/nx)
💬 [Nx Official Discord Server](https://go.nx.dev/community)
Let’s be honest. Dealing with tooling is not something enjoyable if you have to deliver code. It should just work and not be in the way. So let’s explore how to kickstart your next React project using Vite, in under 2 minutes, without worrying about the setup.
## Table of Contents
· [How do I create a new project setup?](#how-do-i-create-a-new-project-setup)
· [Running, building and testing the app](#running-building-and-testing-the-app)
· [Building the app](#building-the-app)
· [Testing the app](#testing-the-app)
· [Running integration tests with Cypress](#running-integration-tests-with-cypress)
· [Linting](#linting)
· [Customize Vite and Vitest](#customize-vite-and-vitest)
· [Hidden gem: Caching](#hidden-gem-caching)
· [Hidden gem: Easily modularize your app](#hidden-gem-easily-modularize-your-app)
· [Hidden gem: Visualize your architecture](#hidden-gem-visualize-your-architecture)
· [Hidden gem: Guard your boundaries](#hidden-gem-guard-your-boundaries)
· [Hidden gem: Just run what changed](#hidden-gem-just-run-what-changed)
· [Hidden gem: A dedicated Editor extension](#hidden-gem-a-dedicated-editor-extension)
· [Using CRA? Automatically migrate to Vite + Nx](#using-cra-automatically-migrate-to-vite-nx)
· [Conclusion](#conclusion)
{% youtube src="https://youtu.be/fkTz6KJxhhE" /%}
Traditionally, you might lean towards [Create-React-App (CRA)](https://create-react-app.dev/) started to do precisely that. But what if I told you there’s a better alternative, providing
- not just scaffolding for the initial setup but helping you along the way to generate components, routing, etc
- automatically sets you up with best practices tools for e2e testing, unit testing, code formatting, and linting
- has built-in support for Vite and Vitest (alternatively Webpack & Jest)
- caches your scripts to speed up things
- helps you modularize your application
- comes with automated upgrade features to keep your tooling evergreen
I’m talking about Nx. Nx comes with a set of plugins that come with code generation abilities and help abstract some of the lower-level tooling setups. And this can be really interesting for the use case we wanna tackle today.
> **_Reader:_** _“Wait a minute, I heard about Nx. Isn’t that for monorepos?”_**_Me:_** _“Yeah you’re right. But in 15.3 they introduced something called ‘standalone apps’”
> Reader: “Standalone?”
> _**_Me:_** _“Yeah, a fancy term for a setting up a single app and allows for some cool modularization. There’s a video introducing that feature here:_ [_https://youtu.be/qEaVzh-oBBc_](https://youtu.be/qEaVzh-oBBc)_"
> _**_Reader:_** _“ha, interesting 🤔”_
So let’s go and set up our **React + Vite + TypeScript project**.
## How do I create a new project setup?
To set up a new project, just invoke the following command:
Note `awesomereactapp` is the name of the app and folder being created, and `--preset=react-standalone` tells Nx which template to use when scaffolding the initial setup. You can also invoke it like:
```shell
npx create-nx-workspace@latest awesomereactapp
```
And then choose the option you prefer in the terminal prompt:
First off, let’s run our new, shiny application. Just invoke
```
npm start
```
And in a matter of milliseconds, your app should be served at [http://localhost:4200/](http://localhost:4200/).
`npm start` just invokes the script defined in the `package.json`:
```json {% fileName="package.json" %}
{
"name": "awesomereactapp",
...
"scripts": {
"start": "nx serve",
"build": "nx build",
"test": "nx test"
}
...
}
```
Internally this delegates to `nx serve`, where `serve` is the [Nx target](/reference/glossary#target) to be invoked. You can find those in the `project.json`:
This is where you can see all the targets available for a given project, and you can [add your own](https://youtu.be/iygb-KhAeik)! In a Nutshell, an Nx target contains
- `executor` - a function (here `dev-server`) exposed by the plugin (here `@nrwl/vite`) to run the task at hand. Think of it as the wrapper of your usual Npm scripts
- `options` - this is where you can pass options to the `executor`
- `configurations` - allows you to create different versions of the `options` . You control which configuration is used by passing it via the `--configuration=production` flag to your commands. Also, note the `defaultConfiguration`.
You can go more in-depth if you want on the [Nx docs](/concepts/executors-and-configurations).
## Building the app
Just in the same way as serving our web app, we can build it with
```shell
npx nx build
```
This places an output into a `dist` folder. Now that we've seen the `project.json` targets, you probably guessed that you could customize that output folder directly in those settings.
## Testing the app
This setup also comes with testing baked in using [Vitest](https://vitest.dev/). And you probably guessed it, you can just run tests as follows:
```shell
npx nx test
```
## Running integration tests with Cypress
You might have noticed the `e2e` folder. That's a fully-functioning setup of [Cypress](https://cypress.io/) for doing integration-level or even full end-to-end tests.
This is excellent because you don’t have to configure anything at all. No need to
- Cypress configured to use Vite (instead of Webpack)
- set up linting for the e2e project (yes writing good quality test code is just as important)
- spinning up our development server manually first that serves our React app such that we can load it in our Cypress tests environment
All we need to do is to use
```shell
npx nx e2e e2e
```
This might look weird initially, but basically, we run the `e2e` target (see `e2e/project.json`) on the `e2e` project.
By default, these tests run in headless mode, but you can pass `--watch` to run it interactively with the Cypress test runner such that the tests get re-executed whenever we change our source.
> _Want Cypress Component testing? There’s an Nx generator that can help set that up. Check out the docs:_ [_/nx-api/react/generators/cypress-component-configuration_](/nx-api/react/generators/cypress-component-configuration)
## Linting
And similarly, linting can be triggered by running the following command:
```shell
npx nx lint
```
There’s a `.eslintrc.json` file already at the workspace's root that contains some best practices rules.
## Customize Vite and Vitest
The project setup is made in a way that you can easily customize your [Vite](https://vitejs.dev/) and [Vitest](https://vitest.dev/) setup. Just open the pre-generated `vite.config.ts` at the root of your workspace and add custom Vite plugins or fine-tune Vitest.
```typescript
/// <reference types="vitest" />
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import viteTsConfigPaths from 'vite-tsconfig-paths';
Nx is known for its caching that helps optimize the speed in monorepos. Caching takes the inputs (the command, source files, environment variables…) and computes a hash.
On every run, Nx compares that hash against a local cache folder. If the hash exists, Nx restores the command line output and potential artifacts (JS, CSS,… files) produced by a previous run. This helps speed up computation because you don’t run it if you don’t need to.
> _See Nx the docs for more info:_ [_/concepts/how-caching-works_](/concepts/how-caching-works)
While this obviously makes a lot of sense in a monorepo, it can also help **speed up single-project workspaces**. Most projects have multiple targets, such as `build`, `test`, `lint`. These can be cached! Imagine you have a PR where you change some `*.spec.ts` files because you add a test or fix some. Your CI script probably runs all the targets (`build`, `test`, `lint`) all the time. And it should totally do that. But you could avoid the `build` step because your spec file should not influence that outcome. As such, it could be restored from the cache. `test` needs to run and potentially also `lint` if you run linting also for spec files.
You can fine-tune what goes into the cache for each command. [More on the Nx docs](/recipes/running-tasks/configure-inputs)
## Hidden gem: Easily modularize your app
Imagine a storefront application. You will probably have domain areas like
- Product list — which would have facilities for listing all currently available products, their ratings, user reviews etc
- Orders — for viewing your currently open orders as a user or browsing past orders. Things like placing a new order or triggering a refund on a previously acquired product
- Payments — for handling the payment flow, asking for the credit card, triggering the payment, and starting the order placement process once the payment is successful
- Authentication — which handles the whole signup/login flow and provides lower-level utilities for other domain areas in the app, like getting access to the current user.
- User Profile — which manages everything user related. Think of it when you access Amazon and go to your account. Things like managing your addresses
- …
We’re just scratching the surface here. This can become big quickly. The only way to manage such a structure with the current tooling (including CRA) is to organize these domains in folders. So you’d have something like this in a CRA setup:
```
cra-app
├─ public/
├─ src/
│ ├─ authentication/
│ │ ├─ current-user/
│ │ │ ├─ ...
│ │ │ └─ index.ts
│ │ ├─ login/
│ │ └─ signup/
│ ├─ orders/
│ │ ├─ checkout/
│ │ ├─ place-order/
│ │ ├─ refund/
│ │ └─ order-list/
│ ├─ payments/
│ ├─ products/
│ ├─ user-profile/
│ │ ├─ addresses/
│ │ └─ credit-cards/
│ ├─ App.css
│ ├─ App.tsx
│ ...
├─ package-lock.json
├─ package.json
└─ README.md
```
Most devtools (including CRA) force you into a monolithic structure, where you divide your features into folders. Folders are limited in terms of isolation, though; as your application grows, this might quickly go out of hand.
We can impose a different, stronger structure with Nx by extracting these areas into dedicated libraries or modules. These live side-by-side with your application. Let’s say we have a folder named “domains” which contains these domain areas. Then you can easily generate a new library with the following command:
```shell
npx nx g @nrwl/react:lib checkout --directory=domains/orders/checkout --bundler=none
```
The above command creates a new “ checkout “ library in the `domains/orders/` folder. Here's what it looks like:
```
awesomereactapp
├─ public
│ └─ favicon.ico
├─ src
│ ├─ app
│ ├─ ...
├─ domains
│ └─ orders
│ └─ checkout
│ ├─ src
│ │ ├─ index.ts
│ │ └─ lib
│ │ ├─ domains-orders-checkout.module.css
│ │ ├─ domains-orders-checkout.spec.tsx
│ │ └─ domains-orders-checkout.tsx
│ ├─ tsconfig.json
│ ├─ tsconfig.lib.json
│ ├─ tsconfig.spec.json
│ └─ vite.config.ts
├─ ...
├─ index.html
├─ package-lock.json
├─ package.json
├─ ...
├─ tsconfig.app.json
├─ tsconfig.base.json
├─ tsconfig.json
├─ tsconfig.spec.json
└─ vite.config.ts
```
Notice the `domains/orders/checkout/src/index.ts`: this is the public API of the `checkout` library where you can decide what to export and what should remain private within the library. This conscious process of selecting what to expose and what not leads to a much stronger encapsulation than just a folder structure. It also greatly helps with the maintainability aspect as your app grows.
When generating the library, a TypeScript path mapping is automatically created in the root-level `tsconfig.base.json`:
```json
{
"compileOnSave": false,
"compilerOptions": {
...
"paths": {
"@awesomereactapp/domains/orders/checkout": [
"domains/orders/checkout/src/index.ts"
]
}
},
"exclude": ["node_modules", "tmp"]
}
```
In this way, anything that’s being exported from the `checkout` library can be consumed like
```typescript
import { SomeComponent } from '@awesomereactapp/domains/orders/checkout';
```
You can also just run linting or testing in isolation for these new libraries:
```shell
npx nx test domains-orders-checkout
```
And obviously, caching (as seen previously) would work on these new libraries as well.
> _Note,_ `_domains-orders-checkout_` _is the unique name of the project, composed by its file structure. You can change the name in the_ `_domains/orders/checkout/project.json_` _if you'd like._
## Hidden gem: Visualize your architecture
Another side-effect of splitting up your codebase into libraries is that your code structure and architecture emerge and becomes visible. Nx comes with a `graph` command built-in, so you can even visualize it:
> _Note this is a hypothetical app to demo some of the features of the Nx graph visualization. Some of the connections might only make a little sense._
## Hidden gem: Guard your boundaries
Scaling a software product is more than just the initial structuring and modularization. It consists of a constant ongoing process of ensuring modules stay in shape and don’t contain any undesired cross-references or circular dependencies. You could leverage the Nx graph to verify that visually, but that doesn’t scale.
To help with that, Nx has a built-in [module boundary lint rule](/features/enforce-module-boundaries). Projects can be assigned “tags”, like `type:domain`, `type:utils`, `type:shared` and `domain:products`, `domain:orders`, `domain:auth`. These tags can be assigned in the `project.json`, like
```json
{
// ... more project configuration here
"tags": ["domain:products", "type:domain"]
}
```
> _Note that_ `_type:domain_` _or_ `_domain:products_` _are really just strings. You can define them however you want._
In the `.eslintrc.base.json` you can then define the rules. Here for instance we're stating that a library of `type:utils` can only depend on other utility libraries, while a `type:domain` can depend on both, other domain libraries as well as utility libraries.
If some of these lint rules need to be followed, your editor will show it right in your code, and you can also run lint checks for each PR on CI.
If you’re curious, you can read more [here](/blog/mastering-the-project-boundaries-in-nx).
## Hidden gem: Just run what changed
In such a modular structure (as shown above) where your code is organized in smaller modules/libraries, it is very common that a given team member just works within a single domain area. Hence, very often PRs just touch a subset of the entire set of libraries. Nx comes with a backed-in command that allows you to take advantage of that on CI, using the so-called “[affected commands](/ci/features/affected)”.
Let’s say we make a change in the `product-detail` library of our application. This would affect all other libraries that depend on it. You can also visualize it by running
To make a concrete example, running just tests for those projects:
```shell
npx nx affected:test
```
## Hidden gem: A dedicated Editor extension
If you are not the “command line interface type” developer and you’d rather prefer something integrated within your IDE, then there’s good news. The Nx core team also ships a dedicated VSCode extension: [Nx Console](/getting-started/editor-setup).
It has a dedicated view within VSCode to trigger common commands, browse the workspace structure and even inline render the graph.
Here’s a walkthrough video showing some of the powerful capabilities of Nx Console:
{% youtube src="https://youtu.be/ZST_rmhzRXI" /%}
## Hidden gem: Automated Upgrades
To keep workspaces evergreen, Nx comes with automated code migrations that
- upgrade your `package.json` packages to the next version
- can automatically update your configuration files if necessary
- can automatically update your source files if necessary (in case of breaking changes in the API)
This allows for smooth transitions even if there are breaking changes. Just run
```shell
npx nx migrate latest
```
Nx gathers the currently installed packages and updates them to the latest version. If a package comes with Nx migration scripts, Nx collects them in a `migrations.json` file. You can inspect and then run them. This dramatically helps to keep your project tooling up to date.
Read more about how [Nx migrations work](/features/automate-updating-dependencies) on the docs.
## Using CRA? Automatically migrate to Vite + Nx
If you’re currently on a [CRA](https://create-react-app.dev/) setup, you can easily migrate to an Nx + React + Vite-based setup by running the following command in your CRA project:
{% youtube src="https://youtu.be/zvYb7XCLQzU" /%}
```shell
npx nx init
```
Read more on the Nx docs: [/recipes/adopting-nx/adding-to-existing-project](/recipes/adopting-nx/adding-to-existing-project)
> _If for some reason you cannot migrate to Vite just yet, you can pass_ `_--vite=false_` _to keep a Webpack-based setup for now._
We just released Nx Console 17.28.0 and it comes with a huge new feature: Nx Cloud Integration, right in VSCode! 🎉
In case you’re not sure what it does, Nx Cloud takes your Nx workspace to the next level with awesome features like:
- **Remote Caching** — share your Nx cache with your coworkers and CI agents. By using Nx Cloud, you can be sure that no computation is done twice — throughout your company.
- **Distributed Task Execution** — the most important feature for truly scaling up repositories. Nx already knows about your project graph and what tasks depend on each other. With Nx Cloud, you can leverage this knowledge to distribute tasks smartly across multiple agents while making sure that everything is run in the correct sequence. This can speed up your CI times by orders of magnitude!
- **VCS \[version control system\]** **Integration** — see the results of your CI runs right on your pull request! Nx Cloud can talk to GitHub and other version control systems in real-time, giving you an overview of successes and failures as they happen.
And the best part? It’s free! You won’t pay anything for the first 500 hours of computation time saved per month. If you exceed 500 hours of computation saved, you can buy more; in the worst case, caching stops until the next month. For open-source projects, it’s free even beyond that. 😍
Head over to [http://nx.dev/nx-cloud](/nx-cloud) to learn more.
If you rerun the same task, you can see that the time it took to complete is under a second. This is because of Nx’s [advanced computation caching](/features/cache-task-results). Whenever a task is executed, Nx caches it. If the task has been run before, it just restores the result from the cache. By default, this cache is local to your own workstation. However, with Nx Cloud, you can distribute and share it between machines.
To see it in action, push your newly created access token and have a coworker (or CI pipeline) run a task on their machine. If you execute that same task again, it will be pulled from the cache just like it did locally! 🔮
Out of the box, Nx Cloud works without the need to register. It is, however, highly recommended to create an account and associate it with your workspace. This process is called _claiming your workspace_ and has become much easier with Nx Console! After claiming, you can take full control of your cloud workspace, manage access restrictions and other settings.
Just click on ‘Login and claim your workspace’ to be redirected to the browser where you can sign in to Nx Cloud or create an account. After successful authentication, you will come back to VSCode, where you can select one of your organizations and connect your workspace to it.
From now on, Nx Console will be able to make authenticated requests to the cloud API, so even if you choose to make your workspace private, logged-in users that are authorized to access it can do so.
## Distributed Task Execution
Distributed Task Execution (DTE) becomes very important as your workspace grows. With Nx, powerful features like [computation caching](http://√) and [affected analysis](/ci/features/affected) help you drastically cut down your CI times. Most of the time, large parts of your codebase will not need to be rebuilt and retested. However, we also have to consider the worst-case-scenarios. Let’s say you do change a core lib that everything in your monorepo depends on. This could mean hundreds or even thousands of projects needing to be rebuilt and retested, which would mean hours of CI time. This is obviously very impractical and you should consider solutions that allow you to parallelize all this work and keep worst-case CI times at a reasonable level. [There are different approaches to achieving this](/ci/concepts/parallelization-distribution) but it’s hard to get right and not something most teams want to spend engineering resources on.
Distributed Task Execution with Nx Cloud solves this issue — it allows you to optimally parallelize tasks without thinking about their interdependencies or agent management. You don’t have to use it immediately, but it’s useful if you want to keep your CI times low even as your workspace grows. 🚀
DTE is available for all Nx Cloud workspaces with minimal setup. If you see a yellow DTE status in Nx Console, that just means you haven’t used it yet. [Check out the docs](/ci/features/distribute-task-execution) to [learn more about the motivation for DTE](/ci/concepts/parallelization-distribution) and [how to test it out in your workspace](/ci/features/distribute-task-execution).
Nx Cloud isn’t just great for its remote caching and DTE features, it also generates readable and searchable reports for any executed tasks — whether it be 10 or 10.000. In a monorepo, your CI pipelines will seldom run just a single task. It’s more common to have commands like `nx affected — -target=build` which amounts to “rebuild everything that changed”. This could potentially be dozens, hundreds or thousands of tasks. If something goes wrong, combing through thousands upon thousands of lines of logs quickly becomes tedious. So having a nicely structured, per-target view that you can filter and sort while still preserving all terminal styling is incredibly useful!
To take advantage of this valuable information without changing your development workflow, use the Nx Cloud integration for your favourite platform: Github, GitLab or Bitbucket Cloud. You can see the results of your cloud runs in a PR comment with an overview of failed tasks and links to easily readable outputs. No more scrolling through endless logs until you find what you need!
To set it up, just click on the button in the Nx Console cloud view and follow the prompts in your browser. Read more in the [full guide on connecting your workspace to](/ci/recipes/set-up/monorepo-ci-github-actions) VCS.
Let’s talk about configuration. The detractors call it boilerplate while proponents call it scaffolding or infrastructure. No matter what your feelings are, configuration code is all the setup that needs to be done before you can work on the features that actually accomplish something for your business. Like road maintenance, infrastructure code is often unnoticed when it is done well, but as soon as problems crop up, everyone feels the pain. How can this crucial configuration code be effectively maintained without dragging down the productivity of your development team?
## Less Configuration
There have been many attempts over the years to make it easier to bypass configuration code.
Ruby on Rails popularized the philosophy of Convention over Configuration. In this philosophy, the default configuration settings are derived from your folder structure or the way you name your files. These unwritten conventions are used as a way of bypassing writing configuration files that most of the time will follow a set pattern.
Parcel advertises itself as a zero configuration bundler. This is mostly a reaction to webpack, which requires a fairly complex config file before it can do anything useful. As application grow more complex, so does the config file. These often become so complicated that developers dread fixing any problems with them, because once it becomes known that they have fixed a problem with webpack, they will be forever saddled with the burden of maintaining that file. In contrast, Parcel does all the tasks required of a typical SPA web app without any config file.
Apple also leveraged this sentiment with marketing slogan “It Just Works”. Compared to Windows or Linux ecosystems that require modifying settings to get software from different companies to work together, Apple provides its own suite of tools and hardware that have a major selling point of being intentionally designed to all work together. Theoretically, any hardware or software produced by Apple should fit seamlessly into the rest of the system.
All of these efforts to skip the configuration step reach their limits at some point. The idea of hiding default configuration works well, until you need to modify that default and have no starting point. The Zen of Python philosophy of “explicit is better than implicit” is a direct contradiction to Convention over Configuration. If you like most of what the zero config tool gives you, but you want to tweak it a little bit, it can be hard to find where to do the tweaking. Apple is great when It Just Works. But sometimes, It Just Doesn’t.
## How much configuration is the right amount of configuration?
When your application is just getting started or when the configuration defaults work just fine for you, any time spent writing those defaults is wasted time and mental space. This applies to default configuration for initializing a project as well as default configuration for adding a new route or component in your application. When a developer is starting a new project or feature, we want their initial burst of energy to go as much as possible toward code that is valuable for the business, rather than code that is just infrastructure.
On the other hand, when the infrastructure code needs to be modified to make your application faster or modify the way the app behaves in some way, that infrastructure code needs to be easily accessible and clearly organized so that developers don’t need to understand everything about the system before they can change a single part.
## Skip the Scaffolding
A cursory glance at the repos on Github will reveal numerous starter repos that people use to bypass the initial time investment involved in setting up the initial configuration files. Yeoman was a tool used to help generate scaffolding code, both for starting a project and for creating new sections of an application.
The problem with both of these tools is that any code they generate for you is instantly technical debt. By definition, no one in your company wrote the code that was created by those tools. But developers in your company will now have to maintain this code that they didn’t write. Even if the starter project or Yeoman generator was well maintained and always used the latest state of art practices, any application built using them will only be state of the art the instant its created. The infrastructure code grows stale without constant maintenance.
Nx has an elegant solution to this dilemma. There are three key parts.
1. Use [code generators](/features/generate-code) to create configuration files that you can safely ignore
2. Modify those configuration files whenever your application needs some custom setting
3. Run [migration generators](/features/automate-updating-dependencies) to maintain state of the art defaults
If you never think about a configuration file is it still technical debt? Some people are put off by the number of configuration files that Nx generates when creating a new application. Perhaps these developers have been burned by starter repos burdening them with instant technical debt that must be maintained. These config files are created only for the eventuality that some day you’ll need to modify them.
When you do need to modify a setting for Webpack, Vite or Jest (or any of the other tools for which we maintain plugins) the configuration file provides you an easy access point to make your own modifications without needing to understand all the default settings.
Every Nx plugin provides migration generators that will automatically update the default settings to the latest state of the art. With these generators, Nx can take on the burden of maintaining your infrastructure code, except for the specific portions that your developers have customized.
## One Size Never Fits All
While the generators that Nx provides work for most people, there will always be infrastructure that is unique to your own organization. Nx makes it easy to extend generators so that your developers can use generators that create code that has been tailored to your own organization’s set up. Instead of having a manual check list to run through every time a developer makes a new feature, you can automate that check list with a generator.
## Negative Configuration?
Nx provides the ability to define default configuration settings at the global level and have individual projects inherit those settings from the global defaults. If a lot of your projects have the same settings, adding Nx to your repo will actually reduce the lines of code in your codebase — thus negative configuration. This isn’t convention over configuration or zero configuration, because the configuration settings are still explicitly defined. The configuration code is just better organized and defined in a predictable way.
If you’re ready to have Nx help you manage your infrastructure so that your developers can speed down the highway without needing to avoid configuration potholes, check out [nx.dev](/getting-started/intro) to get started.
## Learn more
- [🧠 Nx Docs](/getting-started/intro)
- [👩💻 Nx GitHub](https://github.com/nrwl/nx)
- [💬 Nx Official Discord Server](https://go.nx.dev/community)
Developers love to argue about whether Tailwind is good, almost like arguing about code formatting or tabs vs. spaces (I use spaces!!). But whether you love it or hate it, Tailwind has found massive adoption among the frontend developer community. In fact, I’m right now in the process of refreshing and rebuilding my personal site (it will be at [https://juri.dev](https://juri.dev/) soon, so keep an eye on that).
Tailwind has good docs around getting started quickly. There are options to set up Tailwind with their Tailwind CLI, PostCSS, and framework-specific guides.
- installing `tailwindcss`, `postcss` and `autoprefixer`
- configuring your `tailwind.config.js` to make sure Tailwind can properly "purge" its generated CSS file based on the content files (usually your `html`, `[j|t]sx`, `[t|j]s` )
- adjusting your main CSS file to include the Tailwind base classes (in case you want to use Tailwind also in your CSS files, a heated topic)
**One important thing:** if you use [Create-React-App](https://create-react-app.dev/) you might want to check out [what the Tailwind docs say](https://tailwindcss.com/docs/guides/create-react-app) first.
This came up a couple of weeks ago due to a [PR opened on the CRA repo](https://github.com/reactjs/reactjs.org/pull/5487) asking to kinda deprecate it as the main choice for new React projects. I couldn’t help but share my opinion on this as well:
{% youtube src="https://youtu.be/fkTz6KJxhhE" /%}
And so did also [Fireship](https://youtu.be/2OTq15A5s0Y) and ultimately [Dan Abramov](https://github.com/reactjs/reactjs.org/pull/5487#issuecomment-1409720741). Anyway, if you’re in the **“CRA situation”, read on**. There’s a way to get unblocked there.
## There is an easier way — Code Generators
Code generators speed up such configuration tasks. They are valuable for scaffolding the initial project structure and adding new features to the app setup, such as Tailwind.
Nx has such generators. To use them, you need an Nx-based React setup. If you’re starting new, you can create an [Nx Standalone React project](/getting-started/tutorials/react-standalone-tutorial) easily using the following command
As you can see, this allows you to choose which bundler to use as well as other options (such as the CSS setup). Again, this is already such a code generator that creates this initial project scaffold.
Alternatively, **if you happen to use CRA already**, you can easily convert to an Nx and Vite (or also Webpack) based setup by running:
```shell
$ npx nx@latest init
```
You can pass `--vite=false` if you still want to keep the Webpack configuration or pass `--integrated` if you already plan to have a monorepo instead of a single-project setup. The [Nx docs go into more detail here](/recipes/adopting-nx/adding-to-existing-project).
## Generating a Tailwind Setup
Once you have a [Nx-based React](/getting-started/tutorials/react-standalone-tutorial) setup, adding Tailwind is as easy as running:
```shell
$ npx nx g @nrwl/react:setup-tailwind
```
This launches a generator that will guide you through the setup. It works **not only for Nx React-based projects** but **also if you use Next.js** in an Nx workspace.
You’ll get
- Tailwind, PostCSS, and Autoprefixer installed
- Tailwind configured together with PostCSS
- your main `styles.css` file updated with the Tailwind base classes
It’s almost a tradition to have some stats at the beginning of our Nx release blog posts. This time, about our YT channel: incredibly, we crossed 10k subscribers [on our Youtube channel](https://www.youtube.com/@nxdevtools)!!
Apart from delivering high-quality engineering work, we’re very invested in producing educational content around developer tooling and monorepos. We’ve been almost consistently shipping new content every week, whether that is blog posts on the [Nx blog](/blog) or in the form of new videos and live streams on our channel. Seeing our audience grow on Youtube confirms we’re on the right track and gives us new fuel to keep pushing!!
If you haven’t subscribed yet, please do 🙏: [https://www.youtube.com/@nxdevtools](https://www.youtube.com/@nxdevtools). We also announce most of our new videos and live streams [on Twitter](https://twitter.com/nxdevtools).
## Updates to our Nx Plugin Guides
Nx has been designed to be extensible from the ground up. Which is precisely why Nx Plugins are so powerful. They don’t just come as part of an Nx integrated monorepo or standalone setup. Still, you can leverage them in the same way to automate your local workspace or even share them as proper Nx plugins with the community.
Please have a look at our updated guide: [/extending-nx/tutorials/organization-specific-plugin](/extending-nx/tutorials/organization-specific-plugin)
## Nx meets Node — First-Class Support landed
{% youtube src="https://youtu.be/K4f-fMuAoRY" /%}
Due to a lack of time we never invested much more into streamlining the Node experience within Nx, though. This [changed now](/blog/from-bootstrapped-to-venture-backed), which is why we’re committed to making Nx the best developer tool for node based apps. Starting with v15.7 we improved support for [ExpressJS](https://expressjs.com/), [Fastify](https://fastify.io/) and [Koa](https://koajs.com/).
When starting a new Nx workspace, you now have a new option: “Standalone Node Server app”.
This is when you want a single-project Nx workspace to build out your Node backend.
All the features Nx is known for also apply to backend development. That includes
- **code generation support** for all the previously mentioned Node frameworks
- avoiding monolithic codebases via **modularizing it with local libraries** (with code generation support)
- Ability to **automatically setup a Dockerfile** for packaging your app
- **Optionally bundle** your Node app for easy deployment in the case of edge-functions
- **Speed** via running building, linting, testing for only **(**[**affected**](/ci/features/affected)**) parts of your applications**, via [caching](/concepts/how-caching-works) and [optimized CI setups](/ci/features/distribute-task-execution)
- the ability to use and/or expand to a monorepo
This is the first iteration with first-class Node support. But we’re already working on a whole set of improvements for the Nx + Node story. So stay tuned!
## Detaching Angular versions
{% youtube src="https://youtu.be/AQV4WFldwlY" /%}
The Angular CLI supports a single version of Angular and requires the user to upgrade them together with the help of automated upgrade mechanisms like `ng update`. On the other hand, Nx operates on a different release cycle and is independent of Angular versions. However, prior technical limitations resulted in each Nx major version only being compatible with a specific Angular major version. This caused challenges for Angular developers and corporations who were either stuck on an older Angular version or unable to upgrade promptly but still wanted access to the latest and greatest Nx features for increased productivity.
Starting with v15.7.0, the `@nrwl/angular` plugin will support both Angular v14 and v15, and our goal is to continue supporting the Angular LTS versions from Angular v14 onwards.
New workspaces will always be created with the latest Angular version, but during migration, you can skip some package updates as defined by Nx plugin authors. For Angular, this means you can skip migrating to newer versions. This feature can be enabled by running the following command in an interactive mode:
```
$ nx migrate latest --interactive
```
When collecting migrations in interactive mode, you’ll be prompted to apply any optional migrations, and any updates you choose to skip won’t be applied. The rest of the updates will be used as usual.
If you need to apply an Angular update that you previously skipped, you can collect migrations from an older version of Nx by running:
```
$ nx migrate latest --from=nx@<version>
```
In particular, we’re working on making that part more intuitive in upcoming versions.
Also, have a look at our [updated docs](/recipes/tips-n-tricks/advanced-update) as well as our [Nx and Angular compatibility matrix](/nx-api/angular/documents/angular-nx-version-matrix) for more details.
## Bootstrapping a new Angular app with Standalone API support
{% youtube src="https://youtu.be/Hi3aJ0Rlkls" /%}
Angular’s new [standalone APIs](https://angular.io/guide/standalone-components) is exciting as it provides a new, more lightweight way of developing and composing Angular applications without the need for `NgModules`. Nx has had the ability to generate new Angular components using the Standalone API for a while. With v15.7, we now also allow you to quickly bootstrap a new single-project Nx workspace with a NgModule-less Angular application.
```shell
npx create-nx-workspace@latest ngapp
--preset=angular-standalone
--standaloneApi
```
## Lockfile parsing and pruning
Lockfiles can be highly complex, and different formats across the NPM, Yarn, and PNPM package managers don’t make it easier. Nx used to consider the lock-file a black box. Starting with 15.7, this changes! Nx can now properly process the lock-file of all three major package managers (and their different versions!).
Why is this useful? Glad you asked! Mostly for three reasons:
- more **accurately map the nodes and dependencies** in the Nx graph (yep the graph also includes npm packages used by every single project)
- generate a `package.json` with **precise snapshot of the used versions** (especially useful in a monorepo with single-version policy)
- ability to **generate a pruned lock-file** that can be used along-side the `package.json` when packaging your app in a Docker container
Some of our plugins’`build` executors include:
-`generatePackageJson` flag (`@nrwl/webpack:webpack` and `@nrwl/node:webpack`) that automatically generates `package.json` and lock file.
-`generateLockfile` flag (`@nrwl/js:swc`, `@nrwl/js:tsc` and `@nrwl/next:build`) that generates lock file
If you’re an Nx plugin developer, you can generate `package.json` and lock file using the following functions from the `@nrwl/devkit` package:
```
import { createPackageJson, createLockFile } from '@nrwl/devkit';
Stay tuned for a more in-depth blog post coming soon to [our blog](/blog).
## Storybook 7.0 beta support
Nx provides support for Storybook version 7.0 beta, with generators and executors, so that you can try it out now, either in a new or in your existing Nx workspace. Storybook version 7 is a major release that brings a lot of new features and improvements. You can read more about it in the [Storybook 7 beta announcement blog post](https://storybook.js.org/blog/7-0-beta/). Apart from the new features and enhancements, it also brings some breaking changes. You can read more about them in the [Storybook 7 migration docs](https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#from-version-65x-to-700) and the [Storybook 7 migration guide](https://chromatic-ui.notion.site/Storybook-7-migration-guide-dbf41fa347304eb2a5e9c69b34503937). Do note that _version 7 is still in beta_, and so is the Nx support for it.
You can try out Storybook 7.0 beta in a new Nx workspace by passing the `--storybook7betaConfiguration` flag when generating the Storybook configuration for your projects. Read more in our [Storybook 7 setup guide](/nx-api/storybook/documents/storybook-7-setup). If you want to migrate your existing Storybook configuration to Storybook 7.0 beta, please read our [migration guide](/nx-api/storybook/generators/migrate-7).
## More flexible Webpack config
{% youtube src="https://youtu.be/CIT4MFMraXg" /%}
Previously when you created a new React application with the Nx `@nrwl/react` plugin, the actual Webpack config was hidden within the plugin itself.
It was for a good reason, but at the same time, it is a thin line to walk between giving more flexibility and ensuring integrity and consistency (not to speak about features such as [automated code migrations](/features/automate-updating-dependencies)). We wrote a [blog post about it last week](/blog/configuration-files-and-potholes-in-your-codebase).
Inspired by our new [Vite setup](/nx-api/vite), which allows for a more modular configuration in the `vite.config.ts`, we wanted to bring some of the same flexibility to our Webpack setup as well. As such, now every Nx Webpack setup (e.g. a new React + Webpack based app) have a `webpack.config.js` in the project root. Old project are automatically migrated to this new setup.
If you want to upgrade but still retain the previous behavior, we introduced an `isolatedConfig` mode that can be set to `false`. More details on our docs: [/recipes/webpack/webpack-config-setup](/recipes/webpack/webpack-config-setup)
## How to Update Nx
Updating Nx is done with the following command and will update your Nx workspace dependencies and code to the latest version:
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
npx nx migrate --run-migrations
```
## Coming up
We are currently working on some exciting stuff, including
- Deno support
- Improvements to Nx Console, including support for IntelliJ
- NestJS
- Rust 👀
- Nx for non-JS environments
- …
So keep an eye on our [Twitter](https://twitter.com/nxdevtools), [Youtube](https://www.youtube.com/@nxdevtools) and [blog](/blog) to not miss those announcements.
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
Version 15 of [NgRx](https://ngrx.io/) introduced Standalone APIs to the package, enabling usage of the NgRx with Standalone Component-based [Angular](https://angular.io/) applications. This allows for a simpler integration of NgRx to your application.
Nx has added support for using these Standalone APIs from NgRx when generating NgRx stores with our `@nrwl/angular:ngrx` generator when you give it a path to a `Routes` definition file. _(Usually denoted by_`_*.routes.ts_`_)_
In this article, we’ll walk through using Nx to create a new Standalone Component-based Angular application and add NgRx to it, using _ONLY_ Nx Generators!
**Prefer a video version? We’ve got you covered!**
This is important, as this is the file where your root NgRx providers need to be placed, within the `providers` option of the `bootstrapApplication` function.
Nx will aid this also!
## Generate the root state
`nx g @nrwl/angular:ngrx --root --parent=src/main.ts`
You’ll be asked for a name for the feature state, but you can ignore this and simply press enter in your terminal, it is not necessary at this stage.
Notice the addition of `provideEffects()` and `provideStore()` to the `providers` array.
## Generate a new feature library
NgRx works better when you split your store based on the features you have within your application. This is a pretty common use case. Nx allows you to do this very easily and in a very structured way.
First, let’s generate a new feature library, called `feature-users`, in Nx that will house everything related to our feature including the NgRx State.
`nx g @nrwl/angular:lib feature-users --standalone --routing --lazy --parent=src/app/app.routes.ts`
This command does a few things:
- It creates a new library in our Nx Workspace
- It uses an Angular Standalone Component as the entrypoint
- It adds a routing configuration to the library and adds the component as the default route.
- It will add a lazy-loaded route to the application’s `app.routes.ts` file, wiring up the application to the library!
Some files you may want to explore in your own time are:
`src/app/app.routes.ts`
`feature-users/src/lib/lib.routes.ts`
## Add feature state to the feature library
Now that we have a feature library for our users feature, let’s generate the feature state! It’s as simple as one command.
`nx g @nrwl/angular:ngrx users --parent=feature-users/src/lib/lib.routes.ts --route=''`
You’ll be asked if this is the root state of the application, enter `N`. Then say no to Facades (unless you really want them).
The `--route` option here is used to dictate what `route` within our routes definition file (`lib.routes.ts`) should have the state attached to it. This is to allow the NgRx Standalone APIs to be attached to that route.
We can see that if we look at the `lib.routes.ts` file
```
import { Route } from '@angular/router';
import { FeatureUsersComponent } from './feature-users/feature-users.component';
import { provideStore, provideState } from '@ngrx/store';
import { provideEffects } from '@ngrx/effects';
import \* as fromUsers from './+state/users.reducer';
import { UsersEffects } from './+state/users.effects';
And with that, we now have NgRx installed and integrated into our application!
If you’d like to confirm the integration, you can run the following commands and see successful outputs!
`nx build`
`nx test`
`nx test feature-users`
## Conclusion
This guide has shown how easy it is to set up NgRx with Nx and how to take advantage of the latest Standalone APIs with your application. All with just 5 Nx commands!
With the Angular roadmap pointing to Standalone Components becoming the preferred option for developing Angular applications, this support will be crucial in the future, and Nx will help you achieve it with the best possible DX!
> Btw, did you know you can now scaffold a single-project Angular Nx workspace that fully leverages the Standalone APIs? Check it out here: [https://youtu.be/Hi3aJ0Rlkls](https://youtu.be/Hi3aJ0Rlkls)
You can check out an example repository that was created following the steps above here: [https://github.com/Coly010/nx-ngrx-standalone](https://github.com/Coly010/nx-ngrx-standalone)
## Learn More
🧠 [Nx Docs](/getting-started/intro)
👩💻 [Nx GitHub](https://github.com/nrwl/nx)
💬 [Nx Official Discord Server](https://go.nx.dev/community)
In case you missed it, Lerna version 6.5 recently launched. We’ll catch you up on the latest Lerna news and newest features.
## Table of Contents
- [Lerna: Brought to You by Nx](#lerna-brought-to-you-by-nx)
- [Still On Lerna 4?](#still-on-lerna-4)
- [Idempotency Added to the `lerna publish from-git` Command](#idempotency-added-to-the-lerna-publish-fromgit-command)
- [`lerna run` Can Run Multiple Scripts In a Single Command](#lerna-run-can-run-multiple-scripts-in-a-single-command)
- [New --include-private Option Added To lerna publish](#new-includeprivate-option-added-to-lerna-publish)
- [Massive Refactor](#massive-refactor)
- [Getting Started With Lerna From The Lerna Team](#getting-started-with-lerna-from-the-lerna-team)
- [The Future of Lerna](#the-future-of-lerna)
## Lerna: Brought to You by Nx
In case you missed it, Lerna, the OG JavaScript monorepo tool, went largely unmaintained for a while, starting around 2020. Then, it officially declared itself to be unmaintained in April of 2022, only for Nx to step in to take over maintenance of the project in May of 2022!
You can find a more detailed account of Lerna’s “Maintainance Odyssey” in [this article](/blog/lerna-is-dead-long-live-lerna).
Since Nx took over in Lerna 4, we’ve added a brand new site to refresh the Lerna Docs:
The top of our priorities for Lerna 5 was to resolve all vulnerabilities and outdated dependencies facing Lerna. We went on to make Lerna faster by allowing users to [opt into Nx’s task caching inside of Lerna with the new `lerna add-caching` command](https://github.com/lerna/lerna/tree/main/packages/lerna/src/commands/add-caching#readme), and [add support for distributed caching to share task results amongst your organization in Lerna with Nx Cloud](https://lerna.js.org/docs/features/share-your-cache).
We were proud to go on to launch [Lerna 6](/blog/lerna-reborn-whats-new-in-v6) last October, where we began focusing on further improving Lerna’s feature set — focusing specifically on its unique strengths: versioning and publishing.
## Still on Lerna 4?
[Here’s how to upgrade to the latest and greatest](https://lerna.js.org/upgrade).
We’ve also started an initiative to assist Open Source projects in getting the most out of Lerna. Projects that use Lerna can now request free consulting to learn how to take advantage of Lerna’s newest features.
We’ve just started this initiative and have already been able to help [Sentry](https://github.com/getsentry/sentry-javascript) get optimized with task caching and task pipeline optimizations for their workspace!
This initiative complements [our free tier of unlimited Nx Cloud](/pricing) for any Open Source project.
If you’re interested in optimizing your Open Source project to take advantage of the latest Lerna features, [reach out to us on Twitter!](https://twitter.com/lernajs)
Now let’s jump into the newest Lerna 6.5 features!
## Idempotency Added to the `lerna publish from-git` Command
{% youtube src="https://youtu.be/kh4TaiKbC8c" /%}
“Idempotent” is a word used to describe an operation you can perform any number of times, and the resulting state is the same as if you had only run the operation once.
The [`lerna publish` command](https://github.com/lerna/lerna/tree/main/libs/commands/publish#readme) is a beneficial tool for quickly publishing multiple packages from your workspace:
- Running `lerna publish` by itself will version and publish all packages in the workspace since your latest release
- Running `lerna publish from-git` will publish all projects tagged in the latest commit
- Running `lerna publish from-package` will publish all projects whose version does not yet exist in the target registry based on the version listed in their `package.json` file.
As we can see, `lerna publish from-package` is already idempotent (since it only publishes packages whose version doesn't exist, any run past the first will not adjust the state of the registry).
With 6.5, we’ve added the same idempotency to `lerna publish from-git`. This update is handy for recovering from a situation where some of your packages failed to publish initially (maybe due to a networking issue).
[For more information, check out the PR](https://github.com/lerna/lerna/pull/3513)
## `lerna run` Can Run Multiple Scripts In a Single Command
For 6.5, we’ve added the ability to run multiple scripts in a single `lerna run` command! Checkout this quick video demonstrating this below:
{% youtube src="https://youtu.be/Ey73CEGcVKw" /%}
Learn more [here](https://github.com/lerna/lerna/pull/3527).
## New `--include-private` Option Added To `lerna publish`
[Npm supports a `["private": true]` configuration](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#private) as a way of preventing the publication of a library that is private.
Running `lerna publish` with this new [`--include-private`](https://github.com/lerna/lerna/tree/main/libs/commands/publish#--include-private) option (as above) will strip this `"private": true` configuration from the `package.json` of the packages listed in the command.
This new option is beneficial for the use case where you’d like to run e2e for a package that will eventually be public but is currently private to prevent getting published too soon.
You can find more information on this change [here](https://github.com/lerna/lerna/pull/3503).
## Massive Refactor
Unlike the other updates mentioned for 6.5, this update does not affect Lerna’s public API, but as you can see from the numbers, this was quite an undertaking:
The result is a significant improvement to the Typescript support for Lerna’s internals and a substantial simplification of the codebase. This investment will make Lerna significantly more approachable to other would-be contributors!
Find more on this change [here](https://github.com/lerna/lerna/pull/3517).
## Getting Started With Lerna From The Lerna Team
We recently ran a live stream with [James Henry](https://twitter.com/MrJamesHenry) and [Austin Fahsl](https://twitter.com/AustinFahsl) from our Lerna team to show how to get started with Lerna, all the way through to versioning and publishing our packages to npm!
{% youtube src="https://youtu.be/HqPOoU35xzA" /%}
Check out the recap of this session above, and check out [the repo from our session on GitHub](https://github.com/ZackDeRose/for-the-lulz).
## The Future of Lerna
Looking to the future, we are targeting Q2 of 2023 for Lerna v7 (including a `--dry-run` option for both `lerna version` and `lerna publish` commands - you can catch a sneak-peak of this in James' talk from Nx Conf 2022 below!)
{% youtube src="https://youtu.be/CNdDv2MsBuw" /%}
You can find [a roadmap for all the features we plan to add in Lerna 7](https://github.com/lerna/lerna/discussions/3410) on Github!
There are many decisions to make when it comes to building a Node API. There are a variety of frameworks to choose from (Express, Fastify, Koa, etc.), and a million different ways to build and deploy the application.
In this article, I’ll show you the easiest way to go from zero to production by using Nx to create a Node API project.
We’ll be using [Fastify](https://www.fastify.io/) as the framework of choice. Fastify is a fast (as the name implies) and low-overhead server in Node. It has grown in popularity, recently crossing the 1 million weekly download mark on npm. I’m a fan of Fastify’s plugin architecture, and the ecosystem is quite impressive, boasting over [250 core and community plugins](https://www.fastify.io/ecosystem/).
## **Table of Contents**
· [Creating the project](#creating-the-project)
· [Running tests](#running-tests)
· [Building for production using esbuild](#building-for-production-using-esbuild)
· [Docker support](#docker-support)
· [Deploying the server](#deploying-the-server)
· [Summary](#summary)
**Prefer a video version? We’ve got you covered!**
--preset=node-standalone \ # create a Node.js project
--framework=fastify \ # other options are express and koa
--docker # we'll touch on this later on
```
To run the server in dev-mode, use `npx nx serve` (aliased to `npm start`), and you should see the server starting at port 3000.
```
$ curl <http://localhost:3000>
{"message":"Hello API"}
```
A couple of notable files:
- The `src/main.ts` file is responsible for starting the Fastify server and registering plugins.
- The `src/app/app.ts` file is the app plugin that provides an initial endpoint at `/` that replies with `{"message": "Hello API"}`.
When you edit the source code, the server will reload. You can pass `--no-watch` to disable this behavior.
## Running tests
In additional to generating the source code, Nx will also create two test suites:
1. Unit tests via `npx nx test` (aliased to `npm run test`).
2. E2E tests via `npx nx e2e e2e` (aliased to `npm run e2e`).
Unit tests take advantage of Fastify’s plugin architecture, and allows you to test each plugin in isolation. It runs using [Jest](https://jestjs.io/), which is the most popular test runner in Node.
```
// src/app/app.spec.ts
// This file is generated by Nx.
import Fastify, { FastifyInstance } from 'fastify';
import { app } from './app';
describe('GET /', () => {
let server: FastifyInstance; beforeEach(() => {
server = Fastify();
server.register(app);
}); it('should respond with a message', async () => {
The E2E tests run against the actual server (with all plugins registered), which gives better real-world guarantees.
```shell
$ npx nx serve &# run server in background
$ npx nx e2e e2e # run test suite
GET /
✓ should return a message (27 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.429 s
Ran all test suites.Tearing down... ——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————— >
NX Successfully ran target e2e for project e2e (3s)$ lsof -i:3000 -t | xargs kill# stop server process
```
There are trade-offs between speed versus confidence when it comes to unit versus E2E tests, which is a topic that is out of scope for this article. I think you should do both, but this is a discussion be held with your team. Nx supports both cases out of the box.
## Building for production using esbuild
Now that we have our production-ready app, let’s examine how Nx handles the build process using [`esbuild`](https://esbuild.github.io/).
`esbuild` is a bundler written in Go that is extremely fast — it is much faster than other bundlers like webpack and parcel, but that may change in the future as other tools make their own speed improvements.
When you run the build command, Nx uses `esbuild` to generate a self-contained app bundle, which does not require `node_modules`.
NX Successfully ran target build for project api (2s)
```
A cool feature of Nx, is that commands such as `build` and `test` are cached if the project (or its dependencies) have not changed. If we run the build a second time, you’ll see it completes in a few milliseconds.
```shell
$ npx nx build
> nx run api:build # existing outputs match the cache, left as is
NX Successfully ran target build for project api (16ms) Nx read the output from the cache instead of running the commandfor1 out of 1 tasks.
```
We’ll touch more on the caching when we look at Docker support.
And now that the server bundle is ready, we can run it.
```
$ node dist/api
{"level":30,"time":1675880059720,"pid":70605,"hostname":"mbp.lan","msg":"Server listening at http://\[::1\]:3000"}
{"level":30,"time":1675880059721,"pid":70605,"hostname":"mbp.lan","msg":"Server listening at <http://127.0.0.1:3000>"}
[ ready ] <http://localhost:3000>
```
You can even run the e2e suite against the production bundle: `npx nx e2e e2e`.
## Docker support
Recall that we passed the `--docker` option when creating the API project. WIth this option, Nx will generate a default `Dockerfile` and a `docker-build` target.
```shell
# This file is generated by Nx.
#
# Build the docker image with `npx nx docker-build api`.
# Tip: Modify "docker-build" options in project.json to change docker build args.
#
# Run the container with `docker run -p 3000:3000 -t api`.
FROM docker.io/node:lts-alpine
ENV HOST=0.0.0.0
ENV PORT=3000WORKDIR /appRUN addgroup --system api &&\
adduser --system -G api apiCOPY dist/api api
RUN chown -R api:api .CMD ["node", "api"]
```
To build the image, run `npx nx docker-build`. The image copies only the self-contained bundle, so no `npm install` at all!
Nx is smart enough to bundle the app before building the Docker image — because of the `dependsOn` configuration in `project.json`. You can visualize this dependency with `npx nx graph`.
{"level":30,"time":1675880993256,"pid":1,"hostname":"248744de020a","msg":"Server listening at <http://0.0.0.0:3000>"}
[ ready ] <http://0.0.0.0:3000>
```
**Note:** The server binds to `0.0.0.0` so that it can be access from the host machine. You can run curl to verify that it indeed works, or better yet use the E2E test suite (`npx nx e2e e2e`)!
## Deploying the server
There are numerous platforms that we can deploy our app to. I like [Fly.io](https://fly.io) since it very easy to deploy all over the world using the CLI, and it comes with good [Docker support](https://fly.io/docs/languages-and-frameworks/dockerfile/).
If you haven’t used Fly before, please follow their [short getting started guide](https://fly.io/docs/speedrun/) (5–10 mins).
Once you are ready, let’s configure our project.
```
$ fly launch --generate-name --no-deploy
```
Follow the prompts and a `fly.toml` file will be generated, which contains the Fly configuration. We need to update this file with the correct port used by our image.
```
[[services]]
http_checks = []
internal_port = 3000 # Make sure this matches what the app listens on
```
Now we can deploy the app.
```
$ fly deploy
```
Fly will log out the monitoring link when the app is successfully deployed.
That’s it! Our server is now deployed for the world to use.
## Summary
In this post, we saw how easy it is to go from zero code to a deployed server using Nx. Here is a quick summary of the points.
1. Use `create-nx-workspace --preset=node-standalone --framework=fastify --docker` to quickly create a Fastify server project.
2. Nx provide both unit test and E2E test suites — `npx nx test` and `npx nx e2e e2e`.
3. Nx builds the server using esbuild — `npx nx build`.
4. Docker support is provided out of the box via the `--docker` option, and Nx understands that Docker build depends on the app to be bundled. Run it via `npx nx docker-build`.
5. Deploying to Fly (or other platforms) is easy since we have a Docker image.
To learn more about Nx and what else it can do, refer to the [intro page](/getting-started/intro) in the docs.
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
Before we go into details of Nx Console for IntelliJ, we’d really want to go and **thank our community**. [\* \*_Issam Guissouma_\*\*](https://twitter.com/iguissouma) and [**_Edward Tkachev_**](https://twitter.com/etkachev) from the
Nx community had their own Nx Console plugins for IntelliJ out there already for a while. And they have been super
popular. As such we’d like to take the occasion to give them a shout-out for the awesome work on the community plugins,
but also for closely collaborating with us over the last weeks to build our official IntelliJ support for Nx Console.
Especially Issam has been actively helping us port over all the features he built to the official Nx Console plugin. So
be sure to look out for the upcoming release because it’s going to be another huge one!
### Table of Contents
· [Going from one IDE to two](#going-from-one-ide-to-two)
· [Nx Language Server](#nx-language-server)
· [Generate UI](#generate-ui)
· [Communicating with IntelliJ](#communicating-with-intellij)
· [Adapting Styling](#adapting-styling)
· [JCEF](#jcef)
· [Glueing it together](#glueing-it-together)
· [Looking ahead](#looking-ahead)
**Prefer a video version? We’ve got you covered!**
Just weeks after the [release of Nx 15.7](/blog/nx-15-7-node-support-angular-lts-lockfile-pruning) (release video [here](https://www.youtube.com/watch?v=IStJODzZSoc)), the Nx team has now launched Nx 15.8, with exciting new features and enhancements aimed at improving developer experience, productivity, and efficiency. Let’s dive straight in.
**Table of Contents**
· [Rustifying the Nx Hasher](#rustifying-the-nx-hasher)
We have the Nx live stream on Thursday, March 9th at 7 PM CET, to talk about all the features that went into Nx 15.7 and 15.8. So tune in to ask your questions :)
Starting with Nx 15.8, we now have a Rust-based Hasher enabled by default!
Performance is at the core of what we do at Nx. Hence it isn’t surprising that Nx is the fastest JS-based monorepo solution out there. We’ve shown [that a couple of times](https://github.com/vsavkin/large-monorepo). But every millisecond counts! As such, we decided to experiment with Rust to see whether we could further optimize our project graph creation as well as the hasher function that is used for the [computation cache](/features/cache-task-results).
Our original implementation used Git to calculate the hash. But it had some downsides as
- it didn’t work if you don’t have or use Git (obviously)
- it didn’t work if you used Git submodules
- it became super slow if you had a lot of file changes on your Git working tree, like when switching between branches
- it triggered a lot of `execSync` calls to get different git status which was a fragile implementation
In some situations where we couldn’t rely on or use the Git hasher, we did a fallback to a node implementation which made things even slower.
**All nice and good, but show me the numbers!**
So we did run some experiments on a small repo:
- avg. time for Rust hasher: 17ms
- avg. time for Git hasher: 24ms
We also tried it on the [Nx repository](https://github.com/nrwl/nx) itself:
- Rust hasher: 50ms
- Git hasher: 69ms
When running these tests on Windows (not WSL), the Nx repo hashing timings turned out to be
- Rust hasher: 72ms
- Git hasher: 330ms
Right now, we only observed the Rust hasher to be slightly slower on large repositories when you don’t have any changes. Once you start making changes the Git hasher becomes slower again and is overtaken by the Rust version which remains stable in performance.
An interesting side-effect of using the Rust-based hasher is the size of the generated hashes, which are much smaller and thus allow for a quicker serialization between the [Nx Daemon](/concepts/nx-daemon) and Nx.
**Future work**
While we started with the hasher optimization, the next implementation we’re exploring is using a binary format to communicate between the Nx Daemon and the Nx client. Currently, we serialize the JSON to a string and pass that through an IPC socket. Using a binary format will significantly speed up the communication here.
**Opting out**
We build the binary for the Rust hasher for:
- macOS x64
- macOS arm
- linux arm
- linux gnu
- linux musl
- windows arm64
- windows x64
As such, it should work on most CI and local developer machines. If we missed something, please reach out an [open an issue on GitHub](https://github.com/nrwl/nx)! In case something breaks though, you can also disable the Rust hasher by using the environment variable `NX_NON_NATIVE_HASHER=true`.
## Deno Support
{% youtube src="https://youtu.be/NpH8cFSp51E" /%}
Nx Deno support [already landed in 15.7](/blog/nx-15-7-node-support-angular-lts-lockfile-pruning), but didn’t make it into the blog post. So here we go: we have a brand new Nx Deno plugin published at `@nrwl/deno`. For now, it is experimental and lives in our [labs repository](https://github.com/nrwl/nx-labs).
This plugin features the ability to generate Deno applications and libraries inside of an Nx workspace. Obviously, all the other much-loved Nx features such as caching, affected commands and the project graph visualization work out of the box as well.
To use Deno in an existing Nx workspace, just install the `@nrwl/deno` plugin:
```
npm i -D @nrwl/deno
```
Then run the generator to create a new application:
```shell
npx nx g @nrwl/deno:app mydenoapp
```
Or generate a new library with:
```shell
npx nx g @nrwl/deno:lib mydenolib
```
We’re excited to see folks welcome in Deno APIs to their Nx workspaces and be able to easily share their Typescript packages across Deno, Node, and web applications, all inside the same monorepo.
Given this is still experimental, we’re more than happy to receive feedback and hear about ways you are using Deno right now and/or plan to use it in an Nx workspace.
To see some of this in action, be sure to check out our [recent livestream with Caleb and Chau](https://youtu.be/Um8xXR54upQ), two of our engineers that have been working on this plugin:
## Nx Console — IntelliJ Support
{% youtube src="https://youtu.be/xUTm6GDqwJM" /%}
Developer tool CLIs are known for being, well, command-line interfaces. Nx comes with many such CLI commands for scaffolding projects, running tasks, and more. We wanted to make some of this more approachable, so we introduced Nx Console, an extension to the Visual Studio Code editor. And it turned out to be highly successful. Nx Console now has over 1.2 million downloads on the [Visual Studio Code marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console). We kept improving it over the years,
- adding support for [rendering the Nx graph](https://youtu.be/ZST_rmhzRXI)
- [providing IntelliSense](https://twitter.com/NxDevTools/status/1573323012476051456) support for Nx configuration files
With the growing popularity, the ask for an equivalent extension for JetBrains’ IntelliJ & WebStorm editors got louder and louder. At Nx, we’re lucky to have an awesome community. [Issam Guissouma](https://twitter.com/iguissouma) and [Edward Tkachev](https://twitter.com/etkachev) from the Nx community jumped in and provided their implementation of Nx Console for IntelliJ.
Since our team [now works full-time on Nx](/blog/from-bootstrapped-to-venture-backed) and the surrounding tooling, we decided to have a dedicated Nx Console extensions for IntelliJ and WebStorm that is actively maintained and developed by the core team. We reached out to Issam and Edward and started collaborating on it. The result can now be installed from the JetBrains marketplace:
Read all the details [on our blog post](/blog/expanding-nx-console-to-jetbrains-ides) or check out our docs page about [integrating with editors](/getting-started/editor-setup).
## Nx Console Field Prioritization (x-priority)
{% youtube src="https://youtu.be/JJ12zKedwIs" /%}
Nx Console has proven a highly valuable tool for exploring Nx generators. Especially if you cannot recall all the various parameters, you can possibly pass. And sure, you could always pass the `--help` or browse [the docs](/nx-api/react/generators/library), but it is just less convenient.
With a growing number of parameters that a generator can take, it started to get messy and overwhelming. Furthermore, in 80% of the cases, you would probably need the main parameters such as the name, bundler, and directory where to generate the output.
This is the main reason we introduced a `x-priority` flag to our generator metadata, to have a way to prioritize certain flags and show them more prominently to the end user. Available values are `important` and `internal`.
The property can be defined for the desired parameters in the generator’s `schema.json`:
```json
{
"directory":{
"description":"The directory of the new application.",
"type":"string",
"x-priority":"important"
}
}
```
All required properties and those marked with an `x-priority: important` will be shown at the top of both, the CLI output (when using `--help`) as well as the Nx Console UI.
Read all about it [in the doc about Customizing Generator Options](/extending-nx/recipes/generator-options).
## Modular Node Applications
Nx has had Node backend support since the beginning, where you could add an [ExpressJS](/nx-api/express) or [Nest.js](/nx-api/nest) based application to your monorepo. This is a powerful approach as it allows you to colocate your frontend and backend code, which helps share code and, in particular, TypeScript types for your APIs!!
In [Nx 15.7](/blog/nx-15-7-node-support-angular-lts-lockfile-pruning), we then announced [Nx Standalone Projects](https://youtu.be/qEaVzh-oBBc) support for Node. This allows to develop a Node backend in isolation but still leverages all the features from Nx in terms of code generators, automated migrations, and speed features such as [affected commands](/ci/features/affected), [caching](/concepts/how-caching-works), and [optimized CI setups](/ci/features/distribute-task-execution).
In 15.8, we kept improving our Node support. Our main focus was on
- allowing to have a non-bundled output, while still being able to modularize the codebase with local libraries
- generating a pruned lock file when building in production mode
- improving our docker setup to account for non-bundled output and properly install node packages
Check out the following video walkthrough on using these features for modularizing a Fastify application:
{% youtube src="https://youtu.be/LHLW0b4fr2w" /%}
## Storybook
Nx now generates stories using [Component Storybook Format 3 (CSF3)](https://storybook.js.org/blog/storybook-csf3-is-here/). If you are using our `@nrwl/react:storybook-configuration`, `@nrwl/angular:storybook-configuration`, `@nrwl/react:stories` and `@nrwl/angular:stories` generators, you will notice that the stories are now generated in the new format. You can check out our documentation for [Storybook and Angular](/recipes/storybook/overview-angular) or [Storybook and React](/recipes/storybook/overview-react) to see the new syntax.
As the Storybook doc mentions, CSF3 _reduces boilerplate code and improves ergonomics. This makes stories more concise, faster to write and easier to maintain._
You can migrate your existing stories in your Nx workspace to CSF3 using the Storybook [`csf-2-to-3` migrator](https://storybook.js.org/blog/storybook-csf3-is-here/#upgrade-to-csf3-today):
At Nx, we are excited to see the JavaScript tooling ecosystem evolve, particularly when it comes to improving speed! Performance is at the core of Nx. Faster tools with which we can integrate make our lives easier and allow us to provide a better experience for developers.
Almost a year ago [ByteDance](https://www.bytedance.com/) started developing a new, faster Webpack alternative: **Rspack**. [Valor Software](https://valor-software.com/) joined the collaboration and reached out to us about developing a dedicated Nx plugin. The goal: give developers an easy onboarding path to Rspack and React!
## Faster than Webpack? What is Rspack?
Rspack is a rewrite of Webpack with the primary goal of improving performance. Rust is the main language, allowing for a highly parallelized architecture that takes full advantage of modern multi-core CPUs. In addition, it also comes with essential bundling features already built-in to avoid further bottlenecks from 3rd-party packages. It also highly optimizes HMR (Hot Module Replacement) using a specialized incremental compilation strategy.
ByteDance developed Rspack to solve performance issues they faced when developing and maintaining their internal monolithic applications, all of which rely heavily on complex Webpack configurations. Rspack being a rewrite allows to rely on Webpack’s mature architecture and is, at the same time, an easy drop-in replacement.
ByteDance already applied Rspack on some of their internal business applications and has seen between 5 to 10x improvement in compilation performance.
More on the official Rspack docs: [https://rspack.dev](https://rspack.dev/)
## Getting up to speed with Rspack & Nx!
Our goal at Nx is to be the best CLI for your framework of choice. We want to remove friction so developers can easily leverage these new tools and focus on shipping features using a production-ready setup. This is why we developed a dedicated Rspack plugin that lets everyone quickly get up to speed.
Check out the following video for a complete walkthrough of how Nx and Rspack work together to create production-ready React applications.
{% youtube src="https://youtu.be/jGTE7xAcg24" /%}
## React Standalone App with Rspack
You can create a new Rspack-based React application using the following command:
This creates a pre-configured setup with React, TypeScript, ESLint, Jest (optionally Vite), Cypress for e2e testing, and obviously Rspack as the bundler.
But not just the “speed features”. All the code generators, automate code migrations, and [code editor extensions](/getting-started/editor-setup) work too.
## Rspack in an Nx Monorepo
Similarly, you can use Rspack-based applications in existing Nx monorepos. Just install the NPM package:
```
npm i @nrwl/rspack -D
```
Then generate a new application:
```shell
npx nx g @nrwl/rspack:app myrspackapp
```
This creates a new application in your Nx monorepo that uses Rspack as the bundler. You can even import existing React libraries, which can also be an excellent way to experiment with Rspack in an existing production setup.
## Wrapping up
Go and learn more on the
- official Rspack website: [https://rspack.dev](https://rspack.dev/)
- learn about the Nx Rspack plugin: [/nx-api/rspack](/nx-api/rspack)
## Learn more
- 🦀 [Rspack and Nx docs](/nx-api/rspack)
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
It has been almost 2 years since we released [Nx Cloud 2.0](https://nx.app/). Since then, it has saved over 400 years of computation by leveraging its distributed caching and task execution. And we keep adding 8 years every single week. Not only does this tremendously [impact our environment](https://dev.to/nx/helping-the-environment-by-saving-two-centuries-of-compute-time-4nep), but it also helps developers be more productive and companies save money.
It has been almost 2 years since we released [Nx Cloud 2.0](/nx-cloud). Since then, it has saved over 400 years of computation by leveraging its distributed caching and task execution. And we keep adding 8 years every single week. Not only does this tremendously [impact our environment](/blog/helping-the-environment-by-saving-two-centuries-of-compute-time), but it also helps developers be more productive and companies save money.
In the last couple of months we have quadrupled the team and have done some amazing things. And we have some big plans for what is coming next. Here’s all you need to know!
@@ -27,7 +27,7 @@ In the last couple of months we have quadrupled the team and have done some amaz
## New, Streamlined UI
This latest release of Nx Cloud comes with a new, streamlined design that offers users a more modern and visually appealing experience. This includes the main [Nx Cloud website](https://nx.app/), where we improved our messaging, including interactive visualizations to better explain some core concepts around remote caching and distributed task execution.
This latest release of Nx Cloud comes with a new, streamlined design that offers users a more modern and visually appealing experience. This includes the main [Nx Cloud website](/nx-cloud), where we improved our messaging, including interactive visualizations to better explain some core concepts around remote caching and distributed task execution.
@@ -90,7 +90,7 @@ Learn more at [enterprise](/enterprise).
Nx Cloud has evolved a lot since we first released it in 2020, and is changing even more in 2023. To better adapt to Nx Cloud being a critical CI tool, we changed our pricing model to be more consistent and predictable for CI workloads.
Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](https://nx.app/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
@@ -100,7 +100,7 @@ Finally, the **Enterprise plan** is for companies that want full control over wh
All these changes should allow developers to choose the plan that best suits their needs and budget more easily, ensuring a seamless and transparent experience regarding pricing and subscription management.
Learn more at [https://nx.app/pricing](https://nx.app/pricing).
Learn more at [/pricing](/pricing).
## Coming Next
@@ -119,4 +119,4 @@ In addition, we are actively exploring ways to provide advanced analytics for yo
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
We’re proud to announce the release of Nx version 16! In this article, we’ll go over the major updates from Nx 16 and the key pieces of information you’ll need to know for the changes that Nx 16 brings!
But before we jump into the new features of Nx 16, let’s recap some of the recent features from our Nx 15 minor releases!
- We introduced simpler presets for React, Angular, and [Node starter applications](https://youtu.be/K4f-fMuAoRY)
- We added official support for [Vite](/nx-api/vite) and Vitest for integrated Nx monorepos
- We introduced an [official Deno plugin](https://youtu.be/NpH8cFSp51E), including integration for Node and Deno project collocation and project graph support for Deno imports
- We added Rust into the Nx codebase to speed up core functionality
- We added support for [non-npm workspaces](https://youtu.be/QOhdL02f6BY) to support workspaces focused on other languages like C#, Java, and Kotlin, and saw some of those in action with community plugins for [.NET](https://www.nx-dotnet.com/) and [Java/Kotlin](https://github.com/tinesoft/nxrocks)
- Introduced [Nx Console for JetBrains IDEs like IntelliJ and WebStorm](https://youtu.be/xUTm6GDqwJM)
- We have [decoupled the Nx version from Angular](https://youtu.be/AQV4WFldwlY) versions allowing you to update Nx without updating Angular
### Table of Contents
· [Here’s how to Upgrade with Nx Migrate](#heres-how-to-upgrade-with-nx-migrate)
· [Rescoping From @nrwl/_ to @nx/_](#rescoping-from-nrwl-to-nx)
· [Deno Standalone Apps, Edge Deployment and More](#deno-standalone-apps-edge-deployment-and-more)
· [The Nx Repo Switches to PNPM for its Package Manager](#the-nx-repo-switches-to-pnpm-for-its-package-manager)
· [Learn more](#learn-more)
## Here’s how to Upgrade with Nx Migrate
As with all new Nx releases, `nx migrate` can be used to bump your Nx packages to the appropriate version, as well as run any necessary changes to your codebase.
To update to Nx 16, run
```
nx migrate latest
```
This will update your dependencies to the latest version, as well as update those dependencies in your root `package.json` file.
If further migrations are available, you’ll see a `migrations.json` file in the root of your workspace. This file will describe any further code generation scripts that should be run. To run these, use the command..
```
nx migrate --run-migrations
```
…as prompted in the terminal.
After the migrations have been run, you should be able to see them in your source control tools. Ensure that everything is still working properly by running any automated testing you have set up.
Check out this real-world example using the `nx migrate` command for the `Tanstack/query` repo:
{% youtube src="https://youtu.be/X1I1Aw2sV-Y" /%}
Also as a reminder to our Angular users — we’ve now **decoupled the Nx version from Angular versions**, so as long as you’re on an LTS version of Angular, you’re clear to migrate to the latest Nx version without having to touch your Angular version! To do so, be sure to use the `interactive` option (e.g. `nx migrate --interactive`). Check out this video for more info:
{% youtube src="https://youtu.be/AQV4WFldwlY" /%}
## Rescoping From @nrwl/_ to @nx/_
{% youtube src="https://youtu.be/HzkvhPKAepA" /%}
One of the more impactful changes from Nx 16 is that we’ll be changing the npm scope that we publish our packages under from `@nrwl` to `@nx`. In other words, `@nrwl/react` will now be published as `@nx/react`.
Nx will handle this migration automatically via the `nx migrate` command to update your workspaces!
To ensure that community plugins are not broken, the `@nrwl/*` versions of these packages are deprecated but will continue to be published until Nx 17 which is scheduled for October 2023.
## Deno Standalone Apps, Edge Deployment and More
Nx has had support for developing Node-based backends for a while. It was a popular choice for building your BFF in a monorepo-based setup alongside your React or Angular application. [In Nx 15.7](/blog/nx-15-7-node-support-angular-lts-lockfile-pruning) we decided to expand that support and really go deep into improving the overall DX.
**Deno got quite some love** in this iteration:
- Standalone App support — You can now scaffold a new single-project Deno workspace with Nx. Just run `npx create-nx-workspace --preset=@nx/deno`. Probably the fastest way to get up and running with Deno
- We also added Nx generators to set up Deno with [oak](https://oakserver.github.io/oak/). Just pass the `--framework` option when you set up a new Deno app (or use [Nx Console](/getting-started/editor-setup))
It’s all about **Edge functions** recently (and, well, serverless in general). Especially when developing with Node it is common that you might want to deploy to the Edge or some serverless environment. Therefore, we..
- created a brand new `@nx/netlify` package (currently [in labs](https://github.com/nrwl/nx-labs/tree/main/packages/netlify)) which allows you to set up a brand new project for developing and pushing Netlify functions, or you can add serverless deployment support to an existing project, using the `@nx/netlify:setup-serverless` generator. Check out our in-depth recipe on the topic: [/recipes/node/node-serverless-functions-netlify](/recipes/node/node-serverless-functions-netlify)
- published anew `@nx/aws-lambda` for deploying [Lambda functions](https://aws.amazon.com/lambda/) to AWS. All details in our latest recipe: [/recipes/node/node-aws-lambda](/recipes/node/node-aws-lambda)
- Improved our existing Deno package to add support for serverless deployment to both Deno Deploy as well as Netlify. Such support can be added to an existing app using the `@nx/deno:setup-serverless` generator and providing the `--platform` flag that either point to `deno-deploy` or `netlify`.
## Cypress Feature Testing
{% youtube src="https://youtu.be/d5i9_Y8Ip54" /%}
Nx sets up e2e tests for apps that tend to collect many features. This ends up as a large atomic suite that Nx isn’t good at separating out. With Nx 16, we’ve made it easier to distribute these tests closer to the actual feature they test. This will make it much easier for `nx affected` to determine which tests are actually necessary.
I also had the opportunity to have a live stream with Nx’s own Caleb (who lead most of the development for this feature), as well as Cypress’s Jordan Powell who also contributed to this effort — check it out:
{% youtube src="https://youtu.be/y3gFRSqarEo" /%}
## Task Graph
Nx 16.0 also introduces more helpful tools for visualizing your project and task graph as determined by Nx:
{% youtube src="https://youtu.be/9_Y6Mop-Kac" /%}
The task graph in particular is helpful for visualizing what actually runs when you run commands, and with Nx 16.0, you can now use the `--graph` option when running most Nx commands to visualize the graph of tasks that would have run - for example:
```
nx build react --graph
```
The task graph was also highlighted in a recent video demonstrating feature parity between our VsCode and JetBrains plugin:
{% youtube src="https://youtu.be/XCoeNiyM6hw" /%}
## The Nx Repo Switches to PNPM for its Package Manager
Internally, the [Nx repo](https://github.com/nrwl/nx) switched to using `pnpm` as its package manager. Since switching we have noted the following advantages:
- publish is 2x faster
- CI times decreased
- install times decreased
While we are using `pnpm` as our package manager, we are not using the `pnpm` workspaces functionality in the Nx repo, but we've found that Nx actually works extremely well with `pnpm` workspace setups. Juri had released [an article on this topic](/blog/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx) previously, and we used this approach to introduce Task Caching and Distributed Caching (via Nx and Nx Cloud) to [the Tanstack/query repo](https://github.com/TanStack/query), which yielded excellent results:
{% youtube src="https://youtu.be/NvPXK6DVZGE" /%}
## Wrapping up!
That’s about it for Nx 16.0 — we’ve really loved the opportunity to bring you all this cool stuff, and we’re eager to start our next iteration with a steady focus on making Nx an awesome tool for increasing your productivity by taking all the repo management tasks out of the equation so you can focus on shipping great stuff.
### Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
The Nx community is too large to be adequately supported by the Nx team alone. Luckily, there are many people who volunteer their time and expertise to help others and share how they use Nx to solve their problems. We are launching the Nx Champions program as a way of acknowledging the work of key members of the community and supporting them in their ongoing efforts.
### What Does Champion Mean?
Champion is both a noun and a verb and the champion in Nx Champions is intended in both ways. Nx Champions have achieved a champion level of knowledge and expertise in some area of Nx. They also champion Nx to the community through content like blog posts, videos and conference talks or by contributing code through plugins or the Nx repo itself. In addition, they champion the ideas of the community back to the Nx team.
### Who are the Nx Champions?
A full list of Nx Champions is available at [/community](/community).
We appreciate everyone who was part of the initial group of Nx Champions, but acknowledge that there are more people who could qualify. If you are interested in joining the program, fill out the [application form](https://forms.gle/wYd9mC3ka64ki96G7) and let’s talk about it.
## Learn more about Nx
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
Today, we will explore how to use `@nx/netlify` serverless functions to determine a user’s location. This can be an incredibly useful feature in various applications, such as customizing user experiences based on their region, displaying localized content, or tracking user demographics for marketing purposes. In this post, we’ll walk you through a step-by-step guide on implementing this functionality using `@nx/netlify` serverless functions.
Before we get started though, here’s a video introduction to the new `@nx/netlify` package:
{% youtube src="https://youtu.be/idH6GCkWq0w" /%}
### Step 1: Set up your Nx workspace with Netlify
To get started, you need to have an Nx workspace. If you haven’t already, create a new Nx workspace by running:
To determine the user’s location, we will leverage the `request.headers` object, specifically the `x-forwarded-for` header containing the user’s IP address. We can then use an IP geolocation API like ipapi ([https://ipapi.co/](https://ipapi.co/)) to fetch location data based on this IP address.
_Note_ in **Node.js 18**, the experimental global fetch API is available by default. If you are using a node version **lower** than **18** you can install `node-fetch` to handle API requests:
```
npm install node-fetch
```
Now, update the `user-location.ts` file with the following code:
```
import { Handler } from "@netlify/functions";
import fetch from "node-fetch"; // Can be removed if node >= 18
return { statusCode: 500, body: `Error fetching user location` };
}
};
```
### Step 4: Deploy your serverless function
When we created our workspace, the initial scaffolding generated a **deploy-target** inside our `project.json`.
> A **target** is a specific task you can run for a project.
> You can think of it as a script/command that does a specific job. The most common targets are “build”, “serve”, “test”, “lint”, “deploy”, etc. For more information regarding `project.json` you can read about it at [project-configuration](/reference/project-configuration)
We can start off by creating our site on Netlify by running:
```shell
npx netlify init
```
After you have answered all the prompts your site should be created. A `.netlify` folder should be created with references to your newly created site.
Now, to deploy your serverless function run:
```
nx run deploy
```
Finally, navigate to your Netlify site’s Functions tab, and you should see your `user-location` function deployed and ready to use!
For example, ours can be found at: [https://644a9b17d0299b00b581b33f--find-user-location.netlify.app/.netlify/functions/user-location](https://644a9b17d0299b00b581b33f--find-user-location.netlify.app/.netlify/functions/user-location)
The JavaScript ecosystem evolves at a rapid pace, frequently introducing new tools and packages. At Nx, we provide out-of-the-box integrations with the most popular among them so you don’t have to worry when stitching them together. That, however…yes you guessed it… can be a challenging task. There’s just one way to keep up: automation.
We already run a ton of automated testing on our repository to ensure we don’t break anything. But given Nx’s popularity and vast usage across open source and enterprise projects, we want to go a step further: introducing the [Nx Ecosystem CI](https://github.com/nrwl/nx-ecosystem-ci). Inspired by the work done by our friends on the [Vite](https://vitejs.dev/) team, the [Nx Ecosystem CI](https://github.com/nrwl/nx-ecosystem-ci) is designed to enhance the stability of Nx by testing pre-release versions with projects in the Nx ecosystem.
### Inspired by the Vite Ecosystem CI
The [Vite Ecosystem CI](https://github.com/vitejs/vite-ecosystem-ci) is an innovative tool that has significantly enhanced the use of [Vite](https://vitejs.dev/). It monitors the compatibility of Vite with various other packages and projects in the ecosystem by running tests against the latest changes in the Vite codebase and the projects it integrates with. This allows the Vite team to catch issues early and maintain a high level of stability, ensuring that developers using Vite can trust that new contributions to either Vite or their project will not result in breaking changes.
This robust testing system is essential because it gives users confidence in Vite’s reliability, encouraging more developers to adopt Vite. It’s a great example of proactive testing in a fast-paced ecosystem and an inspiration for other projects, including Nx. The concept of the Ecosystem CI introduces a framework-agnostic way of testing integrations of one tool with other tools in the ecosystem. It puts together a “syntax” with which tools can easily find the way to test their latest versions with one another.
### Nx Ecosystem CI
The [Nx Ecosystem CI](https://github.com/nrwl/nx-ecosystem-ci) is a fork of the [Vite Ecosystem CI](https://github.com/vitejs/vite-ecosystem-ci) but is tailored specifically for the Nx ecosystem. It’s designed to ensure that Nx maintains its high standards of reliability and compatibility with all our users.
### How Nx Ecosystem CI Works
The Nx Ecosystem CI works in the following way:
1. It clones the provided repo which uses Nx
2. It installs the project’s dependencies
3. It runs a number of scripts specified by the project’s author (eg. `test`, `build`, `e2e`)
4. It migrates the repository to the `next` version of Nx (using `nx migrate next`)
5. It runs the scripts again
6. It reports the results of the runs to the [Nx Official Discord Server](https://go.nx.dev/community)
in the `#ecosystem-ci` channel.
The main difference between the Nx Ecosystem CI and the Vite Ecosystem CI is that Nx Ecosystem CI uses the \`next\` version of Nx as published on npm, rather than cloning and building Nx locally, like Vite does in the Vite Ecosystem CI. This approach ensures that the tests run against the same code that developers are most likely to use in their projects. It also makes it easier for the script to migrate to that version.
At its core, the Nx Ecosystem CI is a set of command-line tools that run tests for a specific or all available suites. Each test suite corresponds to a specific configuration and consists of a set of commands executed in a given repository. The test suite checks for the correct execution of Nx commands, such as build, test, and e2e tests, ensuring that Nx functions as expected in different environments and projects.
### Adding a new test suite
To add a new test suite for your project in the Nx Ecosystem CI, you would need to create a new file under the tests directory. The name of this file should reflect the suite it represents, for example, [`nx-rspack.ts`](https://github.com/nrwl/nx-ecosystem-ci/blob/main/tests/nx-rspack.ts) .
The first step is to import the necessary modules and types from `utils.ts` and `types.ts` at the top of your file:
```typescript
import{runInRepo}from'../utils';
import{RunOptions}from'../types';
```
`RunOptions` is a type that represents the options for running a test suite. It includes properties such as the repository to test, the branch to use, and the commands to run for building, testing, and performing e2e tests (all optional).
Next, you need to define the `test` function that accepts the `RunOptions`. Within this function, you’ll call the `runInRepo` function, passing in the options as well as any specific properties required for your suite:
Again, using the example of `nx-rspack`:
```
export async function test(options: RunOptions) {
await runInRepo({
…options,
repo: 'nrwl/nx-labs',
branch: 'main',
build: ['build rspack'],
test: ['test rspack'],
e2e: ['e2e rspack-e2e'],
})
}
```
In this example, the suite is set up to run on the ‘nrwl/nx-labs’ repository on the `main` branch. It will run `build rspack`, `test rspack`, and `e2e rspack-e2e` as its build, test, and e2e tests respectively. These commands will be invoked using the package manager used by your repository. So, in the `nx-labs` case, it will run `yarn build rspack` in the `nrwl/nx-labs` repo.
For this reason, adding a new test suite to the Nx Ecosystem CI also requires setting up appropriate `scripts` in your repository’s `package.json` file. These scripts provide the commands that will be invoked by your package manager to carry out the `build`, `test`, and `e2e` steps.
Here’s an example of how scripts might be configured in a package.json file for a repository using Nx:
```
"scripts": {
…
"build": "nx build",
"test": "nx test",
"e2e": "nx e2e"
…
},
```
These scripts should be set up in such a way that they can be invoked directly by your package manager. For example, in a repository using `pnpm`, you could run the build script with the command `pnpm run build`.
When you create your test suite file, you’ll specify these script names in the `build`, `test`, and `e2e` properties of the `options` object passed to `runInRepo`.
```
export async function test(options: RunOptions) {
await runInRepo({
…options,
repo: 'nrwl/nx-labs',
branch: 'main',
build: ['build'],
test: ['test'],
e2e: ['e2e'],
})
}
```
With this setup, the Nx Ecosystem CI will run these scripts in your repository as part of its CI process, or just when you run `pnpm test <name-of-suite>` locally.
In addition to creating the test suite and setting up the package.json scripts, you will also need to add the name of the new suite to the workflow configuration files in the `.github/workflows` directory of the Nx Ecosystem CI repository. This suite name should match the filename of your test suite script.
There are two workflow files you’ll need to update:
-`.github/workflows/ecosystem-ci-selected.yml`
-`.github/workflows/ecosystem-ci.yml`
In `.github/workflows/ecosystem-ci.yml` you’ll find a strategy section with a `matrix` property. This `matrix` property specifies an array of suite names for the workflow to run. You’ll need to add your new suite name to this array.
Here’s what the strategy section might look like after adding a new suite named `my-new-suite`:
```
strategy:
matrix:
suite:
- ….
- nx-remix
- nx-rspack
- …
- my-new-suite # your new suite
```
By adding your suite name to this file, you’re instructing the Nx Ecosystem CI to include your suite in its test runs.
In addition to the `.github/workflows/ecosystem-ci.yml` file, you also need to include your suite in the `.github/workflows/ecosystem-ci-selected.yml` file.
The `ecosystem-ci-selected.yml` workflow is designed to allow manual selection of a test suite to run. To add a suite to this workflow, you add it to the options array under `workflow_dispatch > inputs > suite`. Here’s what it might look like with a new suite named `my-new-suite`:
```
on:
workflow_dispatch:
inputs:
suite:
description: "testsuite to run"
required: true
type: choice
options:
- ….
- nx-remix
- nx-rspack
- …
- my-new-suite # your new suite
```
Adding your suite name to this file allows it to be manually selected for a test run via the GitHub Actions interface. This manual selection process provides additional flexibility and control over the testing process, allowing you to run individual suites as needed.
### Reporting the results
The Nx Ecosystem CI is integrated with GitHub Actions, which helps with its automation process. The CI pipeline is scheduled to run three times a week (on Mondays, Wednesdays, and Fridays) and can also be triggered manually. The workflow uses a matrix strategy to run the suites in parallel. Each suite is given a big amount of memory, and the pipeline is configured with a long timeout, meaning that even if one suite encounters an error, the rest will continue to run. This ensures that we get comprehensive feedback on the health of all the test suites, regardless of individual failures. Once the test suites run, Github sends a message to the [Nx Official Discord Server](https://go.nx.dev/community)
`#ecosystem-ci` channel with the status of each suite, enabling the team and the community to view the results. Each result points to the Nx tag that was used, and also the job logs on GitHub.
The introduction of the Nx Ecosystem CI is a significant win for both the Nx team and the Nx developer community. For us, it enables us to catch issues early, often before they affect most end-users. By running tests against the \`next\` version of Nx, we can ensure that any changes we make are compatible with the various configurations that our users maintain.
For developers using Nx, the Nx Ecosystem CI offers reassurance that the tools they rely on are being actively tested and maintained. This provides confidence in the stability of Nx and its plugins.
### Ecosystem CI as part of the Open Source community
We are not alone in recognizing the value of an Ecosystem CI approach. Other OSS projects including Nuxt, VueJs, VolarJs, and Rspack, have also adopted this strategy. You can explore their implementations here:
As we continue to improve and refine the Nx Ecosystem CI, we remain committed to the goal of making Nx a reliable and integral part of your development workflow. If you’re an open-source maintainer, you can create your own Ecosystem CI either from scratch (like Storybook) or by cloning the Vite Ecosystem CI. If your project uses Nx, you can easily add a new test suite for it.
## Learn more
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
@@ -26,11 +26,11 @@ If you’re curious to learn more about the rewrite and the motivations behind i
### A Short History of Nx Console
Let’s go back in time: Nx Console has been around for a while. [It first launched in 2018](https://blog.nrwl.io/announcing-the-first-stable-release-of-angular-console-the-ui-for-the-angular-cli-bb19093a92d4?source=friends_link&sk=d955094b2cb872a130b47c8040ec820e) — then called Angular Console — as a standalone Electron app which let you run Angular schematics and builders from a graphical interface. Of course, it was built with Angular and looked something like this:
Let’s go back in time: Nx Console has been around for a while. It first launched in 2018 — then called Angular Console — as a standalone Electron app which let you run Angular schematics and builders from a graphical interface. Of course, it was built with Angular and looked something like this:
In 2019, [it was ported to a VSCode extension](https://blog.nrwl.io/brand-new-ui-custom-vscode-task-support-more-in-angular-console-9-0-5e4d3a109fb9?source=friends_link&sk=47fd72d5700b4cb3de09e559c5524ce5) with the now familiar UI and support for the standalone app was dropped.
In 2019, it was ported to a VSCode extension with the now familiar UI and support for the standalone app was dropped.
In 2020, support for the entire Nx ecosystem was added, it was renamed to Nx Console and an amazing transformation began: Today, Nx Console is much more than just a single form — it tightly integrates Nx into your IDE, gives you the overview of your projects that you need and puts your task-running just a click away.
@@ -44,7 +44,7 @@ In addition, we started questioning our usage of Angular. Angular is a great fra
So, ultimately, **we decided to pull the plug and rewrite the entire thing in [Lit](https://lit.dev/).**
Lit is a lightweight framework built on top of web components and “adds just what you need to be happy and productive: reactivity, declarative templates and a handful of thoughtful features to reduce boilerplate and make your job easier” (taken from their docs). We had used it before to [build the Nx Cloud view](https://blog.nrwl.io/nx-console-meets-nx-cloud-d45dc099dc5d?source=friends_link&sk=90215eb316ef332c1324f2d50cd3ad85) and were happy with the simple setup and great DX. So the decision to reuse it here was an easy one, since it allowed us to reuse code, build tooling and expertise. The rewrite also gave us the opportunity to improve the design for both supported IDEs and give the entire UI a clean, new coat of paint.
Lit is a lightweight framework built on top of web components and “adds just what you need to be happy and productive: reactivity, declarative templates and a handful of thoughtful features to reduce boilerplate and make your job easier” (taken from their docs). We had used it before to [build the Nx Cloud view](/blog/nx-console-meets-nx-cloud) and were happy with the simple setup and great DX. So the decision to reuse it here was an easy one, since it allowed us to reuse code, build tooling and expertise. The rewrite also gave us the opportunity to improve the design for both supported IDEs and give the entire UI a clean, new coat of paint.
@@ -62,7 +62,7 @@ This architecture’s modularity meant we could quickly switch out the Generate
If you want to dive deeper, there are many more resources on the architecture of Nx Console and how it’s built:
- [In-depth blog post about expanding to JetBrains IDEs](https://blog.nrwl.io/expanding-nx-console-to-jetbrains-ides-8a5b80fff2d7?source=friends_link&sk=967080ea30bdbf9f8132f098a2cdd188)
- [In-depth blog post about expanding to JetBrains IDEs](/blog/expanding-nx-console-to-jetbrains-ides)
- [Accompanying Youtube video by Zack DeRose](https://www.youtube.com/watch?v=xUTm6GDqwJM)
- [The Power of Nx Console — talk by Jon Cammisuli](https://www.youtube.com/watch?v=3C_9g9kt2KM)
@@ -70,7 +70,7 @@ If you want to dive deeper, there are many more resources on the architecture of
To rebuild our UI, we first needed a new Lit app to work on. While there’s no native Nx plugin for Lit, generating the code we need was still very straightforward:
`nx generate @nx/web:app --name generate-ui-v2`
`nx generate @nx/web:app apps/generate-ui-v2`
This generates an entire project for us, with a `tsconfig.json`, `index.html`, `main.ts`, and a `project.json`, where our Nx-specific config lives.
@@ -131,7 +131,7 @@ If you need to pass information up the DOM, you use normal events and you can se
### Communicating with the IDE — using Reactive Controllers
To communicate with the host IDE, we were able to reuse almost all the logic from the previous UI (for more details, see [Communicating with IntelliJ](https://blog.nrwl.io/expanding-nx-console-to-jetbrains-ides-8a5b80fff2d7?source=friends_link&sk=967080ea30bdbf9f8132f098a2cdd188#d151) from the last blog post). Instead of a service that exposes observables that our component can consume, we used a [Reactive Controller](https://lit.dev/docs/composition/controllers/). Controllers are a neat feature of Lit — they hook into a component and can request DOM updates on their behalf. This eliminates the need for observable streams and subscriptions while keeping the communication code self-contained. Look at this example:
To communicate with the host IDE, we were able to reuse almost all the logic from the previous UI (for more details, see [Communicating with IntelliJ](/blog/expanding-nx-console-to-jetbrains-ides) from the last blog post). Instead of a service that exposes observables that our component can consume, we used a [Reactive Controller](https://lit.dev/docs/composition/controllers/). Controllers are a neat feature of Lit — they hook into a component and can request DOM updates on their behalf. This eliminates the need for observable streams and subscriptions while keeping the communication code self-contained. Look at this example:
```ts {% fileName="main.ts" %}
@customElement('root-element')
@@ -294,11 +294,7 @@ As mentioned earlier, Angular comes with a lot more features out-of-the-box than
We were able to reduce the bundle size (w/o compression) from about 733 kB to 282 kB, which comes out to about a 2,6x decrease. Unlike a website, where the bundle needs to be shipped to users when they load a page, Nx Console users only need to download it once when installing the plugin. This means we’re not affected by network speeds after installation, which makes the bundle size less critical.
> 💡 Because of a misconfiguration from a few Angular versions ago, the bundle size that we reported in:
was overly bloated. We corrected it, but Lit still came out ahead in terms of size and rendering times.
> 💡 Because of a misconfiguration from a few Angular versions ago, the bundle size that we reported in [this tweet](https://twitter.com/MaxKless/status/1671095858182381569) was overly bloated. We corrected it, but Lit still came out ahead in terms of size and rendering times.
### Build Time
@@ -335,4 +331,4 @@ If the prettier UI and better performance haven’t convinced you, this surely w
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
We have launched SO MANY features since our last release blog on Nx 16.0, so we’re covering the major features in this blog!
{% youtube src="https://youtu.be/7XLoLOc3afY" /%}
Be sure to mark your calendars for our Nx 16.5 livestream as well! We’ll highlight the features you see here AND field any questions live! Follow the link to schedule a notification for when we go live:
{% youtube src="https://youtu.be/EYgkKmYbRNI" /%}
## Targetting Tasks By Tags
Our first major feature actually comes to us from the community. Nx has supported a tags property in your project.json file for awhile now — and it’s main purpose has been to be used in conjuncture with the [Nx Module Boundary lint rule](/features/enforce-module-boundaries) to define which projects in your Nx workspace can depend on what — for example, you don’t want your frontend applications to depend on any backend-specific code.
With this new feature, you can add the `--tag` option to the [`nx affected`](/nx-api/nx/documents/affected) and [`nx run-many`](/nx-api/nx/documents/run-many) commands to specify to Nx to only run commands for projects that match the given tags.
{% youtube src="https://youtu.be/enQDQmFquGU" /%}
## NextJS 13 Support
React Server Components and the new NextJS app router are here, and Nx is here to support them. We’ve added support for the latest versions of Next — complete with generators and executors. We’ve also made sure that our [`withNx` NextJS plugin](/recipes/next/next-config-setup), which allows you to import from your other projects in your workspace while still working with the NextJS build scripts, works both for workspaces using our executors in an Integrated Monorepo approach, as well as for those using a Package-Based approach that are simply using the `next dev` command directly to start their dev server.
There’s also built-in support for the new turbopack builder option via the `--turbo` command, for example: `nx serve webapp --turbo`
We’ve also launched a new preset for `npx create-nx-workpace` for a standalone NextJS app. Checkout it out using the command: `npx create-nx-workspace@latest --preset=nextjs-standalone` or use the interactive prompts to find it:
We’ve added a couple videos specifically on Next development in an Nx workspace in the past month, so if you’re looking for more on Next, be sure to check them out!
{% youtube src="https://youtu.be/RupxGAQ3fBY" /%}
{% youtube src="https://youtu.be/X3WfXAZZH7s" /%}
## New Nx Recipes!!!
Did you know that we maintain [a set of Nx workspaces](https://github.com/nrwl/nx-recipes) designed to serve as examples for different Nx Workspaces?
We’ve recently added examples repos for:
- fastify + mongo
- fastify + postgres
- fastify + redis
- nextjs + trpc
- remix
- serverless + fastify + planetscale
Go check it out at [https://github.com/nrwl/nx-recipes](https://github.com/nrwl/nx-recipes) and let us know in the comments if there are more recipes you’d like to see or if you want to see videos made from any of the existing recipes!
## Angular 16 Support And Migrations
Angular is continuing their pattern of releasing new and exciting features — and in Nx 16.1, we added support for Angular 16, including updates to our NgRx generators and cypress support.
As usual, we provide migrations to the most recent Angular version to cover your codebase for any breaking changes going to Angular 16.
And in case you missed it, Nx is no longer tied to your Angular version — the most recent version of Nx will now always [support all currently LTS versions of Angular](/nx-api/angular/documents/angular-nx-version-matrix), meaning you DON’T have to upgrade your Angular version in order to get all these latest Nx Features. Be sure to use the `--interactive` flag to take advantage of this feature: `nx migrate latest --interactive`. You can find more details in [our docs for choosing optional packages to apply](/recipes/tips-n-tricks/advanced-update).
{% youtube src="https://youtu.be/AQV4WFldwlY" /%}
## New `verdaccio` support!
The `@nx/js` package now includes a new `setup-verdaccio` generator as well as a `verdaccio` executor!
{% youtube src="https://youtu.be/t1c925TzrzE" /%}
Running `nx g setup-verdaccio` will now add a new `local-registry` target to your workspace, that will use the new `verdaccio` executor.
To start your local registry, run the command `nx local-registry` in one terminal, and then you can publish via commands like `npm publish` as you normally would, but rather than publish packages to the npm registry, this will only publish those packages to your locally-running registry!
While the `local-registry` process is running, you will also be able to install packages published to your local registry as well.
These tools should help in particular with local testing of publishing packages to help support both manual and automated testing!
## Create your own CLI with Nx
The use of command-line interfaces (CLIs) to create new workspaces is common in various technologies. React has one, so does Angular, Vue, Vite and many more. Maintaining a good CLI experience can be tedious though, especially because framework authors would rather want to focus on the library or framework itself.
For a while now, Nx plugin authors had the possibility to create a so-called “preset” to control the entire Nx workspace structure. Once published it can be invoked by using the `--preset` flag:`npx create-nx-workspace myapp --preset=@my/plugin`. [Qwik-Nx](https://github.com/qwikifiers/qwik-nx) is an example of that.
However, many authors would rather want to have a more “branded” experience. Like being able to invoke the previous example as follows:
```shell
npx create-qwik-nx myapp
```
To fulfill this need, in 16.5 we ship with a new `create-package` generator that allows you to add and ship such "CLI package" with your Nx plugin.
You can either create a new Nx plugin workspace immediately with a CLI package using:
Or alternatively add it to an existing Nx plugin workspace using:
```
nx g @nx/plugin:create-package <cli name> --project=<existing plugin name> --e2eProject e2e
```
## New `externalDependencies` Input Type
Nx now supports a new input type: `externalDependencies` to add to the existing input types: `filesets`, `runtime` inputs, and `env` variables.
By default, Nx will take the defensive stance of assuming that all packages will affect your commands, meaning all external dependencies are taken into account when hashing your task’s dependencies.
The new `externalDependencies` input type allows you to specify a specific set of external dependencies for a given command, so you can configure your tasks to more accurately reflect their inputs.
For example, if you have a `publish-package` target that is using a `command` of `lerna publish` for your publishing, you can specify that the only external dependency for that specific input is `lerna`:
```json
{
"name":"mylib",
// ...
"targets":{
"publish-package":{
"command":"lerna publish",
"inputs":[{"externalDependencies":["lerna"]}]
}
}
}
```
This way you are free to change other dependencies that don’t affect this task without invalidating your cached run of the task.
{% youtube src="https://youtu.be/FRqgWBmHmAU" /%}
## New `@nx/dependency-checks` EsLint Rule
We’ve added a new `@nx/dependency-checks` lint rule to help with detecting any issues when specifying dependencies for your packages.
This rule will analyze your source code to determine any dependencies you are using in this specific package, and will catch any missing dependencies, mismatched versions, and unused dependencies in your project’s `package.json` file.
Even better, this rule supports the `--fix` option to automatically fix any issues that are found - making it a great tool for automating your dependencies.
After migrating your Nx workspace, you should have access to this lint rule. To turn it on, you’ll need to adjust the `lint` targets in your `project.json` files to include your `package.json` files like so:
```json
{
"name":"webapp",
// ...
"targets":{
// ...
"lint":{
"executor":"@nx/linter:eslint",
"outputs":["{options.outputFile}"],
"options":{
"lintFilePatterns":[
"apps/webapp/**/*.{ts,tsx,js,jsx}",
"apps/webapp/package.json"// here!
]
}
}
}
}
```
Then in “webapp” project’s `.eslintrc.json` file you'll want to turn the rule on for your json files:
```json
{
...
"overrides":[
// ...
{
"files":["*.json"],
"parser":"jsonc-eslint-parser",
"rules":{
"@nx/dependency-checks":"error"
}
}
]
}
```
Now you should be able to run the linter via `nx run-many --target=lint` to catch any errors across any of your packages, and you can `nx run-many --target=lint --fix` to automatically fix all errors as well.
## Nx Goes Brrrrrr
Nx has continued to get faster!
Our biggest speed increase has come from moving our task hashing into the Nx Daemon. A daemon process refers to a process that runs continuously in the background.
Because the daemon persists between command runs, we are able to have more of the work that goes into hashing a task cached, which we added in Nx 16.3!
In Nx 16.4 we also moved to a rust-based watcher to further improve performance. We had already began the migration of some of the more performance-intensive computation of Nx to Rust in prior version, but we’re excited to bring more of the core of Nx into Rust and see more of these performance gains!
Since our last benchmarking of Nx in October of last year where we clocked Nx at 276.2ms per command, these speed boosts have now gotten us down to 149.3ms, nearly doubling our speed!!
You can see our results and the details of the benchmark — and even run the benchmarks for yourself in [this repo](https://github.com/vsavkin/large-monorepo).
## Nx Console Revamped
Nx Console got a new coat of paint in both the VsCode and JetBrains (IntelliJ/Webstorm) IDEs!
As part of the redesign, we also moved our webviews to the Lit framework — checkout all the latest updates in this video:
{% youtube src="https://youtu.be/p455D4W7330" /%}
## Nx Changelog Launched
Last but CERTAINLY not least, we’ve launched [a new changelog](/changelog) to our docs site!
This changelog includes links to all the release notes for all major and minor versions, as well as links to patch versions. We made sure to also include any deprecations or breaking changes brought about by each version as well.
## Wrap Up
That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to [our YouTube channel](https://youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
As developers we always want to use the latest shiny tools. There’s a new bundler? Let’s try! A new code editor, I’m in! For your side-project: for sure! At work: nah, not really. Keeping your tooling up to date with the rather fast moving JS ecosystem can be a major challenge. Nx provides a mechanism that can help mitigate that, by providing a command to upgrade your tooling automatically:
You can run the following command to automatically upgrade your Nx workspace to the latest version:
```shell
npx nx migrate latest
```
## The Balancing Act: Updating Tooling vs Shipping Features
If you’re anything like me, you’ve probably found that discussions about updating tooling tend to fall to the bottom of the priority list when talking to your product owner. It’s understandable — their primary goal is to ship features. However, sticking with outdated tooling can impact our ability to deliver these features swiftly (not to speak about potential security concerns due to outdated libraries).
Don’t get me wrong, I’m not suggesting that we should always be on the bleeding edge of technological innovation — especially in an enterprise environment.
> _Jason Lengstorf has some opinions there as well:_ [_“The Hidden Danger of Switching Tech Stacks in 2023_](https://youtu.be/u0j-DlsimZ4)_?)._
It’s wise to let security patches land and initial bugs get fixed before jumping on the upgrade bandwagon. But here’s the catch — don’t wait too long. The **longer you delay upgrading, the more challenging and time-consuming** it becomes. And the more effort it requires, the harder it is to sell the idea to your product owner.
## The Key: Making Updates Easy(ier)!
Updating tooling is never easy, but the Nx team aims at making it “easier” at least. We try to embrace the concept of “evergreen tooling”, a strategy that’s been around since Google decided to automatically update Chrome for all users. The Angular team adopted this approach for their Angular CLI, and Nx has followed suit. But what exactly is it, and how does it work?
> _What if I told you Nx users have been_ **_automatically_** _updating their React applications from Webpack 4 to Webpack 5!_
The “why” is pretty straightforward. From the perspective of an open-source project, you want users to adopt the latest version as quickly as possible. This minimizes the maintenance work involved in supporting older versions, which can be a real headache. Looking at how Nx manages it, it seems to be successful in this regard ([Source](https://www.craigory.dev/npm-burst/?package=nx)):
The distribution of Nx installs by version demonstrates the effectiveness of this approach. For instance, v16.5, which accounts for 19.7% of all versions, has already been adopted by many users, despite [its recent release](/changelog). The latest major accounts for 34.7% already and 41.4% are on the previous v15, a large majority of which is on the latest 15.9 minor. Hence, v16 & v15 make up 3/4 of all Nx installs.
## How? Database Migration Scripts for Code?
If you know what “database migration scripts” are, then yes, it’s the same concept but applied at the code level. A series of small functions invoked to bring your workspace from version X to version Y (usually the latest). That includes:
- update `nx` itself
- update all Nx plugins and the technology they are responsible for (for example: `@nx/react` will upgrade React as well, `@nx/webpack` is upgrading Webpack)
Everything that is required to get you to the latest version and still have a running code, even if there have been breaking changes.
**How?!** Because the **Nx team (and plugin authors) do the work for you**! Nx has a built-in mechanism where you can define so-called “migrations” for each Nx package. Here’s an excerpt of the `@nx/webpack`'s migration file.
They are defined in a `migrations.json` config file within the NPM package. Each entry defines a `version` for which the entry should be run, a `description` (just for humans to read) and a `factory` property which points to a TypeScript file.
Example: if you’re on Nx 15.5 and you run `nx migrate latest` it would run the corresponding “factory functions” for:
-`webpack-config-setup`
-`add-babelUpwardRootMode-flag`
-`update-16-0-0-add-nx-packages`
Depending on the nature of the update, these functions can be as simple as performing text replacements to more complex AST parsing and TypeScript source file manipulations. Let’s have a look at the `add-babelUpwardRootMode-flag` migration:
```
import {
formatFiles,
readProjectConfiguration,
Tree,
updateProjectConfiguration,
} from '@nx/devkit';
import { forEachExecutorOptions } from '@nx/devkit/src/generators/executor-options-utils';
import { WebpackExecutorOptions } from '../../executors/webpack/schema';
It leverages the utility functions provided by the `@nx/devkit` package to read the various `projects.json` files to adjust the `babelupwardRootMode` property.
Nx’s modular design helps as each plugin is responsible for a particular area and can thus contribute according migration scripts. To give you some context. There is the [nx package](https://www.npmjs.com/package/nx) at the core — which you can use nicely in combination with a [PNPM workspaces repo](/blog/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx) to speed things up — and then there are plugins built on top.
These plugins are usually technology-specific, like a plugin to help you manage React, Next, Remix, or Angular projects and tooling like ESLint, Cypress, Playwright, Vite, Jest, and so on. There are no limits as you can [create your own](/extending-nx/intro/getting-started). They are **optional**, in that you can use Nx and React and set everything up on your own. But it might be worth relying on them for some better DX and automation, such as the update mechanism we’re currently looking at.
Plugins are helpful here, because each plugin has a clearly defined responsibility. Like the `@nx/webpack` we looked at earlier, handles everything related to Webpack. So it’ll be responsible for updating the `webpack` NPM package and adjusting config Webpack-related files.
## Performing the Update
Alright, we’ve learned how these updates work behind the scenes. Let’s look at what the experience looks like as a developer performing the update on your codebase.
> _Note, it is highly recommended to start with a clean Git workspace s.t. you can quickly revert the update._
To run the update, use the following command:
```shell
npx nx migrate latest
```
Note `latest` stands for the target version. You can also provide a specific Nx version if you cannot update to the latest one for some reason.
At this point, Nx
- analyzes your workspace and finds all the plugins you’re using
- downloads the version of the plugins specified in the migrate command above
- collects all the `migration.json` files from these plugins
- picks out the relevant ones based on your current workspace version
- creates a `migrations.json` at the root of your workspace
- updates the `package.json` to point to the matching NPM package versions (without performing an install just yet)
You can now inspect the `migration.json` and the `package.json` before you run the following command to run the migrations on your codebase.
```shell
npx nx migrate —-run-migrations
```
After that, your codebase should have been updated. Run your (ideally automated) sanity checks and fix the remaining issues that couldn’t be adjusted automatically.
## Wrapping Up
That’s it! If you want to dive deeper, here are some potentially helpful links:
- [Watch our YT video about Code Migrations](https://youtu.be/Ss6MfcXi0jE)
In Nx 16.6 we are introducing our new generators for [Storybook interaction tests](https://storybook.js.org/docs/react/writing-tests/interaction-testing)! These new generators replace the default Cypress tests we used to generate along with a project’s Storybook configuration, particularly for those already using Storybook. The intention is that if a user chooses to use Storybook and generate Storybook configuration, to integrate in that experience Storybook Interaction testing, and skip generating Cypress tests, to keep everything in one place, in an integrated experience.
**Prefer a video walkthrough? We’ve got you covered**
Interaction tests allow users to verify the functional aspects of UIs. This is done by supplying the initial state of a component, simulating user behavior such as clicks and form entries, and finally checking if the UI and component state update correctly. Very much like e2e tests are doing.
In Storybook, this workflow occurs in your browser, which makes it easier to debug failures since you’re running tests in the same environment you develop components.
## How it works
You write a story to set up the component’s initial state, simulate user behavior using the [play function](https://storybook.js.org/docs/react/writing-stories/play-function), and then use the [test runner](https://storybook.js.org/docs/react/writing-tests/test-runner) to confirm that the component renders correctly and that your interaction tests with the play function pass. [Storybook’s Test runner](https://storybook.js.org/docs/react/writing-tests/test-runner) is a standalone utility — powered by Jest and Playwright — that executes all of your interaction tests, and runs parallel to your Storybook.
## Setting Up Storybook Interaction Tests on Nx
You can read our detailed guide on how to set up Storybook interaction tests on Nx, here: [/recipes/storybook/storybook-interaction-tests](/recipes/storybook/storybook-interaction-tests).
## Writing Interaction Tests in Storybook
An interaction test is defined inside a play function connected to a story. The story simulates the user’s behavior once it loads in the UI and verifies the underlying logic.
Under the hood, Storybook’s [@storybook/addon-interactions](https://storybook.js.org/addons/@storybook/addon-interactions) mirrors [Testing Library](https://testing-library.com/)’s user-events API. So, you can use the same queries and assertions that you would use for Testing Library, like we already do with our unit tests.
For complex flows, it can be worthwhile to group sets of related interactions using the step function. This allows you to provide a custom label that describes a set of interactions.
## Debugging and Reproducing Errors
Storybook provides an interactive debugger that displays the step-by-step flow of your interactions, and provides UI controls to pause, resume, rewind, and step through each interaction.
If an error occurs during a story’s play function, it’ll be shown in the interaction addon panel to help with debugging. And since Storybook is a web app, anyone with the URL can reproduce the error with the same detailed information without any additional environment configuration or tooling required.
## Executing and Automating Tests
Storybook only runs the interaction test when you’re viewing a story. Therefore, as a Storybook grows, it becomes unrealistic to review each change manually. The Storybook test-runner automates the process by running all tests for you. This can be executed via the command line or on CI environment.
## What should I choose? Interaction tests or E2E tests?
Setting up interaction tests with Nx and Storybook provides an extra layer of confidence in the functionality of your components. It ensures that they not only look right but also behave correctly in response to user interactions.
Storybook interaction tests provide a unique advantage over traditional e2e tests, especially when considering the development setup. With Storybook already in place, you essentially have a controlled environment set up for each of your components. This allows you to write interaction tests almost immediately, without the overhead of setting up and navigating through a full application environment, as is the case with e2e tests.
Moreover, since Storybook isolates each component, you can ensure that the tests are solely focused on individual component behavior rather than application-level concerns. This results in faster test execution, easier debugging, and more granular feedback during the development process. In essence, with Storybook’s interaction tests, you get many of the benefits of e2e tests but with a setup that’s quicker, more focused, and integrated right into your component development workflow.
Most technologies have a CLI to create a new workspace. In fact, it is so prevalent that NPM and other package managers support it natively. For example:
- Nx has [create-nx-workspace](/getting-started/installation)
- React has, well, had [create-react-app](https://create-react-app.dev/)
- Angular has [Angular CLI](https://angular.io/cli)
- Vite has [create-vite](https://vitejs.dev/guide/#scaffolding-your-first-vite-project)
Having a CLI to quickly scaffold a starting project is great for onboarding new people, but it can also be a burden for framework authors as they want to rather focus on building the framework. Additionally, building **and supporting** a good CLI is another beast to tackle. And this is where Nx comes in.
Nx has had support for [creating custom “presets”](/extending-nx/recipes/create-preset) for a while, allowing plugin authors to fully customize the workspace structure from the ground up. To use them you had to go via the `create-nx-workspace` command though, passing the name of your plugin as the `--preset` . This works, but you might want to have a more “branded command” experience, like `npx create-my-own-app` .
And this is exactly what we’re going to explore in this article. We will write our own CLI. And out of nostalgia, let’s build our own version of Create-React-App.
If you want to check out the final result, here’s the corresponding Github repo: [https://github.com/nrwl/nx-recipes/tree/main/nx-devkit-create-own-cli](https://github.com/nrwl/nx-recipes/tree/main/nx-devkit-create-own-cli)
But before we jump right into the topic, what is Nx? And more specifically, what are Nx Plugins?
Nx is an open-source build system that provides tools and techniques to enhance developer productivity. [Check out this 10 min video overview](https://youtu.be/-_4WMl-Fn0w) of Nx if you want to learn more.
Our example, in particular, uses Nx as a dev tool for creating a CLI and plugin. Nx plugins are npm packages that provide integrations between Nx and other technologies. You can use Nx without them, but they can provide great value if applied properly. `my-own-react` is the plugin to integrate React and Nx.
## Step 1: Create a CLI workspace
Create a new Nx workspace that is preconfigured for plugin development, using the below command:
Note, if you already have an existing Nx plugin workspace, instead of creating a new workspace, you can simply run the following in your plugin repository to generate the create CLI:
```
nx g @nx/plugin:create-package <cli name> --project=<existing plugin name> --e2eProject e2e
The resulting workspace contains 2 projects: a CLI and an Nx plugin.
- **create-my-own-react-app:** The CLI project. It contains the code to run when developers invoke `npx create-my-own-react-app`. This will set up a workspace for the developer.
- **my-own-react:** Nx plugin to integrate react with Nx. It will contain the code for creating and serving an app. It is under the src folder. This will be installed in the user’s workspace.
### CLI Package Structure
Let’s focus on the `create-my-own-react-app` project which is our CLI.
console.log(`Successfully created the workspace: ${directory}.`);
}
main();
```
The main chunk of code is `` createWorkspace(`my-own-react@${presetVersion}`) ``. This function creates an Nx workspace with the `my-own-react` plugin installed.
2. `createWorkspace` will also generate the preset generator defined by `my-own-react` located at `src/generators/preset/generator.ts`. This is the logic which scaffolds a project which uses your technology.
## Step 2: Run the CLI Locally
To properly test your CLI you can either publish it to NPM as a beta version or use a local npm registry like [Verdaccio](https://verdaccio.org/). Luckily our Nx workspace already comes with a feature to make that a seamless process.
1. First, start a local Verdaccio-based npm registry using the following command:
```shell
npx nx local-registry
```
This will start the local registry on port 4873 and configure npm to use it instead of the real npm registry.
2\. In the second terminal, run the command to publish all the projects:
_(Note,_ `_publish_` _is a target defined in the_ `_project.json_` _of our projects.)_
This command will publish both `my-own-react` and `create-my-own-react-app` packages to your local registry. If open the running Verdaccio registry at [http://localhost:4873](http://localhost:4873) you should see the published packages.
3\. Now, you can run `npx create-my-own-react-app` just like a developer using our CLI would. For example, go to the tmp directory and create a `my-own-react` workspace named `test`:
```shell
cd tmp
npx create-my-own-react-app@1.0.0 test
```
What you’ll get is an Nx workspace with the base setup and a `test` library project with a single TS file. Because that’s exactly what our current `preset` generator does.
In this step, we dive a bit more into the actual Nx plugin development to create our CRA replica.
We’ll go rather quickly but if you want a slower walkthrough you might be interested in this video that leverages a generator for automating the creation of projects. Exactly what we’re going to do in our preset now.
{% youtube src="https://youtu.be/myqfGDWC2go" /%}
To do this, we will fill in the preset generator under `src/generators/preset`
A generator is a function that makes modifications to a file system representation known as the `Tree`. These modifications will then be applied to the real file system. In our case, the preset generator will create the files for a React app.
Currently, the file at `src/generators/preset/generator.ts` looks like:
- Create an Nx project using the`addProjectConfiguration` function. This creates a `project.json` file which allows Nx to run commands on it.
- Generates files in the project using the`generateFiles` function. This uses the templates under `src/generators/preset/files` which are interpolated to become the files that are generated for the user.
- Format the generated files with `prettier` with the`formatFiles` function
The `addProjectConfiguration` and `generateFiles` functions are from [@nx/devkit](/nx-api/devkit/documents/nx_devkit), a library that contains utility functions for writing plugins for Nx. For the future, see the [complete list of utility functions](/nx-api/devkit/documents/nx_devkit).
1. Change the project which is created with `addProjectConfiguration`:
```
const projectRoot = '.';
addProjectConfiguration(tree, options.name, {
root: projectRoot,
projectType: 'application',
targets: {}
});
```
- The `projectRoot` will be ‘.’, the root of a workspace
- The `projectType` changes to `application`
2\. Next, change the files generated into the project under `src/generators/preset/files`. We will use the same template as `create-react-app` .
Rename the existing `index.ts.template` to `src/generators/preset/files/src/index.tsx.template` and add the following content:
<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div>
<!--
This HTML file is a template.
If you open it directly in the browser, you will see an empty page.
You can add webfonts, meta tags, or analytics to this file.
The build step will place the bundled scripts into the <body> tag.
To begin the development, run `npm start` or `yarn start`.
To create a production bundle, use `npm run build` or `yarn build`.
-->
</body>
</html>
```
3\. Our application uses some npm dependencies so add those to the workspace as well with the [addDependenciesToPackageJson](/nx-api/devkit/documents/nx_devkit) function to the end of the export default function in `src/generators/preset/generator.ts`:
```
import {
addDependenciesToPackageJson,
...
} from '@nx/devkit';
...
export default async function (tree: Tree, options: PresetGeneratorSchema) {
...
return addDependenciesToPackageJson(
tree,
{
react: 'latest',
'react-dom': 'latest',
'react-scripts': 'latest',
},
{
"@types/react": "latest",
"@types/react-dom": "latest",
}
);
}
```
This line will add the latest `react`, `react-dom`, `react-scripts`, and their types to the `package.json` in the generated workspace.
### Final Preset Generator
Now `src/generators/preset/generator.ts` should look like this:
```
import {
addDependenciesToPackageJson,
addProjectConfiguration,
formatFiles,
generateFiles,
Tree,
} from '@nx/devkit';
import * as path from 'path';
import { PresetGeneratorSchema } from './schema';
export default async function (tree: Tree, options: PresetGeneratorSchema) {
The workspace setup is done, what we’re missing though is a way to easily serve our app. To stick to what CRA does we simply need to run `react-scripts start` , but ideally, we want to make that more convenient for the developer by pre-generating that script into the workspace.
We have two possibilities:
- add the script to the root-level`package.json` using the `updateJson` function exposed by `@nx/devkit`
- add a target to the `project.json` using the `addProjectConfiguration` function exposed by `@nx/devkit`
Nx can use both. The `project.json` is Nx’s variant of a more evolved package.json scripts declaration, that allows to specify metadata in a structured way.
To keep things simple, let’s just generate a new script for the root-level `package.json`. We need to modify our `src/generators/preset/generator.ts` as follows:
```shell
import {
updateJson,
...
} from '@nx/devkit';
...
export default async function (tree: Tree, options: PresetGeneratorSchema) {
...
addProjectConfiguration(...);
updateJson(tree, 'package.json', (json) => {
json.scripts = json.scripts || {};
// generate a start script into the package.json
json.scripts.start = 'npx react-scripts start';
return json;
});
...
}
```
Note, we want to keep our `project.json` file even though it doesn’t have any targets defined. That way Nx recognizes it as a proper project and applies caching and other optimization strategies.
### Adding the target to the `project.json` rather than `package.json`
Alternatively, we could have adjusted the already present `addProjectConfiguration` function to add the `react-scripts` command:
```shell
import {
...
addProjectConfiguration,
...
} from '@nx/devkit';
...
export default async function (tree: Tree, options: PresetGeneratorSchema) {
...
addProjectConfiguration(tree, options.name, {
root: projectRoot,
projectType: 'application',
targets: {
serve: {
command: "npx react-scripts start",
}
},
});
...
}
```
## Step 6: Run it Again to Get a React App That Can Be Served
To test our changes, let’s publish a new version and run it again.
Once we generate a new workspace with the new preset version (npx create-my-own-react-app@1.0.2 test3), we should now see our `package.json` `start`script being generated.
## Step 7: Add a Prompt to the CLI to Customize the Starter App
Now, you have a CLI that creates a workspace that users can use to get started with React. But that’s not all. Let’s take it a step further and make it interactive by adding a prompt that can let different users customize the kind of workspace that they want to create.
Take a look at the CLI code at `create-my-own-react-package/bin/index.ts`, you will notice it is pretty barebone. It reads the`name` from the command’s arguments.
You can use libraries like [enquirer](https://github.com/enquirer/enquirer) (or even fancier ones like [Clack](https://www.npmjs.com/package/@clack/prompts)) to prompt developers for options. For this example, prompt developers to select a light or dark theme for the starter app.
1. Install `enquirer` with `npm i enquirer`
2. Change `create-my-own-react-package/bin/index.ts` to import `enquirer` and prompt developers to enter the mode option:
```
#!/usr/bin/env node
import { createWorkspace } from 'create-nx-workspace';
import { prompt } from 'enquirer';
async function main() {
let name = process.argv[2];
if (!name) {
const response = await prompt<{ name: string }>({
type: 'input',
name: 'name',
message: 'What is the name of the workspace?',
});
name = response.name;
}
let mode = process.argv[3];
if (!mode) {
mode = (
await prompt<{ mode: 'light' | 'dark' }>({
name: 'mode',
message: 'Which mode to use',
initial: 'dark' as any,
type: 'autocomplete',
choices: [
{ name: 'light', message: 'light' },
{ name: 'dark', message: 'dark' },
],
})
).mode;
}
console.log(`Creating the workspace: ${name}`);
// This assumes "my-own-react" and "create-my-own-react-app" are at the same version
Now if you republish the projects and regenerate an app with the light mode, you should see the background color and text color of the header got changed:
This is how users start using your technology so you should write e2e tests to ensure this does not break. This workspace was also generated with a testing file `packages/my-own-react-e2e/tests/create-my-own-react-app.spec.ts`.
You can modify this e2e test to test your CLI. Then, run it using the command `npx nx e2e my-own-react-e2e`. Before the tests run, as a global setup, a local registry is started and the packages are published.
The default test works like this:
1. Creates a test workspace at `tmp/`using the `create-my-own-react-app` CLI
2. Runs `npm ls my-own-react` to validate that the plugin is installed in the test workspace
3. Cleans up the test workspace
Make sure `dark` is passed into `create-my-own-react-app` :
```
exec1-app ${projectName} dark`, {
cwd: dirname(projectDirectory),
stdio: 'inherit',
});
```
Add to a test to check `react` and `react-dom` are installed:
```
it('react and react-dom should be installed', () => {
projectDirectory = createTestProject('dark');
// npm ls will fail if the package is not installed properly
execSync('npm ls react', {
cwd: projectDirectory,
stdio: 'inherit',
});
execSync('npm ls react-dom', {
cwd: projectDirectory,
stdio: 'inherit',
});
});
```
## Recap and next steps
Recap:
- We learned about what an Nx Plugin is and generated a new plugin workspace
- We generated a new CLI package into the workspace: `create-my-own-react-app` . This allows our users to easily scaffold a new workspace
- We adjusted the preset generator to setup a CRA-like React setup
- We wrote some e2e tests to ensure that things do not break
This should give you a good insight into how to get started. But there’s more to explore:
- We could provide more [generators](/plugins/recipes/local-generators\) to our users that help with setting up new components, adding unit tests, configuring the React Router etc.
- Add a generator to add other Nx plugins such as Jest, ESLint, or Cypress
- We could also include “[executors](/extending-nx/recipes/local-executors)”, which are wrappers around tasks to abstract the lower-level details of it
- etc.
Now clearly this was a simple example of how you could build your own CRA using Nx. If you want to see a real-world React setup powered by Nx, check out our React Tutorial: [/getting-started/tutorials/react-standalone-tutorial](/getting-started/tutorials/react-standalone-tutorial)
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
> You can also use the `preset` created by the `qwik-nx` plugin by running `npx create-qwik-nx` or `npx -y create-nx-workspace@latest --preset=qwik-nx`. This will skip a few of the next steps by installing the appropriate dependencies and generating your Qwik app.
>
> The `create-qwik-nx` package is an example of creating an Install Package with Nx. You can learn more here: [https://nx.dev/extending-nx/recipes/create-install-package](/extending-nx/recipes/create-install-package)
> The `create-qwik-nx` package is an example of creating an Install Package with Nx. You can learn more here: [/extending-nx/recipes/create-install-package](/extending-nx/recipes/create-install-package)
Next, navigate into the workspace and install the `qwik-nx` plugin.
@@ -608,4 +608,4 @@ This journey through Qwik and Nx demonstrates how thoughtful architecture and th
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
This blog will show you how to create an Expo monorepo with Nx. In this example, you will be creating two Expo apps in a monorepo with `@nx/expo`: one shows random facts about cats, and the other shows random facts about dogs.
To create a new Nx workspace, run the command `npx create-nx-workspace <workspace name>` in the terminal. In this example, let’s name it `nx-expo-monorepo`:
```
✔ Where would you like to create your workspace? · create-nx-monorepo
✔ Which stack do you want to use? · react
✔ What framework would you like to use? · expo
✔ Application name · cats
✔ Enable distributed caching to make your CI faster · No
```
This will create an [integrated](/deprecated/integrated-vs-package-based) repo. What is an integrated repo?
> An integrated repo contains projects that depend on each other through standard import statements. There is typically a [single version of every dependency](/concepts/decisions/dependency-management) defined at the root.
If you already have an Nx workspace, you need to install the @nx/expo package:
```shell
\# npm
npm install @nx/expo --save-dev
\# yarn
yarn add @nx/expo --dev
\# pnpm
pnpm add @nx/expo --save-dev
```
To create an Expo app, run:
```shell
npx nx generate @nx/expo:app cats
```
Alternatively, if you use Visual Studio Code as your code editor, you can also create apps using [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console):
Now you can use this component in your app directly using an import:
```
import { Carousel } from '@nx-expo-monorepo/ui';
```
## Add Navigation
This project is going to use the [stack navigator](https://reactnavigation.org/docs/stack-navigator) from [@react-navigation/native](https://reactnavigation.org/). So the app needs to import from @react-navigation/stack. In `apps/cats/src/app/App.tsx`, you can change the UI to have one screen displaying a carousel with mock data:
content="Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec porta leo justo, id posuere urna tempor convallis. Nulla finibus, dolor sit amet facilisis pellentesque, velit nisi tempor ipsum, nec interdum libero felis a risus. Pellentesque bibendum, dolor vel varius pulvinar, tortor leo ultrices nisi, non sodales dui quam vitae nulla. Integer sed rhoncus dui. Vestibulum bibendum diam ut leo tempus, vel vulputate magna iaculis. Suspendisse tempus magna libero, sed facilisis tellus aliquet ac. Morbi at velit ornare, posuere tortor vitae, mollis erat. Donec maximus mollis luctus. Vivamus sodales sodales dui pellentesque imperdiet. Mauris a ultricies nibh. Integer sed vehicula magna."
/>
)}
/>
</Stack.Navigator>
</NavigationContainer>
);
};
exportdefaultApp;
```
Run the app with`nx start cats`, and you should be able to see the app on the simulator:
_Page on the simulator (left: iOS, right: Android)_
## Add Another App
In this example, there is already a `Cats` app. To create the `Dogs` app, run the command:
```shell
npx nx generate @nx/expo:app dogs
```
Alternatively, if you use Visual Studio Code as your code editor, you can also create apps using [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console):
content="Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec porta leo justo, id posuere urna tempor convallis. Nulla finibus, dolor sit amet facilisis pellentesque, velit nisi tempor ipsum, nec interdum libero felis a risus. Pellentesque bibendum, dolor vel varius pulvinar, tortor leo ultrices nisi, non sodales dui quam vitae nulla. Integer sed rhoncus dui. Vestibulum bibendum diam ut leo tempus, vel vulputate magna iaculis. Suspendisse tempus magna libero, sed facilisis tellus aliquet ac. Morbi at velit ornare, posuere tortor vitae, mollis erat. Donec maximus mollis luctus. Vivamus sodales sodales dui pellentesque imperdiet. Mauris a ultricies nibh. Integer sed vehicula magna."
/>
)}
/>
</Stack.Navigator>
</NavigationContainer>
);
};
exportdefaultApp;
```
## Build Expo Apps
[EAS Build](https://docs.expo.dev/build/introduction/) is a hosted service for building app binaries for your Expo and React Native projects. To set up EAS locally:
### 1. Install EAS CLI
EAS CLI is the command-line app to interact with EAS services in the terminal. To install it, run the command:
```
npm install -g eas-cli
```
### 2. Login To EAS
If you are not logged in, run the command:
```
eas login
```
### 3. Build the Apps
After the EAS setup, you can build apps by running the command:
```shell
npx nx build cats
npx nx build dogs
```
There are different options you can specify with the build command. For example, you can specify the platform you want to build:
```shell
npx nx build cats --platform=all
npx nx build cats --platform=android
npx nx build cats --platform=ios
```
Alternatively, if you want to create a build to run on a simulator/emulator, you can run:
```shell
npx nx build cats --profile=preview
```
You can view your build status at [https://expo.dev/](https://expo.dev/):
If you want to create a build locally using your own infrastructure:
```shell
npx nx build cats --local
```
Here is the complete list of flags for the build command: [/nx-api/expo/executors/build](/nx-api/expo/executors/build).
## Submit to the App Store
Before you submit, you need to have paid developer accounts for iOS and Android.
- iOS: You need to create an Apple Developer account on the Apple [Developer Portal](https://developer.apple.com/account/).
- Android: You need to create a Google Play Developer account on the [Google Play Console sign-up page](https://play.google.com/apps/publish/signup/). You also need to manually create an app on [Google Play Console](https://play.google.com/apps/publish/) and upload your app for the first time.
### 1\. Run the production build
To submit to the app store, you can build the app by running:
```shell
npx nx build cats --profile=production
```
### 2\. Submit the Build
You can manually upload the build bundle binary to the app store, or you can submit it through EAS.
First, in `app.json` under the project `apps/cats/app.json`, you need to make sure`ios.bundleIdentifier` and `android.package` keys are correct:
- Create multiple apps in a monorepo using @nx/expo
- Create a shared library
- Build your app using EAS
- Submit your app to the App Store
With Nx, it is easy to create and scale up an Expo app. Even though this app is currently a simple 2-page app, you can easily scale it up with more libraries and components. Furthermore, you can also reuse those libraries in the future if you decide to add another app to the repo.
## Learn more
- [Unit Testing Expo Apps With Jest](/blog/unit-testing-expo-apps-with-jest)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
As always, the Nx Team has been hard at work, and we’re here to launch our latest release: Nx 16.8! And it’s absolutely bursting with new features. We’ll go into all these in depth below, but be sure to check out our latest release video on YouTube!
If you have more questions — be sure to stop by our latest Nx Live to ask them there! You can sign up for a notification from the link below!
{% youtube src="https://youtu.be/wj-gb6jqyzA" /%}
## Nx Community News!
Before we jump into the features, be sure to get plugged in to get the most out of Nx in [our NEW discord server](https://discord.gg/Pzz9BW62gD)!
Be sure to checkout our livestream with Jay Bell (Nx Champion, former Nx Community Slack admin, and current Nx Discord Admin) all about the news:
{% youtube src="https://youtu.be/yBsXB8xuTog" /%}
Nx is also coming up on 20k Github stars [please help us get there!](https://github.com/nrwl/nx)
## NEW PROJECT GENERATOR BEHAVIOR: Project Creation Paths and Names in Nx Generators
Alright, getting into the newest updates from Nx, the biggest change is coming in the form of Nx project generators.
Originally, all Nx workspaces had a directory structure where applications were always held in an `apps/` directory, while libraries were held in the `libs/` directory.
Over the years, we found this to be much too rigid, so we made these locations more configurable. We added a `workspaceLayout` category to the `nx.json` file, where you could set `appDir` and `libDir` options to customize the names of these directories.
We also simplified the definition of Nx projects to be any directory that had a `project.json` file in it, allowing for the ability to nest projects in your filesytem and also forego app or lib directories altogether!
With Nx 16.8, we’re introducing an all-new option in this `workspaceLayout` category: `projectNameAndRootFormat` where you can chose either the option to apply project names `as-provided` or `derived`.
You can avoid the extra prompt above by setting the `projectNameAndRootFormat` in the `workspaceLayout` category of your `nx.json` file, or by providing it in in your generate command:
```
> nx g app my-app --projectNameAndRootFormat=as-provided
```
This will change some of the default behaviors of our generators and for new Nx workspaces. By default, new workspaces will be set to `as-provided`, so longtime Nx users might notice that if they create a new workspace and start generating apps or libs, that they will now get generated at the root of the workspace instead of inside the `apps/` or `libs/` directory like they used to.
To get the legacy behavior, be sure to change the `projectNameAndRootFormat` to `derived` and/or use the `name` option to set the name of the project, and the `directory` option to set the full path of the target directory for your new projects:
Nx has always had first-class TypeScript support from the very beginning. You never really had to worry about Type Definition files being properly included or setting up TS support in the first place. But there are some aspects that can be tricky, like defining and properly exporting secondary entry points or packaging in multiple formats (ESM and CJS). That’s why we did some research to help make it easier.
The `package.json` format supports an [export field](https://nodejs.org/api/packages.html#package-entry-points) which is a modern alternative to the `main` property, allowing to have multiple such entry points.
```json
{
"exports":{
"./package.json":"./package.json",
".":"./src/index.js",
"./foo":"./src/foo.js",
"./bar":"./src/bar.js"
}
}
```
To make it easier to maintain these, we’ve added two new options to the `@nx/js` package: `additionalEntryPoints` and `generateExportsField`. Here's an example:
When building the library, the `@nx/js:tsc` executor automatically adds the correct `exports` definition to the resulting `package.json`.
This makes it easy to maintain the `exports` field, something that becomes even more relevant if we **want to add add multiple formats**. By switching to the `@nx/rollup:rollup` executor, we can also add the `format` option and define `esm` and `cjs` as the target formats we want to have. Note we still keep the `additionalEntryPoints` and `generateExportsField`.
Speed is in our DNA! And TypeScript compilation can be slow which is mostly due to `tsc` being a costly operation. You feel this in particular in a monorepo where you have multiple projects that are being compiled independently, thus launching dozens of processes of the `tsc` compiler.
To help with this, the TypeScript team introduced [Project References](https://www.typescriptlang.org/getting-started/intro/handbook/project-references.html) which performs incremental compilation by caching intermediate results. However this comes with some [caveats you need to be aware of](https://www.typescriptlang.org/getting-started/intro/handbook/project-references.html#caveats-for-project-references) and it can be intense to maintain by hand on a large codebase.
We wanted to make it transparent though and not something the user needs to worry about. That’s why we introduced [“Batch Mode”](/showcase/benchmarks/tsc-batch-mode). Batch mode is still experimental, and you can enable it for any project using the `@nx/js:tsc` executor by adding the environment variable `NX_BATCH_MODE=true`:
```
> NX_BATCH_MODE=true nx run-many --target=build
```
When enabling batch mode, Nx leverages the underlying [project graph](/features/explore-graph) to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to [our benchmarks](https://github.com/nrwl/large-ts-monorepo), batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.
In addition to batch mode, the processing of Typescript dependencies is **now using a faster and more accurate Rust implementation**. This should be transparent to most users — aside from your monorepo becoming even faster!
If you want to add playwright to an existing project in your workspace you can also do that now by installing the plugin (here using `npm`):
```
npm add -D @nx/playwright
```
Then running our new generator to add playwright to your project (here I’m adding it to my application called `my-app`):
```
nx g @nx/playwright:configuration --project=my-app
```
This will setup playwright for you, and add an `e2e` target to your project using playwright!
## NEW INTEGRATION: Netlify’s Improved Monorepo Experience
On Netlify’s enterprise tier, approximately 46% of builds are monorepos, with the majority leveraging Nx and [Lerna](https://lerna.js.org/). Recognizing this trend, Netlify has focused on enhancing the setup and deployment experiences for monorepo projects. In particular they worked on an “automatic monorepo detection” feature. When you connect your project to GitHub, Netlify automatically detects if it’s part of a monorepo, reads the relevant settings, and pre-configures your project. This eliminates the need for manual setup. This feature also extends to local development via the Netlify CLI.
[Juri Strumpflohner](https://twitter.com/juristr) from the Nx team sits down with [Lukas Holzer](https://twitter.com/luka5c0m) from Netlify to discuss what monorepos are, when you might need them, their challenges and benefits, and the tooling support Nx provides. But it’s not just talk; they also walk you through setting up a new Nx monorepo, adding Netlify Edge functions, and deploying it all to Netlify — both via the website and locally through the newly improved Netlify CLI.
{% youtube src="https://youtu.be/KL7PCwf-mtM" /%}
If you prefer the blog post, check out [“Elevating enterprise deployment: Introducing an enhanced monorepo experience on Netlify”](https://www.netlify.com/blog/elevating-enterprise-deployment-introducing-an-enhanced-monorepo-experience-on-netlify/) on the Netlify blog.
## NEW Nx CONSOLE FEATURE: Interactive Graph Functionality
If you’re not familiar — Nx Console is our IDE enhancement for [VsCode (1.4 million installations!!)](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) and [JetBrains Products (Intellij/WebStorm/etc — 52 thousand downloads!)](https://plugins.jetbrains.com/plugin/21060-nx-console).
Nx Console provides a Graphical User Interface for running tasks and generating code for your Nx Monorepos, and it also provides the ability to view your project graph
As of our latest release, Nx Console has added the new feature of adding buttons inside the project graph to take you directly to the selected project in the project graph:
## ENHANCEMENT: Storybook Support for Interaction Testing
Storybook 7 introduces new [Interaction Testing](https://storybook.js.org/getting-started/intro/react/writing-tests/interaction-testing) to their platform!
The Nx Storybook plugin has now been enhanced with a new `interactionTests` option on the `storybook-configuration` generator, that will automate setting up these interaction tests for you when you use Nx to generate stories for your components!
You can checkout everything about Storybook Interaction tests and our Nx support for it in this video:
{% youtube src="https://youtu.be/SaHoUx-TUs8" /%}
Nx has always provided similar functionality via our Storybook + Cypress integrations, where you can setup cypress tests to test your storybook showcases, and while you can use interaction testing to replace this integration, we will continue to support our Storybook + Cypress integrations going forward!
## NEW GENERATOR: convert-to-monorepo
Towards the start of the year, we added support for Nx standalone applications. These were designed as a way of using Nx features in a way where you didn’t need to opt into a monorepo setup.
Ever since we introduced these, we’ve had requests from the community to add a generator to convert your standalone workspace to a monorepo setup — to support repos that grew to emcompass more than just the 1 application.
This is where our new [`convert-to-monorepo` generator](/nx-api/workspace/generators/convert-to-monorepo) comes into play!
```shell
nx g convert-to-monorepo
```
This will identify all library projects in currently in your repo and place them in the `libs/` directory that you might expect of a typical Nx monorepo. It will also hoist your application project from the root of your workspace into the `apps/` directory.
When all is said and done, you should be able to now add additional applications to your repo now!
One of the great things about Nx is the extensibility, and the wide range of plugins that are available for supporting languages, frameworks, and tools that the core Nx team does not directly support.
Our docs site has hosted [a registry of these plugins](/plugin-registry) for awhile now, but we’ve recently added npm downloads, github stars, release dates, and compatible Nx versions to this registry:
Go [check it out now](/plugin-registry) live on our docs site!
## DOCS ENHANCEMENT: Redesigned Intro & Examples
Our mission to improve Nx docs continues: this edition with some major updates to our [Docs intro page](/getting-started/intro).
We improved the messaging around Nx and more prominently emphasizing the [core features](/features) that distinguish Nx from other tools out there. We also linked a new “What is Nx” video. You should check it out 🐐
{% youtube src="https://youtu.be/-_4WMl-Fn0w" /%}
The core part of the intro page now has a dedicated section for “Learning Nx”, surfacing some of our Nx, Nx Cloud and Monorepo videos as well as our in-depth tutorial about monorepos and single-project Nx workspaces. And we already have more in the works, so stay tuned.
We’re also proud of all the new examples we’ve added in the last months. We have a brand new [Nx Recipe](https://github.com/nrwl/nx-recipes) repo with a variety of example projects that showcase Nx in combination with different technologies, even outside the JS ecosystem (e.g. with Rust, Go and .Net).
You can find all of the examples and more on our “Showcase” section: [/showcase](/showcase).
## NEW GENERATOR: ESLint Flat Config
ESLint has announced a new config system — nicknamed “flat config” — whose intent is to be be familiar and much simpler than the current config system. You can read more about this [in their blog post](https://eslint.org/blog/2022/08/new-config-system-part-2/).
As part of our continued support for ESLint, we’ve introduced [a new generator](/nx-api/eslint/generators/convert-to-flat-config) to convert your Nx monorepo to this new system:
```
> nx g convert-to-flat-config
```
Flat config is still experimental, so you can use this as a way of easily previewing the new config system now. Just be sure not to mix the original configuration with this new configuration system!
## New Nx Cloud Overview Video
We’ve been working hard on our premium product: Nx Cloud, and part of that has been this awesome video from our own Rares Matei on what exactly Nx Cloud is!
{% youtube src="https://youtu.be/NZF0ZJpgaJM" /%}
Be sure to checkout the [Nx Cloud landing site](/nx-cloud) for more details on all the additional features you unlock with the power of the cloud!
## Nx Conf Coming Up
Last but definitely not least, [Nx Conf 2023](/conf) is fast approaching! We’ll be coming to you live from New York City on September 26!
Be sure to [register to attend online FOR FREE](https://ti.to/nx-conf/nxconf2023online) and be sure to checkout our [lineup of talks](/conf#speakers) and [speakers](/conf#agenda)!
## Wrap Up
That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to our YouTube channel to get updates when new features land! Until next time, KEEP WORKING HARD!
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
Before we start, let’s answer this question: what is Playwright and why should we use it?
From [playwright.dev](https://playwright.dev/), it says: “Playwright is end-to-end testing for modern web apps”. It sounds good, what does it do for us developers? What developer experience does it provide?
### Multiple Browsers
It is easy to run e2e test suites across multiple browsers. Playwright supports all modern rendering engines including Chromium, WebKit, and Firefox. It also supports branded browsers and mobile viewports. For example, we can simply add the below code to the playwright configuration file to run the same test across these browsers:
```
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
/* Test against desktop browsers */
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] },
},
/* Test against mobile viewports. */
{
name: 'Mobile Chrome',
use: { ...devices['Pixel 5'] },
},
/* Test against branded browsers. */
{
name: 'Google Chrome',
use: { ...devices['Desktop Chrome'], channel: 'chrome' }, // or 'chrome-beta'
},
],
});
```
### Auto Waiting
Playwright automatically waits for the relevant checks to pass, then performs the request action. What does it mean? For example, let’s say we have a sign-up form where:
- while the app checks that the user name is unique, the submit button is disabled.
- after checking with the server, the submit button becomes enabled.
How do we write tests in the Playwright? Playwright performs a range of actionability checks on the elements before making actions to ensure these actions behave as expected. So we don’t need to wait for the button to be enabled. Playwright will check it. We can simply write:
```
await page.getByTestId('submit-button').click();
```
### HTML Test Report
Playwright creates a nice HTML test report that allows filtering tests by browsers, passed tests, failed tests, skipped tests, and flaky tests.
It also has other features like recording [screenshots](https://playwright.dev/docs/screenshots) and [videos](https://playwright.dev/docs/videos), [test generation](https://playwright.dev/docs/codegen), and [visual comparisons](https://playwright.dev/docs/test-snapshots). Read more about Playwright at [https://playwright.dev](https://playwright.dev/)
Next, let’s write and run some Playwright tests.
## Create a new Nx Workspace with Playwright
In this example, we will create a React app using Playwright as its end-to-end testing framework. In the terminal, run the below command:
```shell
npx create-nx-workspace
✔ Where would you like to create your workspace? · nx-react-playwright
✔ Which stack do you want to use? · react
✔ What framework would you like to use? · none
✔ Integrated monorepo, or standalone project? · standalone
✔ Which bundler would you like to use? · vite
✔ Test runner to use for end to end (E2E) tests · playwright
✔ Default stylesheet format · css
✔ Enable distributed caching to make your CI faster · No
```
We get a standalone Nx React app named `nx-react-playwright`:
What is a [standalone application](/deprecated/integrated-vs-package-based)? It is like an integrated monorepo setup but with just a single, root-level application. The repo has the same file structure as an app created from Create-React-App, but we can still leverage all the generators and executors and structure your application into libraries or submodules.
### Run E2E
The default e2e test is located in `e2e/src/example.spec.ts`:
Now we have created a new Nx workspace with Playwright. However, if you already have an Nx repo, how do you add Playwright E2E configuration to an existing app?
## How to add Playwright to an existing Nx workspace
For this example, I am going to add Playwright e2e tests to this repo: [nrwl/nx-examples](https://github.com/nrwl/nx-examples)
We are going to focus on the cart app in this example. In the terminal, run `npx nx serve cart` and it should serve up the app at [http://localhost:4200/cart](http://localhost:4200/cart).
Now we can run `npx nx e2e e2e` to run the Playwright e2e tests.
## Summary
In this blog, we have:
- Created a new Nx react repo with Playwright
- Written our own Playwright tests
- Used Nx to run Playwright tests
- Set up a Playwright configuration for an existing Nx app
Hopefully, this gives you good insight into how to get started with Playwright. The Playwright configuration in this example is pretty simple, to learn more about `@nx/playwright` plugin, check out the Nx documentation: [/nx-api/playwright](/nx-api/playwright).
## Learn more
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
Victor and I are excited to announce that Nx has raised another $16M in a Series A funding round with Nexus Venture Partners and a16z! See our announcement video for more, and be sure to check out the [live stream of Nx Conf 2023](https://youtube.com/live/IQ5YyEYZw68?feature=share) tomorrow to see what we’re up to!
- [Experimental: Nx Project Inference API v2](#experimental-nx-project-inference-api-v2)
- [20k Github Stars!!](#20k-github-stars)
- [How to update Nx](#how-to-update-nx)
- [Wrapping up](#wrapping-up)
**Prefer a video?**
@@ -42,7 +44,7 @@ The first place you might notice this new support is in the `create-nx-workspace
This option will create a new Nx workspace with a fresh Vue application, all set up and ready to develop! To add new Vue projects to your existing Nx workspaces, add our new @nx/vue package as a dev dependency to your workspace, e.g.:
```shell
> npm add -D @nx/vue
npm add -D @nx/vue
```
And you’ll have access to Nx generators so that you can generate Vue applications, libraries, components, and more in your workspace:
@@ -74,7 +76,7 @@ The `@nx/react` and `@nx/angular` now include a `federate-module` generator. Thi
To run this generator, use the command:
```shell
> nx g federate-module <module name> --path=<path to module to be exposed> --remote=<name of remote exposing module>
> nx g federate-module <path to module to be exposed> --name=<module name> --remote=<name of remote exposing module>
```
This will add a new module to the `exposes` map in the specified `remote` application, such that it can be consumed by a `host` application.
@@ -126,27 +128,21 @@ When set to `derived`, the generator will try to determine where to create your
In addition, component generators now follow any given casing for component files. For example, let’s say we have an integrated monorepo with a react application called “my-app” and want to add a “Home” component. With Nx 17, you can run the command:
```shell
> nx g component Home --directory=apps/my-app/src/app
> nx g component apps/my-app/src/app/Home
```
And a `Home.tsx` file will be added in the `apps/my-app/src/app` directory.
You can now also build your directory path right into the generator command. For example, the same “Home” component would be created via:
```shell
> nx g component apps/my-app/src/app/Home
```
Finally, generators will now factory in your current working directory, so you can also create this “Home” component via:
```shell
> cd apps/my-app/src/app
> nx g component Home
cd apps/my-app/src/app
nx g component Home
```
## The NEW Nx AI ChatBot
We’ve added a new AI ChatBot to our docs site. You can access it now at [https://nx.dev/ai-chat](/ai-chat).
We’ve added a new AI ChatBot to our docs site. You can access it now at [/ai-chat](/ai-chat).
@@ -206,7 +202,7 @@ There have been some difficulties in determining precisely which files were incl
You can open this graph using the command:
```shell
> nx graph
nx graph
```
And then selecting “Task” from the “Project”/”Task” graph dropdown in the top left. Clicking on a specific task now allows you to see a comprehensive list of all files that were factored in as inputs for this task:
@@ -246,7 +242,7 @@ Interestingly, v2 includes support for dynamic targets as well. This opens up ex
For most developers, the main thing you need to know is that plugins may now add additional targets that you won’t see in your `project.json` file. To see your actual project configuration, you can now use the command:
```shell
> nx show project <project_name>
nx show project <project_name>
```
For plugin authors, check out the [v2 documentation](/extending-nx/recipes/project-graph-plugins) to see how you can take advantage of the new API to deliver a better experience to your users.
@@ -262,13 +258,13 @@ Nx is SOOO CLOSE to 20,000 stars on github! If Nx has been helpful to you, [plea
Nx is known to [help you automatically migrate](/features/automate-updating-dependencies) to the new version (including potentially breaking changes). To update simply run:
```shell
> npx nx migrate latest
npx nx migrate latest
```
This will update your Nx workspace dependencies, configuration and code to the latest version. After updating your dependencies, run any necessary migrations:
```shell
> npx nx migrate --run-migrations
npx nx migrate --run-migrations
```
## Wrapping up
@@ -284,4 +280,4 @@ That’s all for now folks! We’re just starting up a new iteration of developm
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
@@ -160,7 +160,7 @@ Invalid hook call. Hooks can only be called inside of the body of a function com
To solve this, you need to wrap your component inside the renderHook function from `@testing-library/react-native` library:
1.**Install Library to Mock Fetch**
**1\. Install Library to Mock Fetch**
Depending on which library you use to make HTTP requests. (e.g. fetch, axios), you need to install a library to mock the response.
@@ -185,26 +185,26 @@ import fetchMock from 'jest-fetch-mock';
fetchMock.enableMocks();
```
2.**Create Mock Query Provider**
**2\. Create Mock Query Provider**
In order to test out `useQuery` hook, you need to wrap it inside a mock `QueryClientProvider`. Since this mock query provider is going to be used more than once, let’s create a library for this wrapper:
In my latest [blog](https://dev.to/nx/step-by-step-guide-to-creating-an-expo-monorepo-with-nx-3b17), I successfully navigated through the steps of setting up an Expo Monorepo with [Nx](). The next challenge? Testing! This blog dives into:
In my latest [blog](/blog/step-by-step-guide-to-creating-an-expo-monorepo-with-nx), I successfully navigated through the steps of setting up an Expo Monorepo with [Nx](). The next challenge? Testing! This blog dives into:
- Crafting effective unit tests for Expo components utilizing Jest
- Addressing common issues encountered during unit testing
@@ -69,20 +69,20 @@ You can find more options for querying elements on the official React Native Tes
However, unit tests do not always pass. Here are some common errors I ran into and how to resolve them.
### **Error: AsyncStorage is null.**
### Error: AsyncStorage is null.
I am using the library `@react-native-async-storage/async-storage`, and I got the below error when running unit testing:
```shell
\[@RNC/AsyncStorage\]: NativeModule: AsyncStorage is null.
[@RNC/AsyncStorage]: NativeModule: AsyncStorage is null.
To fix this issue try these steps:
• Rebuild and restart the app.
• Run the packager with \`--reset-cache\` flag.
• Run the packager with `--reset-cache` flag.
• If you are using CocoaPods on iOS, run \`pod install\` in the \`ios\` directory and then rebuild and re-run the app.
• If you are using CocoaPods on iOS, run `pod install` in the `ios` directory and then rebuild and re-run the app.
• If this happens while testing with Jest, check out docs how to integrate AsyncStorage with it: https://react-native-async-storage.github.io/async-storage/docs/advanced/jest
@@ -136,14 +136,14 @@ Then I can create a mock store using this library like the below code:
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){export { default as v1 } from './v1.js';
^^^^^^
SyntaxError: Unexpected token 'export'
@@ -286,12 +286,12 @@ I got this error when I was importing from a library such as [react-native-vecto
Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.
By default "node\_modules" folder is ignored by transformers.
By default "node_modules" folder is ignored by transformers.
Here's what you can do:
• If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
• If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
• To have some of your "node\_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
• To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
• If you need a custom transformation specify a "transform" option in your config.
• If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.
@@ -310,9 +310,9 @@ By default, Jest will ignore all the files under node_modules and only transform
However, some libraries such as `react-native-paper` or `react-native-svg`, the library files are in `.ts` or `.tsx`. These files are not compiled to `js`. So I need to add these libraries' names to `transformIgnorePatterns`, so these libraries will be transformed by Babel along with my project. source file. The default generated `jest.config.js` already has:
If I have an error related to a library with an unexpected token, I need to check whether they are compiled or not.
@@ -328,9 +328,8 @@ With Nx, you do not need to explicitly install any testing library, so you can d
## Learn more
- [Add Cypress, Playwright, and Storybook to Nx Expo Apps](https://medium.com/@emilyxiong/add-cypress-playwright-and-storybook-to-nx-expo-apps-1d3e409ce834)
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Community Discord](https://go.nx.dev/community)
Or you can use the utility itself by importing from `@nx/react/mf`:
@@ -124,7 +124,7 @@ nx migrate --run-migrations
You can also use the `--interactive` flag if you want to migrate your workspace to the latest version of Nx while staying on your current version of Angular:
```shell
> nx migrate latest --interactive
nx migrate latest --interactive
✔ Do you want to update to TypeScript v5.2? (Y/n) · true
✔ Do you want to update the Angular version to v17? (Y/n) · false
@@ -212,4 +212,4 @@ That’s all for now folks! We’re just starting up a new iteration of developm
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
@@ -32,7 +32,7 @@ It is that time again: getting flooded by Year of Review blog posts. We did it l
## Top 10 Nx Highlights of 2023
We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: [https://nx.dev/changelog](/changelog) or check out our [Dev.to collection](https://dev.to/nx).
We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: [/changelog](/changelog).
We've picked out 10 highlights for you.
@@ -40,7 +40,7 @@ We've picked out 10 highlights for you.
At Nx, we’ve heavily embraced Typescript from the beginning and we’ve been very happy with that decision. Nx also stands as the [fastest JS monorepo tool](https://github.com/vsavkin/large-monorepo) available, demonstrating that adopting TypeScript does not necessarily compromise speed. However, we don’t stop here. To push the boundaries further, we started to rewrite the most performance critical and computationally intensive parts of the Nx core in Rust.
Our initial focus was on [rewriting the task hasher](https://dev.to/nx/nx-158-rust-hasher-nx-console-for-intellij-deno-node-and-storybook-27ng#rustifying-the-nx-hasher), previously reliant on Git with a Node fallback. This shift to Rust brings a noticeable performance boost, particularly in large repositories, while maintaining the same user experience.
Our initial focus was on [rewriting the task hasher](/blog/nx-15-8-rust-hasher-nx-console-for-intellij-deno-node-and-storybook), previously reliant on Git with a Node fallback. This shift to Rust brings a noticeable performance boost, particularly in large repositories, while maintaining the same user experience.
Following this, we revamped the TypeScript dependency resolution, observing an almost 5x speed increase with our Rust-based approach over the traditional TSC method.
@@ -97,7 +97,7 @@ Nx Console has evolved from an experimental side project of the Nx team to a cor
This year we not only added a lot of new features to Nx Console, but also rewrote its [internals](/blog/nx-console-gets-lit) which paved the way to expand Nx Console to other code editors: **JetBrains IDEs.**
Yes, this means you can now use the latest Nx Console directly in your [Webstorm IDE](https://www.jetbrains.com/webstorm/). Read the [announcement blog post](https://blog.nrwl.io/expanding-nx-console-to-jetbrains-ides-8a5b80fff2d7) for all the details or go ahead and install Nx Console if you didn’t already:
Yes, this means you can now use the latest Nx Console directly in your [Webstorm IDE](https://www.jetbrains.com/webstorm/). Read the [announcement blog post](/blog/expanding-nx-console-to-jetbrains-ides) for all the details or go ahead and install Nx Console if you didn’t already:
- [Nx Console for VSCode](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
- [Nx Console for IntelliJ](https://plugins.jetbrains.com/plugin/21060-nx-console)
@@ -116,7 +116,7 @@ Generally, Playwright fits in the Nx ecosystem as a tool that developers can use
```shell
$ npx create-nx-workspace@latest
> NX Let's create a new workspace [https://nx.dev/getting-started/intro]
> NX Let's create a new workspace [/getting-started/intro]
✔ Which stack do you want to use? · react
✔ What framework would you like to use? · none
✔ Integrated monorepo, or standalone project? · integrated
@@ -144,7 +144,7 @@ TypeScript has won. It has become the prevalent way of writing modern JavaScript
}
```
So in [v16.8](https://blog.nrwl.io/nx-16-8-release-e38e3bb503b5#7b41) we added the ability to automatically have these generated for you by defining the `additionalEntryPoints` and `generateExportsField` when using the `@nx/js` plugin.
So in [v16.8](/blog/nx-16-8-release) we added the ability to automatically have these generated for you by defining the `additionalEntryPoints` and `generateExportsField` when using the `@nx/js` plugin.
```
// packages/my-awesome-lib/project.json
@@ -261,7 +261,7 @@ Where in the example above your host application is named “host-application”
Throughout 2023, we’ve continued to increase Nx’s support and general dev experience around Module Federation, including [adding a generator to federate an existing module](/recipes/module-federation/federate-a-module), improving the local developer experience by improving local webserver performance, and introducing the concept of [Dynamic Module Federation](/recipes/angular/dynamic-module-federation-with-angular#advanced-angular-micro-frontends-with-dynamic-module-federation) which will allow you to dynamically specify the location of your remote applications via a “module-federation.manifest.json” file!
At Nx, we’re excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx’s CI capabilities, in particular allowing for [much shorter build times](/concepts/module-federation/faster-builds-with-module-federation#faster-builds-with-module-federation) especially for larger Angular applications.
At Nx, we’re excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx’s CI capabilities, in particular allowing for [much shorter build times](/concepts/module-federation/faster-builds-with-module-federation) especially for larger Angular applications.
## Many OSS repos adopt Nx
@@ -270,7 +270,7 @@ By simply installing the `nx` package (or initializing with `nx init` in any pro
- Advanced task scheduling, including task pipelines and parallel execution.
- Efficient caching mechanisms.
> If you want to learn more about such setup, make sure to check out our blog post on [how to adopt Nx on a npm/yarn/pnpm workspace](https://dev.to/nx/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx-1eem) or the corresponding [video version](https://www.youtube.com/watch?si=0XH6Sp025xM3Rru5&v=ngdoUQBvAjo&feature=youtu.be).
> If you want to learn more about such setup, make sure to check out our blog post on [how to adopt Nx on a npm/yarn/pnpm workspace](/blog/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx) or the corresponding [video version](https://www.youtube.com/watch?si=0XH6Sp025xM3Rru5&v=ngdoUQBvAjo&feature=youtu.be).
Numerous open-source packages are adopting Nx in this lightweight manner. It enables them to maintain their existing setup while notably enhancing the local developer experience (DX) in task execution and accelerating processes on CI.
@@ -327,21 +327,19 @@ You can also browse them in the [nx-recipes](https://github.com/nrwl/nx-recipes)
And obviously, we jumped on the AI train as well. A couple of months ago, we added the [Nx Assistant](/ai-chat). A ChatGPT-powered interface trained on our docs. [Katerina](https://twitter.com/psybercity) wrote about it [on our blog](/blog/nx-docs-ai-assistant). The AI chat allows to interactively ask questions about Nx and will give you relevant answers from our docs (including linking to the sources).
## New Tagline: Smart Monorepos — Fast CI
Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx’s robust tooling, and later, when the need arises, seamlessly [migrate to a monorepo](/recipes/tips-n-tricks/standalone-to-integrated).
Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx’s robust tooling, and later, when the need arises, seamlessly [migrate to a monorepo](/recipes/tips-n-tricks/standalone-to-monorepo).
However, Nx’s true strength becomes most apparent at scale, typically within a monorepo setup. We wanted to capture it in our new tagline: **Smart Monorepos — Fast CI**.
Setting up an efficient and maintainable CI process for monorepos can be a complex task, so we’ve also made it a focal point in our new tagline. Nx expands beyond the local development experience, helping you set up an efficient CI process. We’re publicly launching [Nx Agents](/ci/features/distribute-task-execution) to add seamless distribution to your CI pipeline, and more are coming in 2024.
As part of that, we also restructured our docs to have a section entirely dedicated to CI: [https://nx.dev/ci](/ci/intro/ci-with-nx).
As part of that, we also restructured our docs to have a section entirely dedicated to CI: [/ci](/ci/intro/ci-with-nx).
## Nx Conf
@@ -389,4 +387,4 @@ Exciting stuff! So keep an eye on our channels, and subscribe if you haven’t a
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
@@ -43,7 +43,7 @@ You can add Nx to an existing npm/yarn/pnpm monorepo quite straightforwardly. Yo
npx nx@latest init
```
You’ll get an `nx` package installed and an `nx.json` allowing you to define [task dependencies](/recipes/running-tasks/defining-task-pipeline) and caching. With that, you're now able to run commands like `nx build <your project>` or nx `run-many -t build test` to run all `build` and `test` targets in your workspace in parallel. Nx will read and use your existing `package.json` scripts. I've written an in-depth [blog post about adopting Nx in such a scenario](https://dev.to/nx/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx-1eem).
You’ll get an `nx` package installed and an `nx.json` allowing you to define [task dependencies](/recipes/running-tasks/defining-task-pipeline) and caching. With that, you're now able to run commands like `nx build <your project>` or nx `run-many -t build test` to run all `build` and `test` targets in your workspace in parallel. Nx will read and use your existing `package.json` scripts. I've written an in-depth [blog post about adopting Nx in such a scenario](/blog/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx).
This is the most lightweight setup you can get while still getting some improvements via Nx regarding faster task running and more intelligent parallelization. But, you need to deal with the remaining of the monorepo setup.
@@ -185,4 +185,4 @@ We just released Project Crystal, so this is just the beginning of it. While we
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
@@ -134,7 +134,7 @@ This modular structure allows teams to work on different aspects of the applicat
For instance, if you want to create a new Vue UI library, you can use the following command:
```shell
nx generate @nx/vue:lib my-shared-ui
nx generate @nx/vue:lib libs/my-shared-ui
```
This command creates a my-shared-ui library within your workspace, which can then be used across your Nuxt app and potentially other applications within the same workspace.
@@ -178,13 +178,20 @@ and see the structure of your projects:
Whether you're starting a new Nuxt project or looking to enhance an existing one, Nx offers a compelling set of tools and features to streamline your development process. From modularization to caching, the integration of Nx into your Nuxt projects promises a more efficient, scalable, and enjoyable development experience. By embracing Nx's capabilities in your Nuxt development, you're not just optimizing your current workflow; you're future-proofing your development process. As your projects grow and evolve, Nx's modular architecture and powerful tooling will continue to provide value, making your development experience more enjoyable and productive.
---
## Nx Live With Nuxt Maintainer Daniel Roe
Don’t miss Nx team members Zack and Katerina with Nuxt’s maintainer, Daniel Roe — live!
@@ -64,7 +64,7 @@ Zack explains Nuxt and how to use the new plugin in this video:
To add @nx/nuxt to your codebase, use the command:
```shell
> nx add @nx/nuxt
nx add @nx/nuxt
```
Huge thanks to [Katerina](https://twitter.com/psybercity) for her work on the plugin, and Nuxt maintainer, [Daniel Roe](https://twitter.com/danielcroe), for helping to guide the project!
@@ -83,7 +83,7 @@ We’re very excited about Nx Agents because we think that in its current state,
Be sure to also checkout the [blog post from Isaac on Nx Agents](/blog/fast-effortless-ci), including explanations of exclusive features like auto-detection and retrying for flaky tasks and automatically splitting lengthy end-to-end tests!
You can [signup for Nx Agents NOW](https://nx.app/products/agents#content), and find out [more of the details in our docs](/ci/features/distribute-task-execution)!
You can find out [more of the details in our docs](/ci/features/distribute-task-execution)!
Rares and Altan are on the team building Nx Cloud, and during the conference, they dove deeper into some of these topics:
@@ -117,7 +117,7 @@ Tusky will also be able to provide organizational-level insights to your codebas
Versioning and publishing packages is always a bit tricky. Mix in the added complexity of having multiple packages — sometimes with different versioning or publishing strategies — inside the same codebase, and things can get weird quick!
For a long time, Nx has been purposefully versioning and publishing agnostic, but given our time spent as [stewards of Lerna](https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9) (the OG Javascript monorepo tool), we’ve been able to take alot of that experience and finally feel confident creating our own versioning and publishing implementation.
For a long time, Nx has been purposefully versioning and publishing agnostic, but given our time spent as [stewards of Lerna](/blog/lerna-is-dead-long-live-lerna) (the OG Javascript monorepo tool), we’ve been able to take alot of that experience and finally feel confident creating our own versioning and publishing implementation.
Therefore, we’ve been working on a new command to the Nx CLI: [nx release](/recipes/nx-release/get-started-with-nx-release#get-started-with-nx-release). We launched this on Friday of our Launch Nx week!
@@ -145,4 +145,4 @@ That’s all for now folks! We’re just starting up a new iteration of developm
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
@@ -32,7 +32,7 @@ But let’s see all the extra things we did this past year to make everything fa
The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn't used. The benchmark results at [this repo](https://github.com/vsavkin/large-monorepo) showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.
### **Task Hasher and archive file innovations**
### Task Hasher and archive file innovations
The introduction of a task hasher written in Rust, alongside the use of an archive file to store workspace file hashes (`.nx/cache`), has significantly reduced the need for repetitive file system accesses. This innovation means that running multiple Nx commands in CI is much faster, as file hashing becomes unnecessary after the initial run.
@@ -48,13 +48,13 @@ Nx Replay enables caching and reusing of task results. It’s our well known Nx
With Nx Replay, you can see significant speed improvements in your CI pipelines for modified PRs. What’s also important is that if a task has been executed in CI, a developer running that same task locally can reuse the task result instead of actually running the task. So you will also see improvements locally.
### **Nx Agents**
### Nx Agents
[Nx Agents](/ci/features/distribute-task-execution) represent the pinnacle of task distribution optimization, ensuring that tasks are executed as efficiently as possible based on the specific requirements of each change. Some features that make up this effort are:
- [Easy integration with existing providers](/ci/features/distribute-task-execution#cicd-guides)
- [Easy integration with existing providers](/ci/recipes/set-up)
- Distribution is handled on the Nx Cloud infrastructure and all you need is a single line. What’s more, all results are played back to your original CI provider script which triggers the Nx Cloud distribution, so that you can make use of the resulting artifacts
- Save compute resources and reduce costs, minimizing idle time and compute waste
@@ -64,13 +64,13 @@ With Nx Replay, you can see significant speed improvements in your CI pipelines
You can read more about Nx Agents [here](https://nx.app/products/agents#content).
### **Atomizer**
### Atomizer
The [Atomizer](/ci/features/split-e2e-tasks) splits your Cypress or Playwright e2e tests by file. This significantly enhances granularity for caching, parallel execution, and flaky test identification. This granular approach ensures that individual test results can be cached and only the necessary tests rerun, greatly reducing CI pipeline times and facilitating more accurate flaky test detection.
### **Addressing flaky tests with test deflaking**
### Addressing flaky tests with test deflaking
Flaky tests can be a significant bottleneck in the CI process. Nx tackles this issue head-on by intelligently [re-running only the flaky tasks](/ci/features/flaky-tasks), rather than the entire pipeline. This approach not only saves time but also provides developers with more confidence in their CI pipeline's reliability.
@@ -102,4 +102,4 @@ Nx provides an unparalleled toolkit for developers and teams looking to optimize
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Community Discord](https://go.nx.dev/community)
The proverbial slow and flaky CI isn’t the failure of the developers or even the testing tools. It’s the failure of the CI execution model we relied on for the last 20 years.
@@ -60,13 +61,13 @@ Tasks can fail:
Let’s see how varying a few parameters affects the probability of the CI execution failing.
| Number of VMS | Avg Tests per VM | Flaky Test Probability | Slow Test Probability | Broken CI Builds (Flaky) | Slow CI Builds |
**The result is much worse than most intuitively expect.** For instance, assuming that an **e2e test has 1 in 1000 chance (0.1%) of failing** for a flaky reason, when the number of e2e tests reaches 500, **the probability of the CI failing for a flaky reason reaches 39%**, and the vast majority of CI executions are slowed down. Note, this is an exceptionally stable test suite. The bottom part of the table is more representative of a typical e2e suite, and the CI becomes “broken” at a much smaller scale.
@@ -170,11 +171,9 @@ The spirit of this post is similar to Alan Kay's quote, "A change of perspective
---
You can learn more about Nx Cloud on [nx.app](https://nx.app) and Nx open source on [nx.dev]().
You can learn more about Nx Cloud on [our docs](/nx-cloud).
**Nx Cloud Pro includes a 2-month free trial** that is definitely worth trying out if you're curious what Cloud Pro can do for your CI. You can try out Nx Agents, e2e test splitting, deflaking and more. [Learn more about Nx Cloud Pro.](https://nx.app/campaigns/pro)
We also have a **Pro for Startups** plan which offers agents that are 3.5x cheaper than analogous VMs on CircleCI or Github Actions. [Learn more about Nx Pro for Startups.](https://nx.app/campaigns/pro-for-startups)
**Nx Cloud Pro includes a 2-month free trial** that is definitely worth trying out if you're curious what Cloud Pro can do for your CI. You can try out Nx Agents, e2e test splitting, deflaking and more. [Learn more about Nx Cloud Pro.](/pricing)
---
@@ -186,4 +185,4 @@ We also have a **Pro for Startups** plan which offers agents that are 3.5x cheap
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Community Discord](https://go.nx.dev/community)
@@ -12,7 +12,7 @@ We are very excited to announce our support for Gradle with our new plugin: `@nx
The Nx Gradle plugin registers Gradle projects in your Nx workspace. It allows Gradle tasks to be run through Nx. Nx effortlessly makes your [CI faster](/ci/intro/ci-with-nx).
> **Note:** this plugin is currently experimental.
> **Update:** Learn how to import your existing Gradle projects into Nx in [ourrecent blog post](/blog/nx-import).
This blog will show you:
@@ -215,4 +215,4 @@ Here is how to set up Nx with the Gradle workspace. Hopefully, this gives you a
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
@@ -82,7 +82,7 @@ Notice how all tasks are now appropriately grouped in the `E2E (CI)` group!
You can also find the same enhancements in Nx Cloud. Below is a view of all tasks in the [CI pipeline](https://staging.nx.app/runs/ctbAZfiLy3):
[](https://staging.nx.app/runs/ctbAZfiLy3)
{% video-player src="/documentation/blog/media/2024-05-08/nx-cloud-atomizer-groupings.mp4" alt="Showing the Atomizer in Nx Cloud" link="https://staging.nx.app/runs/ctbAZfiLy3" /%}
Notice how all e2e groups are collapsed by default to give a concise view, while allowing you to expand to see how each individual task is progressing!
@@ -160,7 +160,7 @@ Since Nx 18 release, we also started using Project Crystal inside of the Nx repo
You can find a full list of fixes and features applied in this major release [here](https://github.com/nrwl/nx/releases/tag/19.0.0).
[](https://github.com/nrwl/nx/releases/tag/19.0.0)
{% video-player src="/documentation/blog/media/2024-05-08/fixes.mp4" alt="A display listing the Github changelog" /%}
With Project Crystal landed now, we're also adjusting our priorities to place a higher importance on stability. You should see this reflected in Nx 19.
@@ -170,9 +170,9 @@ In addition - we are adding more process to make the triage of these issues more
We've got some cool stats to share from our users regarding the benefits of [Nx Cloud](https://nx.app), our premium CI service. The three areas we've identified as the critical aspects of a CI provider are: speed, cost, and reliablity. In these areas we've seen:
We've got some cool stats to share from our users regarding the benefits of [Nx Cloud](/nx-cloud), our premium CI service. The three areas we've identified as the critical aspects of a CI provider are: speed, cost, and reliablity. In these areas we've seen:
- **speed**: Reported 30% - 70% faster CI
- **cost**: Reported 40% - 75% reduction in CI costs
@@ -182,15 +182,15 @@ In February, we launched two big enhancements to Nx Cloud: the [Atomizer](/ci/fe
Since then, the Atomizer has received a nice UI update (as we had seen earlier):
[](https://staging.nx.app/runs/ctbAZfiLy3)
{% video-player src="/documentation/blog/media/2024-05-08/nx-cloud-atomizer-groupings.mp4" alt="Showing the Atomizer in Nx Cloud" link="https://staging.nx.app/runs/ctbAZfiLy3" /%}
Since February, we also revamped our task distribution algorithms. This has resulted in a 5-20% (depending on the repo) increase in both speed and cost efficiency for our users.
If you are interested in trying Nx Cloud, go to [https://nx.app](https://nx.app).
If you are interested in trying Nx Cloud, go to [https://cloud.nx.app](https://cloud.nx.app).
## More Miscellaneous updates!
We've been updating our docs site. We've tweeked the search to make it more helpful, updated navigation, and as you can tell since you're reading it, we've moved our blog to [nx.dev/blog](blog) as well.
We've been updating our docs site. We've tweeked the search to make it more helpful, updated navigation, and as you can tell since you're reading it, we've moved our blog to [nx.dev/blog](/blog) as well.
We've also added a page for [Nx Enterprise](/enterprise):
@@ -235,4 +235,4 @@ Zack
- [Nx GitHub](https://github.com/nrwl/nx)
- [Nx Official Discord Server](https://go.nx.dev/community)
In this episode, Zack DeRose from Nx chats with Hicham El Hammouchi, a veteran in enterprise software. Hicham dives into his background, sharing his career journey and the wealth of experience he's gathered along the way.
They tackle the tough challenges that companies face in software development. Hicham offers practical insights and real-life examples from his own career, making complex issues easier to understand. He also shares some tried-and-true strategies for overcoming these hurdles, emphasizing the importance of teamwork and effective project management.
As the chat continues, Zack and Hicham explore the latest tech trends and innovations that are shaking up the industry. Hicham's forward-thinking views provide a sneak peek into the future of enterprise software. They also discuss detailed case studies of successful projects, highlighting the importance of staying focused on customer needs and feedback.
In this episode, welcome Nx Champion and Nx Expert, Tine Kondo. Our discussion highlights how Nx is poised to make an impact in the Java space.
We touch on the difficulties larger organizations face when merging PRs in a timely manner, emphasizing how a monorepo alleviates the headache of coordinating multiple PRs across various repositories, and share firsthand experiences and frustrations with traditional multi-repo setups, underscoring the benefits of a unified approach.
In particular, Nx's new plugin: [@nx/gradle](/nx-api/gradle) is of interest, and Tine provides some valuable insight on the impact this plugin can make, as well as the importance for Maven support.
It's Friday, and you absolutely, positively have to deploy to production. But you can't get CI to pass your PR. What do you do? It's an inevitable part of your life as a developer, and you've built a collection of tools to deal with it: Google, MDN, Discord, ChatGPT. We've got one more tool for your toolbox: **"Explain with AI" for [Nx Cloud](/nx-cloud)**.
## Your ticket to fast error debugging
"[Explain with AI](/ci/features/explain-with-ai)" is a new feature for all Nx Cloud Pro users that is going to help you troubleshoot those pesky failing tasks. Whenever you get an error message on CI, look for the "Explain with AI" button on the upper right-hand corner:
Once you hit that button, we collect the terminal output and other Nx task information and sprinkle some AI on top of it to give you a suggested fix. That should help you quickly get to the bottom of the issue and get back to work quickly.
No more switching back and forth between a dozen tabs with different solutions. No more providing the right context for your masterfully written chat prompt. **Get your suggested fix and get back to work.**
Also make sure [to check out our docs](/ci/features/explain-with-ai) for more information.
## How can I start using this today?
Here's how you get started:
- **Step 1:** Go to your [Nx Cloud](https://cloud.nx.app/) organization settings
- **Step 2:** Enable AI features
- **Step 3:** Accept the Nx Cloud AI terms and conditions.
- **Step 4:** You're all set ✨
Note that you'll need to be an organization admin for your Nx Cloud workspace to enable AI features.
{% call-to-action title="Log in to Nx Cloud" url="https://cloud.nx.app" icon="nxcloud" description="Enable AI features in your organization settings" %}
Log in to Nx Cloud
{% /call-to-action %}
## More to come!
This is just the first of a series of AI-powered features that we're going to be rolling out to your workspaces. We've got some cool features in the works already, which we're going to **announce publicly during the [Monorepo World](https://monorepo.world) conference in October**! So stay tuned!
- [Monorepo World Conference Speakers Announced!!](#monorepo-world-conference-speakers-announced)
- [Learn more](#learn-more)
## Video Summary
{% youtube
src="https://youtu.be/ER-6sKbb9ck"
title="Nx 19.5 is here! Stackblitz, Bun, AND MORE!"
width="100%" /%}
## Announcing Nx Cloud Hobby Tier
We just added a new [Hobby Tier](/pricing#plan-details) to Nx Cloud! Why is this exciting? It is completely free and contains all major features, which includes the ability to [distribute your tasks with Nx Agents](/ci/features/distribute-task-execution).
This gives you plenty of opportunities to experiment with Nx Cloud on your workspace and see its impact on your teams productivity.
Checkout the [plan details page](/pricing#plan-details) for more info, and see how Nx Cloud can help you! And in case you missed it, check out our latest blog on the latest Nx Cloud feature: [Explain with AI](/blog/explain-with-ai)!
## StackBlitz Support
Nx now has support for [Stackblitz](https://stackblitz.com/) (again). For a while it was not possible to use Nx on Stackblitz because we implemented some perf critical parts of Nx as native components with Rust. Huge shoutout to [LongYinan](https://github.com/Brooooooklyn) for [their amazing work of pushing napi-rs](https://napi.rs/) forward and helping us [add WebAssembly support to Nx](https://github.com/nrwl/nx/pull/22870) as well as the StackBlitz team who helped debug issues.
This means we are back and you can create a StackBlitz with a whole Nx Workspace inside it and run all Nx capabilities from their embedded terminal.
[](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx)
[Check out the example](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx) above. You can use the standard Nx commands in the Stackblitz terminal, like
```shell
nx serve react-app
```
We're excited about this as it opens up many interesting use cases, including easier ways of sharing examples, better opportunities for reproducing issues or bugs, and the potential for us to use embedded examples in our documentation in the future.
Again, special shout out to community contributor [LongYinan](https://github.com/Brooooooklyn) and [their napi-rs project](https://napi.rs/).
## Bun and Pnpm v9 Support
We've been monitoring [Bun](https://bun.sh/) for a while both as a runtime and as a package manager, and we've decided to take the first step in Bun support now by supporting [Bun as a package manager](https://bun.sh/docs/cli/install)! This means that you can now use Bun like you would use npm, pnpm, or yarn to install and manage your dependencies, and Nx will be able to correctly understand those dependencies as `externalNodes` in the Nx dependency graph.
Sending a big thank you to community contributor [Jordan Hall](https://github.com/Jordan-Hall) for completing [this work](https://github.com/nrwl/nx/pull/22602).
In addition to supporting Bun, Nx now supports the latest format of [`pnpm`](https://pnpm.io/) lockfiles which was introduced in version 9.
## Local Flaky Task Detection
Nx Cloud has long offered [flaky task detection](/ci/features/flaky-tasks) on CI, and now this capability is available **even when running them locally**.
If a task is detected as flaky during local execution, you’ll receive a warning. Nx identifies flaky tasks by tracking the outcomes of your tasks in relation to your source code and external dependencies. When the same code produces different results, Nx flags the task as flaky and triggers the warning.
Detecting flaky tasks in the local environment empowers developers to address issues early in the development cycle—before they affect your CI pipelines.
## Project Detail View Enhancements
As part of [project Crystal](/concepts/inferred-tasks) we've added the ability to our plugins to automatically infer tasks based on the tools and configuration files available in your workspace. As part of that we created the "project detail view", allowing you to visualize such dynamically created tasks. You can launch it by using the [Nx Console IDE plugin](/getting-started/editor-setup) or by running the command:
```shell
nx show project [projectName]
```
In this iteration we've added several enhancements to the project detail view. For one, we've added more instructions on how to discover options for the underlying tools, and included examples on how to adjust these options via your `project.json` file.
In addition, we've added a callout for tasks that [leverage the `Nx Atomizer`](/ci/features/split-e2e-tasks). Since atomizer tasks are designed to be used with [Nx Agents](/ci/features/distribute-task-execution#distribute-task-execution-nx-agents), this callout will appear in yellow to warn if your project is not yet configured to run them on CI, and you can click on this callout for an easy way to complete that setup:
Clicking this button will launch the [Nx Cloud onboarding](https://cloud.nx.app) process, which will generate a PR in your repository to complete the setup.
Note that the new, free [hobby tier for Nx Cloud](#new-nx-cloud-hobby-tier) includes the ability to run [Nx Agents](/ci/features/distribute-task-execution) without the need to immediately jump onto a paid plan.
## Pattern Support for `targetDefaults`
When using the [Atomizer features](/ci/features/split-e2e-tasks) of plugins like [`@nx/playwright`](/nx-api/playwright) and [`@nx/cypress`](/nx-api/cypress), you end up creating tasks with dynamic but predictable names.
Notice how the `e2e-ci--src/example.spec.ts` and `e2e-ci--src/test.spec.ts` tasks here are created by the `@nx/playwright` plugin dynamically based on the playwright spec files present in your workspace.
We've now **added pattern matching** to `targetDefaults` task names as a way to target these dynamic tasks.
In the past it was difficult to customize this dynamic set of targets. But with the new support for specifying a pattern to a target name, you can now customize this set of dynamic targets all at once.
The following will set all such tasks to depend on their `build` task:
```json
{
"targetDefaults":{
"e2e-ci--**/*":{
"dependsOn":["build"]
}
}
}
```
Note that our plugins will set sensible configurations here out of the box when creating new workspaces using our generators.
Read more about [reducing configuration with `targetDefaults`](/recipes/running-tasks/reduce-repetitive-configuration#reduce-configuration-with-targetdefaults) and [how you can define task pipelines with `targetDefaults`](/features/run-tasks#defining-a-task-pipeline).
## Individual Targets Can Now Opt Out of Parallelism
One of our goals in transforming the CI landscape is to **make CI more declarative** by focusing on defining the "what" rather than the "how."
To accommodate port collisions in end-to-end tests, we've long adjusted our generated CI script to look like this:
```yml
- run:npx nx affected -t lint test build
- run:npx nx affected --parallel 1 -t e2e-ci
```
Unfortunately, this approach is more imperative, as it instructs how to run and order your CI rather than defining what should be run. Additionally, these instructions cause `lint`, `test`, and `build` targets to run first and wait until they all complete before running `e2e-ci`, leading to inefficiencies.
To address this, all tasks now support a [`parallelism` property](/reference/project-configuration#parallelism). By setting this property to `false`, you can instruct the Nx task runner not to run a specific task in parallel. This allows us to define parallelism as a task property, making our CI configuration more declarative.
Both our `@nx/playwright` and `@nx/cypress` plugins will now automatically set `targetDefaults` for atomized tests to disable parallelism:
```json {% fileName="nx.json" %}
{
// ...
"targetDefaults": {
"e2e-**/*": {
// ...
"parallelism": false
}
}
}
```
This way we can simply run the command:
```shell
nx affected --targets=lint,test,build,e2e-ci
```
In CI, Nx Agents will allow all tasks to run in parallel on the same machine, except for the atomized end-to-end tasks, which will only run in isolation.
Learn more about how you can [Parallelize Tasks Across Multiple Machines Using Nx Agents](/ci/intro/tutorials/github-actions#parallelize-tasks-across-multiple-machines-using-nx-agents):
{% youtube
src="https://youtu.be/0YxcxIR7QU0"
title="Faster e2e Tests!"
width="100%" /%}
## Support For Incremental Builds For Vite
Nx now supports incremental builds with our [`vite` plugin](/nx-api/vite). Incremental builds in Nx workspaces allow you to build any package in your workspace individually, and will then automatically use that built artifact when then building any project or application that consumes the package. This way you can speed up your build and CI times through optimizations like [only building packages that were affected](/nx-api/nx/documents/affected), using [Nx Replay](/ci/features/remote-cache) to effortlessly cache and share your built artifacts, and allowing you to run builds of your various packages in parallel using [Nx Agents](/ci/features/distribute-task-execution).
Read more about [buildable libraries and incremental builds](/concepts/buildable-and-publishable-libraries).
## Project Crystal Conversion Generators
Since launching [Nx Project Crystal](/concepts/inferred-tasks) in Nx version 18, we've adjusted our generators to leverage these features when creating new workspaces and projects. We've now added the `convert-to-inferred` generator to give you an automated way to opt into project crystal.
To run the generator, you can run the command:
```shell
npx nx g convert-to-inferred
```
The important thing to note here is that while this generator will make adjustments to the `project.json` file of the projects you convert, the behavior of your tasks should remain the same. You can see project details via the [Nx Console](/getting-started/editor-setup) plugin of your IDE, or in a browser by running the command: `nx show project [projectName]`.
In Nx 19, we were focused on adding `convert-to-inferred` to our [Playwright](/nx-api/playwright), [Cypress](/nx-api/cypress), and [ESLint](/nx-api/eslint) plugins - where bringing the [Nx Atomizer](/ci/features/split-e2e-tasks) provided the greatest value. Since then, we've added this generator to most other plugins. Currently, our React native plugins (react native, expo, detox) are the only plugins that are outstanding, and we'll be providing `convert-to-inferred` generators here in the near future.
## Gradle Composite Builds Support
In [Nx 19.0](/blog/nx-19-release), we introduced support for Gradle through our [Gradle plugin](/nx-api/gradle). With the latest update, this plugin now also supports [Gradle Composite builds](https://docs.gradle.org/current/userguide/composite_builds.html), in addition to multi-project builds.
Gradle Composite builds are commonly used in larger workspaces to manage dependencies across multiple projects. With this new support, Nx can now leverage composite builds to enhance the Nx Task Graph. For example, consider the following `settings.gradle.kts` file:
```kotlin
rootProject.name = "app"
includeBuild("number-utils")
includeBuild("string-utils")
```
Nx will now be able to automatically determine the dependencies between the `app` project and the `number-utils` and `string-utils` workspaces:
You can read more on composite builds in the [Gradle documentation](https://docs.gradle.org/current/userguide/composite_builds.html).
## Experimental: Gradle Test Atomization
The new [`@nx/gradle` plugin](/nx-api/gradle) now includes experimental support for [Test Atomization](/ci/features/split-e2e-tasks).
With Test Atomization, as you add tests to your Gradle projects, Nx will automatically create a separate task for each test class. This allows you to distribute the execution of these tasks across multiple machines on CI, similar to the functionality provided by our `@nx/playwright` and `@nx/cypress` plugins.
## Experimental: Nx Release Adds File Based Versioning Support
Currently with [Nx release](/nx-api/nx/documents/release), you already have two different ways of figuring out the how to modify the current version of a package to get its updated version:
- Imperatively via the CLI/prompt by telling it your desired relative (semver keyword) or absolute (e.g. `1.2.3`) version.
- Declaratively by letting Nx inspect your git history and determine the semver bump to apply based on the conventional commits specification.
Nx release now supports an experimental third way of deriving the version bump that we call "version plans".
The idea behind version plans is that you want to track your intended version bumps alongside your changes, just like you would do with conventional commits, but you want to make this tracking independent from your actual commit data. This might be because you do not want to/cannot use the conventional commits standard in your workspace, or it could just be that you find it a cleaner approach to versioning.
Version plan files use frontmatter enhanced markdown for their contents, and can be created by hand or by leveraging the new `nx release plan` subcommand. This will guide you through creating a git-tracked file within `.nx/version-plans` that will be committed alongside your normal changes.
When your team is ready to release, you can now simply run the CLI command `nx release` (or use the [powerful programmatic API](/features/manage-releases#using-the-programmatic-api-for-nx-release)) and nx will ingest all the outstanding version plan files and use the combined information to determine the resulting version for all referenced projects and/or release groups as part of the versioning, changelog generation, and publishing steps. (You can also run the command `nx release version` if all you want to do is update the version!)
Anyone who has used the tools "Changesets" or "Beachball" will be familiar with the concept of file based versioning, but with Nx release you get the power to combine one or more of the above mentioned versioning strategies all within the same workspace for different release groups, and we are really excited to keep building out this feature set and mark it as non-experimental (by fully documenting it) very soon. To learn more about the other features of [Nx Release in the meantime, check out our docs](/features/manage-releases).
## Support for React 19 (rc) and Angular 18.1
Nx 19.5 adds support for the React 19 release candidate and updated our Angular package to support the latest Angular minor version: 18.1.
When using our `@nx/angular` package, we'll automatically update you to the latest angular version when you run our migration. Using the `--interactive` flag you can choose to opt in or out of the latest Angular version:
```shell
nx migrate latest --interactive
✔ Do you want to update to TypeScript v5.5? (Y/n) · true
✔ Do you want to update the Angular version to v18.1? (Y/n) · true
Fetching @angular/core@18.1.2
NX The migrate command has run successfully.
```
Our `@nx/react` package will now create new React applications using version 18.3, and we now support the new experimental `reactCompiler`. Users can install the [`babel-plugin-react-compiler` package](https://www.npmjs.com/package/babel-plugin-react-compiler) and you can follow [this guide for how to enable it with Nx](/recipes/react/react-compiler#react-compiler-with-nx).
Note that due to the extent of breaking changes coming with React 19, we will not be providing a automated migration to React 19 via [`nx migrate`](/nx-api/nx/documents/migrate).
## Automatically Update Nx
As always - updating Nx and its plugins is easy as we ship an [automated migration command](/features/automate-updating-dependencies).
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
The [Monorepo World conference](https://monorepo.world) is coming up soon on October 7, 2024 at the Computer History museum in Mountain View, California.
[Get your tickets now](https://ti.to/nx-conf/monorepoworld2024), consider [requesting access to the invite-only Enterprise Summit on October 8](https://ti.to/nx-conf/monorepoworld2024), and be sure to check out our [list of speakers](https://monorepo.world/#speakers-title) that was just published!
In this episode we welcome Nx Champion and creator of [noodle](https://noodle.run) and [OrbitKit](https://orbitkit.dev/): Ahmed Elsakaan.
As a monorepo enthusiast, we explore Ahmed's thoughts on monorepos and how these tools can add value to developers - both in the space of setting up your monorepo (like Nx does) and in the space of creating reusable customizable modules (like OrbitKit is attempting).
In this edition of the Nx Enterprise Podcast, Zack sits down with a panel of Platform Architects from the event platform company, [Cvent](https://www.cvent.com/).
The panel, featuring Youssef Taghlabi, Kevin O'Brien, Josh Lartz, and Ladi Kobiti, dives into their approach to platform engineering—focusing on how they empower teams across their organization and the critical role Nx plays in achieving those goals.
Whenever we talk about Nx Cloud, speed is often a major focus—and for good reason. However, Nx Cloud isn't just about speed. Similar to Nx itself, it's about making work within monorepos more pleasant and efficient. A key part of that is continuously **optimizing developer ergonomics**.
Structuring your log output is one example. In a polyrepo setup, this isn't a big deal since you typically run tasks for a single project. However, in a monorepo setup, you might be running hundreds of tasks in parallel across multiple projects. **Quickly finding a failed task in this context can be challenging.**
## New Table Log View
Today, we released an update that improves how logs are displayed on your CI provider when using Nx Cloud. Instead of streaming all logs directly into your CI provider's pipeline, **we now render a structured table view**. This table shows all tasks, their status (success or failure), timing, and whether they had a cache hit or miss.
At the end of the log output, you'll also see aggregated stats about executed tasks, cache hits, and a link to the Nx Cloud dashboard with full details of the run.
If you prefer the previous log view in your CI, you can opt-out of the new table view. Simply go to your Nx Cloud workspace settings and enable the "Display live terminal outputs in CI pipeline log" option.
If you're not on Nx Cloud yet, you can **connect your Nx workspace** by running:
```shell
npx nx connect
```
This command will guide you through the setup. We recently introduced a [new Hobby plan](/pricing), which lets you experiment with all the Nx Cloud features for free. This is a great way to see if it's a good fit for your team.
## Learn More
- [Nx on CI](/ci/intro/ci-with-nx)
- [Task Distribution with Nx Agents](/ci/features/distribute-task-execution)
- [Automated e2e Test Splitting](/ci/features/split-e2e-tasks)
In this episode of Nx Live, Zack sits down with David from [Trunk.io](https://trunk.io) to explore hands-on examples of how to fast-track your PRs using Nx and Trunk Merge Queues. They also discuss the latest [first-class support for Nx](https://docs.trunk.io/merge-queue/parallel-queues/nx) recently added to Trunk, demonstrating how these tools can streamline your development workflow.
[Monorepo World](https://monorepo.world) is our two-track conference bringing together experts in developer tooling and of course, monorepos. We’re thrilled to share some of this year's speakers, including folks from Zephyr Cloud, Atlassian, GitHub, and HeroDevs. Without further ado, let’s meet your first round of speakers!
### Hacking Bundlers in Nx
[Lois Zhao](https://x.com/zmzlois), Zephyr Cloud
Want to know how builders work and how they can impact your projects? Let’s look at various bundlers and see how they affect the build time and output while also potentially saving organizations millions of dollars.
### What's In Your Dependency Graph
[Josh VanAllen](https://x.com/JVAsays), HeroDevs
Ever ask yourself “why is this build taking so long?” You’re not alone. With monorepos, managing your workspace’s dependency graph can make the difference between spending countless hours waiting to see if your simple changes fixes your apps. Learn how to find the hidden bottlenecks in your dependency graphs and make them efficient!
### How To Use Git - The Right Way - For Monorepos
[Scott Arbeit](https://x.com/ScottArbeit), GitHub
We all use git in our day to day, and it’s great! Until you have to clone a large repository, like potentially a monorepo. Thankfully, there are some tips and tricks you can use to work with large repositories and git that can greatly improve your user experience.
### Atlassian Frontend's Journey To The Monorepo
Manoraj K & Sourav Shaw, Atlassian
Adopting a monorepo for an organization can be a transformative experience. Learn from the folks at Atlassian to hear how they migrated to a monorepo and what strategies they employ to merge multiple repositories into one unified structure.
## Get Your Tickets Today
We hope you’re excited to see these amazing sessions! We’ll have more to share soon about what other speakers you can expect to see at Monorepo world! Don’t forget to register and get your ticket before prices go up September 6th 😱!
In this episode of Nx Live, Zack introduces new Nx team member Mike Hartington to the value of Nx. Together, Zack and Mike build out a full-stack application in their workspace - complete with linting, testing, and end-to-end tests using Nx's generators, and they look at the capabilities that Nx offers in terms of defining their workspace, and how Nx can leverage that information for task-running - especially in CI!
Today, Nx Cloud gets a huge upgrade to managing access to your cached artifacts
using [Nx Replay](/ci/features/remote-cache). Previously, workspaces
were limited to defining access tokens with read or read/write permissions for an entire workspace. With the
introduction of _personal access tokens_, you gain much more control over access. This is a feature request we've heard
from many customers, especially our [Enterprise](/enterprise) customers, and we're happy to be able to deliver this
enhancement.
## Access Tokens and the problem of revoking access
Our previous implementation of access tokens required you to commit the access token to your `nx.json` file. Typically,
service providers don't recommend committing any kind of API token like this, and we've fielded a lot of questions about
this practice in the past. It is safe to commit this token, as access to the cached artifacts of Nx Cloud rely on both
the access token and the source code itself. Without access to both, you can't access the cache.
However, this did present the following problem: revoking someone's access to the cache became difficult as long as they
had the source code. Imagine a scenario where someone has left an organization. As long as they have a clone of the
repo, they have everything they need to access the cache, even if their credentials have been
revoked. To fully revoke
their access would require cycling the access token, which could interrupt the work of other developers and CI
pipelines.
## Access Tokens become CI Access Tokens
What we previously called "access tokens" will now be called "[CI access tokens](/ci/recipes/security/access-tokens)."
They are still defined at the workspace
level, but are designed for use in CI. These tokens should be set as environment variables or secrets on your CI
platform so that they're no longer committed to your repo.
## What are personal access tokens?
[Personal access tokens](/ci/recipes/security/personal-access-tokens) are a new type of access token that is scoped to
an individual user, rather than the workspace. This token authenticates the user with Nx Cloud when running tasks, so that we can validate their access to the distributed cache for a workspace. As soon as a user loses access to an Nx Cloud organization, they will no longer be able to access the cache for any of the organization's workspaces. The user's token belongs to them and will still allow access to their remaining organizations.
This gets even more powerful when combined with the [GitHub integration](/ci/features/github-integration). When a user's GitHub access is removed from
a GitHub-connected organization, their access to your Nx Cloud organization is removed, and their access to the cache for any of the organization's workspaces is removed.
This means that Nx Cloud can fit into existing user de-provisioning processes you already have.
Open source teams also benefit from personal access tokens. You can configure your access to allow anonymous users to
read from the cache, but limit read/write access to core contributors.
## Controlling default access
By default, a workspace that opts in to personal access tokens will allow anonymous users (users without a personal
access token defined) read-write access. This can be changed to disallow access to the cache for anonymous users
in your workspace settings.
Users with personal access tokens will also have read-write access to the cache. This can be changed to enable read-only
access in the workspace settings.
## Converting existing workspaces to use personal access tokens
Personal access tokens can be enabled with _Nx versions 13+_. These steps will get you started, but you
can [find more details in our docs](/ci/recipes/security/personal-access-tokens).
1.**Convert to using `nxCloudId` by running `npx nx-cloud convert-to-nx-cloud-id`** - Previously, your `nx.json` had a
CI
access token defined in the `nxCloudAccessToken` property. This command will replace that with `nxCloudId`, a generic
id that references your workspace but no longer provides access to the cache.
2.**Generate a personal access token by running `npx nx login`** - Follow the directions in your terminal to log
in
to Nx Cloud. Each contributor with access to the workspace will need to complete this step.
3.**Move CI access tokens to environment variables** - Now that the access token is no longer committed to your
`nx.json`,
you'll need to provide that CI access token via the
[Monorepo World](https://monorepo.world) is our two-track conference bringing together experts in developer tooling and of course, monorepos. We’re thrilled to share some of this year's speakers, including folks from Aspect Build Systems, Trunk.io, Aviator Technologies, and Postman. Without further ado, let’s meet your speakers!
## Python Monorepos with Bazel
[Alex Eagle](https://x.com/Jakeherringbone), Aspect Build Systems
Bazel is Google’s open source incremental build tool made for extreme scalability and support for many languages. Let’s look at how Bazel can provide features like CI/CD, building and testing, as well as formatting/linting in a Python environment.
Merge queues are quickly becoming a requirement for high-traffic repos, especially monorepos, - coordinating and merging many PRs from many people while avoiding breaking main can become quite a manual and involved task. This talk will explain what a merge queue is, their features, and how smart merge queues can take advantage of Monorepos with build graphs to scale as the repo grows.
## Scaling Ownership to Improve Developer Experience
Ownership of code and services can become complex and unwieldy, especially as engineering teams scale and codebase complexity grows. This talk will explore practical strategies to streamline ownership management, addressing the intricacies of reorgs, shifting priorities, and codebase complexities.
We often pit Polyrepos against Monorepos, but why not merge the best of both worlds? In this session, let's look at effective management of distributed monorepos from both decentralized and centralized perspectives.
## How to Prevent a Wrong Version Breaking Your Micro Frontends
[Patrick Sevat](https://x.com/_Sevat), Postman
“Oops, it turns out my PR was actually a breaking change. I'm so sorry I broke production for all apps except ours”. This developer nightmare was the worst case scenario the team at Postman has solved. This talk will focus on how shared dependencies can keep federated apps small in bundle size, but come at the risk of breaking other apps when semantic versioning (SemVer) is not adhered to.
We hope you’re excited to see these amazing sessions! We’ll have more to share soon about what other speakers you can expect to see at Monorepo world! Don’t forget to register and get your ticket before it’s too late 😱!
In this episode, Zack sits down with Ruben of Postman to discuss:
- The evolution of Frontend Architecture
- The AngularJS to Angular2 transition and the rise of TS and RXJS
- Why React doesn't get enough credit
- Platform teams and the pit of success
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
FrozenPandaz