## TL;DR;
This PR enabled mapping glob patterns in target names within the project
config to match and extend atomized targets.
## Problem statement
The project configuration (via project.json or package.json) enables us
to override target defaults set via inferred plugins and/or
targetDefaults.
However, this is only possible for fixed targets. Overriding
atomized/dynamic targets would require listing them all explicitly,
which would create a lot of overhead and would break the dynamicity and
automation of the atomized targets.
## Why not use targetDefaults?
The targetDefaults already support globbing to match a range of targets
like e2e-ci-**/* so we can use the same logic on the project level.
We often need to make modifications on project level, rather than the
entire monorepo. E.g. all atomized targets running on a feature lib
checkout should have an implicit dependency on build target of
dependency as stated by "dependsOn": ["^build"] but they also should
have a dependency on app:build - the application which e2e tests are
serving, although there is no direct or indirect dependency between
checkout-e2e and app. This is significant to retain the lean affected
graph.
## Solution
We can use the same globbing logic from targetDefaults and will apply in
mergeProjectConfigurationIntoRootMap function to match glob patterns to
range of targets instead of searching for the explicit target name only.
When the glob pattern doesn't match any targets, the fallback is still
the existing functionality.
This is possible given the fact that plugins' targets get applied before
we start parsing the project configurations, as they have priority over
generic plugin definitions and `targetDefaults.`
Override would look like this:
```jsonc
{
"name": "users-e2e",
"implicitDependencies": ["users"],
"targets": {
"e2e": {
"dependsOn": ["^build", { "target": "build", "projects": "app" }]
},
"e2e-ci--**/*": {
"dependsOn": ["^build", { "target": "build", "projects": "app" }]
}
}
}
```
## 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 we have `^` it forces an update to webpack version
`5.99.x` which is incompatible at the moment with `@angular-devkit`
which is locked to webpack version `5.98.0`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx should be compatible with the migration provided by it's own package
`@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 -->
Publish is failing for linux workflows missing openssl.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Publish passes as reqwest will use `rustls-tls`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The helper to add a project to the package manager workspaces'
configuration doesn't handle correctly when there are no patterns and
this results in the error `Invalid glob pattern` being thrown.
## Expected Behavior
The helper to add a project to the package manager workspaces'
configuration should handle when there are no patterns.
## Related Issue(s)
Fixes #
## Current Behavior
When the `ProjectConfigurationsError` is thrown, no helpful information
is logged.
## Expected Behavior
When the `ProjectConfigurationsError` is thrown, helpful information
should be logged.
It replicates the handling previously done for `ProjectGraphError`.
## Related Issue(s)
Fixes #
## Current Behavior
Angular Rspack relies on Inferred Targets however, when scaffolding the
application, the unit test runners are being set up with executors.
## Expected Behavior
Ensure that when `bundler=rspack` unit test runners are being set up
with inference plugins
This PR adds Git filter `tree:0` to Azure and GitHub pipelines to avoid
fetching the full history content because of the affected command.
The change is made to:
- `ci-workflow` generator in `workspace` project for Azure and GitHub
- `ci-workflow` generator in `gradle` project for GitHub
- this repo's main pipeline -`ci.yaml`
- all documentation occurrences where fetch depth 0 is used on Azure or
GitHub
More info on reasoning here:
https://github.blog/open-source/git/get-up-to-speed-with-partial-clone-and-shallow-clone/
## 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 bumps the versions of `actions/*` GH actions to latest v4.
## 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
Issues reporter is not running
## Expected Behavior
Issues reporter is running
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Create Nx Workspace will prompt for SSG when `Rspack` is chosen as a
bundler option for Angular.
SSG is currently not supported by Angular Rspack.
## Expected Behavior
Do not mention SSG when prompting for SSR with Angular Rspack
Adds a tutorial project under nx-dev
The tutorials are run in browser and can be accessed here:
[/tutorials](https://nx-dev-git-nx-dev-tutorialkit-nrwl.vercel.app/tutorials)
The tutorials include:
- TypeScript Packages
- React Monorepo
- Angular Monorepo
In the future, we will link directly from the sidebar to the in-browser
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 -->
Native typings are out of date.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
native typings are updated
## 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 -->
FreeBSD artifacts are not published as part of PR and canary releases
because it was unstable. Now it seems it's pretty stable though.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
FreeBSD artifacts are published as part of PR and canary releases. Those
releases can be used in this repo (which requires FreeBSD) support.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When running tasks, Nx will run and check the sync generators associated
with the task graph. While locally this is desirable to ensure the code
is always up to date while making changes, in CI, we don't make changes
that need to be synced or checked for every task. This is suboptimal,
and it results in duplicate processing.
## Expected Behavior
Sync generators should not run when running tasks in CI. To validate the
sync status, it is recommended to have a dedicated early step in the CI
pipeline that runs `nx sync:check` once.
## Related Issue(s)
Fixes #
## Current Behavior
When `buildLibsFromSource: false`, webpack fails to resolve custom
entries in the tsconfig `paths`
## Expected Behavior
The tsconfig paths will be correctly loaded by webpack and resolved.
## Related Issue(s)
Fixes#30155.
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
There is currently no way to generate an Angular Rspack app when
creating a new Nx Workspace.
## Expected Behavior
Add support for `--bundler=rspack` in `create-nx-workspace` including
adding `Rspack` as a prompt option when asking for bundler.
## Current Behavior
The `@nx/angular` app generator currently does not support generating an
Angular Rspack application. This makes it slightly more difficult for
users to get up and running with Angular Rspack
## Expected Behavior
Add `rspack` as a supported `--bundler` option allowing for easy
generationg of new Angular Rspack apps.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 a runtime error in our NestJS application:
```
TypeError: Cannot read properties of undefined (reading 'get')
```
The root cause was that services were not being injected correctly due
to missing metadata reflection, which NestJS relies on for its
dependency injection system to resolve services.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We now fully support NestJS's DI system by adding:
```ts
transform: {
legacyDecorator: true,
decoratorMetadata: true,
}
```
This restores proper behavior, and services are injected as expected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29136
## Current Behavior
The `@nx/webpack` depends on `webpack` at version `^5.80.0`. Despite the
`^` allowing it to resolve to a higher minor, there has been no
migration to force users onto a higher version.
There is a security vulnerability with version `5.88.0`.
## Expected Behavior
Ensure users are migrated to a version where the security vulnerability
has been fixed.
## Related Issue(s)
Fixes#29755
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 set assignment rules to default all tasks to medium, which meant that
after the `linux-large` agent was complete, it would terminate since no
tasks would be assigned to it. This fixes the rules to ensure that tasks
can also be assigned to the linux-large agent.
## Expected Behavior
<!-- This is the behavior we should expect 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
The `NxModuleFederationPlugin` and `NxModuleFederationDevServerPlugin`
are currently undocumented on `nx.dev`.
## Expected Behavior
Add documentation for the two plugins including what they do, how to use
them and an API Reference
## Current Behavior
The `@nx/react` `host` and `remote` generators currently use executors
to support Module Federation
## Expected Behavior
When `bundler=rspack` use Crystal Module Federation with no executors
for Module Federation
## Related Issues
#30391
## Current Behavior
After the migration to Vite 6 - The `@vitejs/plugin-vue` was not updated
to v5.
This has led to an incorrect peer dependency.
## Expected Behavior
Upgrade `@vitejs/plugin-vue` to version 5 to remove peer dependency
issues
## Related Issue(s)
Fixes#30326
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 have a Nest app that imports a Nest Lib that is not
buildable inside a TS solution workspace the serving that application
fails because the library is marked as external.
Before we would include these projects as a part of
`tsconfig.compilerOptions.paths`. However, this is no longer possible as
it would not be a valid TS solution setup.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If a library is not buildable it should be able to be resolved
regardless if we are using TS solutions or the legacy paths.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
closes: #30492, #30410, #30544
The `@swc/cli` version we're currently using has a security
vulnerability due to dependency on `cross-spawn`. This PR updates it to
the version that fixes the vulnerability.
Advisory: https://github.com/advisories/GHSA-3xgq-45jj-v275
## Current Behavior
Existing and new JS workspaces have a high security warning.
## Expected Behavior
No high security warning for new workspaces, and existing ones are
updated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There is an issue in the most recent versions of Storybook 8.4 where
expected symbols are not exported correctly.
## Expected Behavior
Migrate to latest Storybook 8.6 to ensure these symbols are correctly
exported to ensure Storybook runs smoothly
## Current Behavior
The `nxCopyAssetsPlugin` from `@nx/vite` does not output the asset files
to the correct location.
It prepends the `rootDir` even when the `outDir` in the `vite.config`
resolves to contain the `rootDir`.
## Expected Behavior
Only prepend the `rootDir` when it does not already exist
## Related Issue(s)
Fixes#28786
## Current Behavior
When a package has a subpath pattern like the following:
```json
{
"exports": {
"./*": {
"types": "./dist/lib/*/index.d.ts",
"import": "./dist/lib/*/index.js",
"default": "./dist/lib/*/index.js"
}
}
}
```
When constructing the graph the project is not picked as a dependency of
others projects that import from the package using a path that matches
that subpath pattern. This is currently happening because the current
resolution is wrongly using `minimatch` to match those patterns instead
of the [Node.js spec for resolving subpath
patterns](https://nodejs.org/docs/latest-v22.x/api/esm.html#resolution-algorithm-specification).
## Expected Behavior
Subpath patterns should be processed after the [Node.js
spec](https://nodejs.org/docs/latest-v22.x/api/esm.html#resolution-algorithm-specification)
and the graph should pick up dependencies when used.
## Related Issue(s)
Fixes#30342
## Current Behavior
The `NxRspackAppPlugin` and `NxWebpackAppPlugin` will not provide
typechecking if using TS Solution setup because it already has a
typecheck target.
However, this means that typechecking will not be run during serve.
## Expected Behavior
Allow typechecking to run during serve even with TS Solution setup
## Related Issue(s)
Fixes#29267
## Current Behavior
The helper to normalize the project name and directory for project
generators validates the provided full directory with a regex pattern
intended to only validate the name.
## Expected Behavior
The helper to normalize the project name and directory for project
generators should only validate the provided name or the name portion of
the provided directory.
## Related Issue(s)
Fixes#28801
## Current Behavior
The `TargetProjectLocator` logic for matching TS path mapping patterns
is incorrect and doesn't handle a few scenarios.
## Expected Behavior
The `TargetProjectLocator` logic for matching TS path mapping patterns
should match the TS resolution and handle all valid scenarios.
## Related Issue(s)
Fixes#30172
## Current Behavior
The `@nx/js/typescript` plugin doesn't handle [extending from multiple
tsconfig
files](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#supporting-multiple-configuration-files-in-extends).
It also identifies local workspace packages linked by the package
manager as external dependencies.
## Expected Behavior
The `@nx/js/typescript` plugin should support extending from multiple
tsconfig files. It should also identify local workspace packages linked
by the package manager correctly and add their resolved path to the task
inputs (not as external dependencies).
## Related Issue(s)
Fixes#29678
This PR fixes and issue where the standard `output.clean` option is
ignored and replaced by the Nx-specific `deleteOutputPath` option on the
`NxAppWebpackPlugin` and `NxAppRspackPlugin` plugins.
We want to allow users to use standards over our own features, so if we
see that `output.clean` is set in webpack/rspack config, then we use
that value.
For example, an Rspack config could be:
```js
const { NxAppRspackPlugin } = require("@nx/rspack/app-plugin");
const { join } = require("path");
module.exports = {
output: {
path: join(__dirname, "dist/demo"),
clean: false, // <-- THIS DOES NOT WORK!
},
plugins: [
new NxAppRspackPlugin({
// ...
}),
],
};
```
But even though `output.clean` is `false`, each build will still delete
`dist`. The only way to disable that behavior is to use the Nx-specific
option like this:
```js
const { NxAppRspackPlugin } = require("@nx/rspack/app-plugin");
const { join } = require("path");
module.exports = {
output: {
path: join(__dirname, "dist/demo"),
},
plugins: [
new NxAppRspackPlugin({
deleteOutputPath: false,
// ...
}),
],
};
```
## Current Behavior
Setting `output.clean` in Webpack/Rspack config does nothing, and we
always default our own `deleteOutputPath` to `true`.
## Expected Behavior
Setting `output.clean` standard option is respected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`-t` is missing in the azure pipelines ci workflow
## Expected Behavior
`nx affected` is called with `-t`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30331
There is a critical vulnerability with Next.js. This PR updates both the
v14 and v15 versions to ensure users are on the latest patched versions.
For new projects, it should already be using the latest patch within the
minor version, since we default to `~` range. This will ensure that
existing projects that did not update yet is updated to the secure
versions.
See: https://github.com/advisories/GHSA-f82v-jwr5-mffw
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Next.js versions for existing projects may be using vulnerable versions.
## Expected Behavior
Migrate existing Next.js projects to patched and secure versions.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`maxCacheSize` is not documented
## Expected Behavior
`maxCacheSize` is documented
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Somewhere in the ts side we are passing a value as null for terminal
outputs. The rust code bails when this happens.
## Expected Behavior
The rust side is able to handle it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR introduces support for `resolutions` and `patches` for yarn lock
file parsing and pruning.
Additionally, it fixes the correct dependency matching when the version
has one of the two forms:
- fluid version range (e.g. `npm:*`)
- union version range (e.g. `1 || 2 || 3`)
## 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
The version of `@analogjs/vitest-angular` and
`@analogjs/vite-plugin-angular` that is installed is `1.10.0`
The latest version is `1.14.1`.
## Expected Behavior
Upgrade to the latest version of the packages.
## Related Issue(s)
Fixes#30423
Closes#30536
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 current version of eslint-config-next (v14.2.16) has peer dependency
conflicts with the latest versions of ESLint (v9.x). This issue causes
npm install to fail in projects using eslint-config-next.
## Expected Behavior
`npm install` should succeed without dependency conflicts.
## Related Issue(s)
Fixes#30536
---------
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
## Current Behavior
There is no dependency between the inferred `typecheck` and `build`
tasks. Depending on their run order, this can result in duplicated
processing (type-checking, `.d.ts` generation). Given there's no
explicit dependency, the order would be non-deterministic.
Additionally, when `outDir` is set in the tsconfig files, it's used
as-is in the currently inferred outputs for `typecheck`. This can result
in extra files being cached for the task.
## Expected Behavior
For optimum performance, the inferred `typecheck` task should depend on
the `build` task. The `typecheck` task's outputs should be more granular
so that only the relevant files (declaration files and declaration map
files if enabled) are cached.
### Explanation
Consider a typical setup with specific tsconfig file for files with
different concerns:
- tsconfig.lib.json: TS configuration for the library runtime files
- tsconfig.spec.json: TS configuration for the unit test files
- tsconfig.json: TS solution configuration, a solution file that
references the specific config files above
When running `tsc -b tsconfig.lib.json --verbose` (build), we can see
how the `tsconfig.lib.json` TS project is built:
```bash
Projects in this build:
* tsconfig.lib.json
Project 'tsconfig.lib.json' is out of date because output file 'dist/tsconfig.lib.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
```
After that, if we run `tsc -b tsconfig.json --emitDeclarationOnly
--verbose` (typecheck), we'll see how the `tsc` output for
`tsconfig.lib.json` is reused:
```bash
Projects in this build:
* tsconfig.lib.json
* tsconfig.spec.json
* tsconfig.json
Project 'tsconfig.lib.json' is up to date because newest input 'src/lib/file.ts' is older than output 'dist/tsconfig.lib.tsbuildinfo'
Project 'tsconfig.spec.json' is out of date because output file 'out-tsc/jest/tsconfig.spec.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.spec.json'...
```
The relevant bit above is `Project 'tsconfig.lib.json' is up to date
because newest input 'src/lib/file.ts' is older than output
'dist/tsconfig.lib.tsbuildinfo'`. Because the initial `build` task
already typechecks and produces `.d.ts` files for the
`tsconfig.lib.json`, when the `typecheck` task runs, `tsc` identifies
that the outputs for that config files were already produced and can be
reused.
If we were to run the tasks in the inverse order, the results would be
different:
```bash
> npx tsc -b tsconfig.json --emitDeclarationOnly --verbose
Projects in this build:
* tsconfig.lib.json
* tsconfig.spec.json
* tsconfig.json
Project 'tsconfig.lib.json' is out of date because output file 'dist/tsconfig.lib.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
Project 'tsconfig.spec.json' is out of date because output file 'out-tsc/jest/tsconfig.spec.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.spec.json'...
> npx tsc -b tsconfig.lib.json --verbose
Projects in this build:
* tsconfig.lib.json
Project 'tsconfig.lib.json' is out of date because buildinfo file 'dist/tsconfig.lib.tsbuildinfo' indicates there is change in compilerOptions
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
```
Note how when the `build` task is run, `tsc` identifies that there was a
change in `compilerOptions` (`--emitDeclarationOnly`) and it requires
building the project. This is because the `typecheck` task only
generates declaration files and the `build` task must also emit the
transpiled `.js` files.
### Benchmark
Running those two different flows in a simple (non-Nx) project with a TS
configuration structure like the one mentioned above and with 5000 TS
files split in half for runtime and test files yields the following:
```bash
hyperfine -r 5 -p "rm -rf dist out-tsc" \
-n "build => typecheck" "npx tsc -b tsconfig.lib.json && npx tsc -b --emitDeclarationOnly" \
-n "typecheck => build" "npx tsc -b tsconfig.json --emitDeclarationOnly && npx tsc -b tsconfig.lib.json"
Benchmark 1: build => typecheck
Time (mean ± σ): 6.832 s ± 0.094 s [User: 11.361 s, System: 1.060 s]
Range (min … max): 6.734 s … 6.985 s 5 runs
Benchmark 2: typecheck => build
Time (mean ± σ): 8.789 s ± 0.015 s [User: 14.817 s, System: 1.267 s]
Range (min … max): 8.771 s … 8.812 s 5 runs
Summary
build => typecheck ran
1.29 ± 0.02 times faster than typecheck => build
```
## Related Issue(s)
Fixes #
## Current Behavior
The Windows drive letter in paths could have different casing in certain
circumstances. The `normalizePath` helper only considers it as
PascalCase, which can result in issues when the path drive letter is
actually in lowercase.
## Expected Behavior
The `normalizePath` should correctly handle the Windows drive letter
regardless of the casing.
## Related Issue(s)
Fixes#28798
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, if you have a webpack application that uses out
NxWebpackAppPlugin and has a non-buildable lib that has exports with
extension enabled for example:`export * from './lib/lib8446520.js';`.
The app fails to build.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using webpack and including libraries that contain extension it
should resolve.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30492
## Current Behavior
The `@angular/google-maps` package version is not updated when running
`nx migrate`.
## Expected Behavior
The `@angular/google-maps` package version should be updated when
running `nx migrate`.
## Related Issue(s)
Fixes#30523
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Update the install instructions for the new java landing page
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
Nothing there.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Adds a new
[/java](https://nx-dev-git-nxdev-gradle-landing-page-nrwl.vercel.app/java)
landing page
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Mike Hartington <mikehartington@gmail.com>
Co-authored-by: Mike Hartington <mhartington@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
When nx is installed in the `.nx` directory the init flow is
substantially different. This changes how some prompting works as well
as how plugin installation flows.
## Expected Behavior
The two flows operate in a similar manner.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, the docs does not differentiate between inferred target
outputs and executor outputs.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Since the outputs differ we should highlight the difference in our docs.
Also, if we pass a bundler to the Next.js lib app generator it should
respect that option.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`@nx/rspack` set ups currently install `@rspack/plugin-minify` which has
been deprecated. It is also unused in the configurations that are
generated.
## Expected Behavior
Remove unused the unused `@rspack/plugin-minify`
## Related Issue(s)
Fixes#30318
## Current Behavior
The `@nx/module-federation` depends on the `@rspack/core` package but it
is currently only set as a `peerDep` meaning users need to install the
package manually.
## Expected Behavior
As the package depends on `@rspack/core`, make sure it is set as a
dependency
## Related Issue(s)
Fixes#30307
## Current Behavior
The `NxAppWebpackPlugin` and `NxAppRspackPlugin` both always set `<base
href="` even when it is set to undefined.
## Expected Behavior
If `baseHref` is set to false, do not set `<base href`.
## Related Issues
#30291
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Every time the vitest generator was run a new duplicate '^build'
dependency was added to the target defaults for the test task.
## Expected Behavior
No duplicate entries added!
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30288
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
If a buildable library depends on another buildable library that has
`outputs` using globs the build fails when using an executor that remaps
the dependency TypeScript path mappings to the build outputs.
## Expected Behavior
Building a buildable library using an executor that remaps the
dependency TypeScript path mappings to the build outputs should succeed.
The remapping logic should identify and replace the glob patterns and
keep the fixed part of the pattern (no segment with wildcards).
Note: additionally, an obsolete check was removed from the
`@nx/angular:package` and `@nx/angular:delegate-build`.
## Related Issue(s)
Fixes#30041
## Current Behavior
Buildable libraries using `tsc` for `build` don't get a `typecheck`
task, which results in test files not being type-checked.
## Expected Behavior
The `typecheck` task should be inferred, and test files should be
type-checked.
## Related Issue(s)
Fixes #
Jest should be compatible with react-router out of the box.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, there are two issues when using `jest` with react-router out
of the box
1. Test files are not included from `tsconfig`
2. While running the test `jsdom` is missing Node's `TextEncoder` and
`TextDecoder` so compilation fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running a test should work without issues when you create a react-router
app with Jest.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30387
## Current Behavior
The `@nx/js/typescript` plugin infers incorrect inputs for tsconfig
`include` patterns when their last segment doesn't contain a wildcard or
an extension (e.g. `"include": ["src"]`).
## Expected Behavior
The `@nx/js/typescript` plugin should [normalize such `include`
patterns](https://www.typescriptlang.org/tsconfig/#include) and infer
valid inputs.
## Related Issue(s)
Fixes#30014
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
In some use cases the local plugins generators and executors are not
transpiled, which causes an error when you execute them. see for example
This issue is introduced by this PR #29539 and is actually a regression
of an error we had in NX 18, see #22958
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR fixes this issue by updating the if statement to register the
typescript transpiler when this is not done yet.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30132
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`nx init` always either installs `next` or `latest` versions of Nx. The
intent here is that running `npx nx init` should always provide the
latest version of Nx, and we added a condition to use `next` if we
detected a beta version of Nx was running to facilitate easier testing
of RC and beta releases. The full logic to determine which version of Nx
to setup is below:
```ts
const version =
process.env.NX_VERSION ?? (prerelease(nxVersion) ? 'next' : 'latest');
```
The goal here was to avoid hitting the `npx` cache and accidentally
creating new workspaces with an older Nx version. This logic falls apart
a bit when considering prereleases though, as `npx nx@next init` would
always check the tag to make sure its up to date rather than using a
cached version. This is the case when providing **_any_** tag to `npx`.
A bad side effect of the above is that when trying to test PR builds and
the like, `nx init` will never setup the PR build when running `npx
nx@0.0.0-pr....` opting instead to setup `next`.
## Expected Behavior
Running `npx nx@0.0.0-pr.... init` sets up an nx workspace using the
specified PR release.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
In a few different places (Crystal plugins, executors, generators,
helpers) where `ts-node` compiler options are overridden and
`moduleResolution` is being set to something other than `node16`,
`nodenext`, or `bundler`, an error can occur if the `customConditions`
compiler option is being used.
## Expected Behavior
When overriding the `ts-node` compiler options and changing forcing
`moduleResolution` to have a value that's incompatible with
`customConditions`, the latter should be unset (set to `null`) to avoid
errors.
## Related Issue(s)
Fixes #
This PR replaces the cumbersome explicit matrix in `e2e-matrix.yml` with
a dynamic matrix built from the input JSON data.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, when you generate a react app and select `--use-react-router`
and `--bundler=` any other bundler except `vite` you would be forced
into using `vite`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When you generate a React app and opt into using `--use-react-router`
with `--bundler=webpack` (for example) you will get an error stating the
React Router can only be used with `vite`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Creating new workspaces since Nx 20.6.0 will generate the Nx
configuration in `package.json` files. This is intended, given that it
is part of the new setup using TypeScript Project References and Package
Manager Workspaces, but there's no way to choose to generate the Nx
configuration in `project.json` files. Project generators do allow to
choose but there's no way to do it when creating a new workspace. This
forces users who want to use `project.json` files to generate an empty
workspace and then use a project generator.
## Expected Behavior
When creating a new Nx workspace, users can provide an option
(`--use-project-json`) to generate the Nx configuration in
`project.json` files.
## Related Issue(s)
Fixes#30464
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Running a batch executor recreates the project graph
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The project graph is passed in when running a batch executor so that it
doesn't have to get recreated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Update library generators to set a `development` conditional export for
buildable libraries' `package.json` files and set the
`customConditions` compiler options in `tsconfig.base.json`. This will
only be done for workspaces using the TS solution setup.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
This PR updates the React monorepo tutorial.
- Remove video embeds since the content is outdated (e.g. shows old TS
setup) -- we have a separate task to update and add back later
- Update the generated files to ensure they are in sync
- Update to show Playwright instead of Cypress since that is the default
- Remove one mention of `project.json` for configuration, and point to
the Inferred Tasks page instead to learn how tasks are automatically
configured
- Update code example for `apps/react-store/src/app/app.tsx` to render
`Welcome react-store` instead of `Home` so that unit and e2e tests still
pass without having to update those as well (better for the flow of the
tutorial)
## Current Behavior
The current `NxModuleFederationPlugin` does not support SSR
## Expected Behavior
The current `NxModuleFederationPlugin` supports SSR
Add `buildLibsFromSource` to the `@nx/rollup:rollup` executor to bring
it to parity with Webpack/Rspack/Vite. This allows the bundle to point
to dist if `buildLibsFromSource: false` is set, which enables
incremental builds.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
Note: This only applies to workspaces using tsconfig paths, as that
linking mechanism is assumed by `buildLibsFromSource`. For NPM
workspaces, whatever is defined in `package.json` exports is used as we
use Node resolution in the new setup.
## Current Behavior
`buildLibsFromSource` does not exist
## Expected Behavior
`buildLibsFromSource exists
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `angular-rspack` and `angular-rsbuild` packages links are always
shown on the menu after navigating to the API section
## Expected Behavior
The links for these packages should only display on the `API` page
In the nx-dev pages, adjust the interface to utilize 'EnterpriseLayout'
instead of 'DefaultLayout'. The duration of the transition in
'customer-logos.tsx' has been reduced from 500 to 200 to boost
responsiveness.
The 'enterprise-layout.tsx' file was added and contains new animation
elements to enhance end-user experience. Updates were made to
'hero.tsx', simplifying and enhancing SVG animation.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
Legacy cache users should get artifacts when remote cache is hit
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30429
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
With a project structure where build.gradle.kts is defined in a separate
buildSrc directory, and not in the root project directory where
`gradlew` is defined, the gradle project is not included in nx project
graph. This is a valid gradle project configuration, with project-report
tasks configured. Running ./gradlew projectReport works and builds the
projectReport.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
With the fix, as long as expected tasks - projectReport or
projectReportAll - is defined, nx should be able to build the nx graph
regardless of the location of the `build.gradle` or `build.gradle.kts`
file.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29783
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 `20.5.0-rc.4`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.7.0-beta.3`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
`tinyglobby` at `0.2.10` (what we use now) is slow on shallow files, but
the latest version `0.2.12` is fast due to this PR
https://github.com/SuperchupuDev/tinyglobby/pull/69/files.
This PR updates both the js and esbuild plugins to use the newest
versions, but also adds `tinyglobby@^0.2.12` to our root `package.json`
so we get the speed increase right away. I removed `fast-glob` in our
repo scripts and replaced it with `tinyglobby`.
## Current Behavior
Asset handling is slow for shallow files like `LICENSE` but is fine for
scoped patterns like `src/**/*.ts`.
## Expected Behavior
Asset handling should be fast for shallow files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- docs(angular): blog post for using angular with rspack
- docs(angular): apply review feedback
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
We do not have the missing features and limitations listed on the docs
for angular rspack
We do not have the benchmarks listed on the docs
## Expected Behavior
Add the missing features and limitations
Add the benchmarks
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
`cache.rs` expects outputs to always be an array
## Expected Behavior
`cache.rs` is able to handle null
## 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 #
This pull request introduces improvements to React Router integration
and removes the Remix preset.
## Key Changes:
- Updated `create-nx-workspace` to support React Router.
- Removed the Remix option from `create-nx-workspace`, but the package
remains to support existing users.
## SSR & React Router Support
- New users who want SSR in their React apps can enable it via the React
option and select React Router for SSR support.
- The ecosystem has shifted to migrating from Remix to React Router for
SSR needs.
- This option is only available for plain React apps and uses Vite.
Other types of React apps (Micro Frontends, Webpack, Rspack, etc.)
remain unaffected.
## Default Routing Behavior
`--routing` is now enabled by default when creating a React app using
`create-nx-workspace`, aligning with Angular’s default behaviour.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 versions of Axios and webpack packages have vulnerabilities
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Versions of axios and webpack have no known vulnerabilities
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Nx currently does not offer an automated method for switching from an
Angular Webpack build to an Angular Rspack build.
## Expected Behavior
Provide a generator `convert-to-rspack` in `@nx/angular` that will allow
conversion from an Angular Webpack build to an Angular Rspack build.
Usage: `nx g convert-to-rspack --project=myapp`
## TODO
- [x] handle more builder options
- [x] take existing custom webpack configs and migrate into the rspack
config that is created
This PR introduces the React Router plugin in Nx.
The new functionality adds a react-router plugin entry into `nx.json`,
projects that are React-Router V7 via `react-router.config.(m|c)?[jt]s`
will have their targets inferred.
### Changes
Update the React plugin to have a react-router (RR V7) plugin export.
The RR V7 will only infer targets if we have a
`react-router.config.(m|c)?[jt]s` and also a `vite.config.(m|c)?[jt]s`.
Under the hood the RR V7 CLI uses vite for compilation.
That being said, apps are not limited to only use vite for RR V7. Should
you choose to use it the compilation will not be done via RR V7 CLI.
## Current Behavior
To create a new workspace that uses the new TS solution setup the
`--workspaces` flag must be provided (Node, React, and Vue stacks).
## Expected Behavior
New workspaces should be created by default using the new TS solution
setup (Node, React, and Vue stacks). Users can opt out of it by
providing the `--no-workspaces` flag.
## Related Issue(s)
Fixes #
## Current Behavior
`convert-webpack` generator is offered by `@nx/rspack` plugin.
## Expected Behavior
Add an alias of `convert-to-rspack` to make it clearer
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 `nx register` requires users to enter a key.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Calling `nx register` should work without having users enter a key.
## 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 max cache size is disabled by default
## Expected Behavior
Max cache size is set to 10% of the current disk by default, and can be
disabled by specifying 0. Information about this shows up in `nx
report`.
<img width="331" alt="image"
src="https://github.com/user-attachments/assets/ee937101-9915-49d1-b3f1-c2f0d929c140"
/>
## 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 plugins which do not support `keepExistingPackages` fail to
initialize via `nx init` or `nx add`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx plugins which do not support `keepExistingPackages` initializes
properly via `nx init` and `nx add`
## 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 `directory` option for the ngrx feature store generator is currently
marked as optional. With that, if you try to run the generator and do
not pass a directory, it will throw an error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`directory` needs to be a required option. The Nx Console already
handles this by pre-populating the option, this just adjusts things
appropriately for those not using the console, or calling the generator
programatically.
## 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 #
Infer the relevant ts-node compiler options to support an Rspack config
file using TypeScript as per https://rspack.dev/config/#using-ts-node.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Cache artifacts are removed based on age at a random interval. There is
not a way to set a max size for the cache, so it can grow quite large in
certain repos
## Expected Behavior
Cache size can be controlled via `maxCacheSize` in `nx.json`. Cache
artifacts are removed based on usage until the limit has been reached.
## 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: Isaac Mann <isaacplmann@users.noreply.github.com>
Add a `useProjectJson` option to project generators to allow users to
opt in/out of generating the Nx configuration in a `project.json` file.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
Moving a project included in the package manager workspaces setup to a
new destination that's not matched by that configuration results in the
project not included in the package manager workspaces setup.
## Expected Behavior
Moving a project included in the package manager workspaces setup to a
new destination that's not matched by that configuration should result
in the new destination included in the workspaces setup.
## Related Issue(s)
Fixes #
The documentation currently states:
> "Add a `module-federation.manifest.json` file to the `src/public/`
folder in our Dashboard application..."
However, the correct location for the file is `public/` and **not**
`src/public/`. This could lead to confusion when implementing the
example, as the folder structure may differ.
So I fixed it to public/
This issue was reported here: [Issue
#30020](https://github.com/nrwl/nx/issues/30020).
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 set the parallelism at the DTE level and it applies to all
tasks executed for that DTE.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We can set parallelism on our assignment rules and dynamically set the
parallelism of tasks as they are being scheduled.
## 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 `20.5.0-rc.3`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.5.0-rc.4`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Adds the march webinar
- Adds an `eventDate` frontmatter property for webinars
- Orders webinars by publish date in the `/blog` list (not event date)
- Adds a CTA to the Cursor blog post that points to the March webinar
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 an e2e test expectation that got outdated after two different
changes were merged.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
The following are the main changes in the context of the TS solution
setup:
- Ensure `name` in `package.json` files is set to the import path for
all projects
- Set `nx.name` in `package.json` files when the user provides a name
different than the package name (import path)
- Clean up project generators so they don't set the `nx` property in
`package.json` files unless strictly needed
- Fix `@nx/vue:application` generator so it creates the Nx config in a
`package.json` file for e2e projects
- Ensure `@types/node` is installed in `vitest` generator
- Fix generated Vite config typing error (surfaced with Vite 6)
- Ensure `jsonc-eslint-parser` is installed when the
`@nx/dependency-checks` rule is added to the ESLint config
- Misc minor alignment changes
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When the `init` generator is in an extended collection, `nx add` will
not run it.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When the `init` generator is in an extended collection, `nx add` will
run it.
## 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: Jason Jean <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 -->
If we are using `esbuild` as our bundler and ts project references
(`--workspaces`) local libraries are not building are not resolved in
the build artifacts.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using ts project references with esbuild all types libraries
(buildable / non-buildable) should work out of the box.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
There is a migration that always adds `sass-embedded` for Rspack and
Webpack for 20.5
## Expected Behavior
`sass-embedded` is already a dependency of Rspack and Webpack and
therefore does not need to be added to users package.json - especially
as they may not be using it.
Updated titles for existing team members to reflect current roles. Added
new team members, Nate Bohn and Steven Nance, along with their
corresponding images.
## Current Behavior
When the Nx configuration is in `package.json#nx` and not in
`project.json`, the move generator creates a `project.json` file in the
new destination.
## Expected Behavior
When the Nx configuration is in `package.json#nx` and not in
`project.json`, the move generator should not create a `project.json`
file in the new destination and should update the `nx` entry in the
`package.json` file.
## Related Issue(s)
Fixes #
## Current Behavior
Daemon log is annotated by time only
## Expected Behavior
Daemon log is annotated by time and nx version
```
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.417Z - Started listening on: /tmp/c31c3bdb2db26a7fdd62/d.sock
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.419Z - [WATCHER]: Subscribed to changes within: /tmp/testing/test-daemon-shutdown (native)
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.421Z - Established a connection. Number of open connections: 1
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.423Z - Closed a connection. Number of open connections: 0
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.694Z - Time taken for 'Load Nx Plugin: /tmp/testing/test-daemon-shutdown/node_modules/nx/src/plugins/project-json/build-nodes/project-json' 172.34599799999998ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.704Z - Time taken for 'Load Nx Plugin: /tmp/testing/test-daemon-shutdown/node_modules/nx/src/plugins/package-json' 182.822698ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.710Z - Time taken for 'loadDefaultNxPlugins' 189.074698ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.747Z - [REQUEST]: Updated workspace context based on watched changes, recomputing project graph...
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.747Z - [REQUEST]:
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.747Z - [REQUEST]:
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.751Z - Time taken for 'loadSpecifiedNxPlugins' 226.801397ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.931Z - Time taken for 'build-project-configs' 171.525398ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.932Z - Time taken for '@nx/js/typescript:createDependencies' 1.57650000000001ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.956Z - [SYNC]: collect registered sync generators
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:40.957Z - Time taken for 'total execution time for createProjectGraph()' 25.567300000000046ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:45.422Z - [WATCHER]: Stopping the watcher for /tmp/testing/test-daemon-shutdown (sources)
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:45.422Z - [WATCHER]: Stopping the watcher for /tmp/testing/test-daemon-shutdown (outputs)
[NX v20.5.0 Daemon Server] - 2025-03-04T21:07:45.424Z - Server stopped because: "5000ms of inactivity"
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.567Z - Started listening on: /tmp/c31c3bdb2db26a7fdd62/d.sock
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.570Z - [WATCHER]: Subscribed to changes within: /tmp/testing/test-daemon-shutdown (native)
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.574Z - Established a connection. Number of open connections: 1
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.575Z - Closed a connection. Number of open connections: 0
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.824Z - Time taken for 'Load Nx Plugin: /tmp/testing/test-daemon-shutdown/node_modules/nx/src/plugins/js' 151.981699ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.838Z - Time taken for 'Load Nx Plugin: /tmp/testing/test-daemon-shutdown/node_modules/nx/src/plugins/project-json/build-nodes/project-json' 165.931999ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.839Z - Time taken for 'loadDefaultNxPlugins' 167.35379900000004ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.856Z - [REQUEST]: Updated workspace context based on watched changes, recomputing project graph...
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.856Z - [REQUEST]:
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.856Z - [REQUEST]:
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.864Z - Time taken for 'loadSpecifiedNxPlugins' 184.725799ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.879Z - Time taken for 'build-project-configs' 9.32310000000001ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.880Z - Time taken for '@nx/js/typescript:createDependencies' 1.6195999999999913ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.886Z - [SYNC]: collect registered sync generators
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:04.886Z - Time taken for 'total execution time for createProjectGraph()' 9.240700000000004ms
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:09.575Z - [WATCHER]: Stopping the watcher for /tmp/testing/test-daemon-shutdown (sources)
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:09.575Z - [WATCHER]: Stopping the watcher for /tmp/testing/test-daemon-shutdown (outputs)
[NX v20.5.0 Daemon Server] - 2025-03-04T21:08:09.577Z - Server stopped because: "5000ms of inactivity"
```
## 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 #
Using vitest whenever we merge configs from executors and the config
file. The executors should override the option which has be set inside
of the config 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 -->
The `reportsDirectory` option which can be set when using
`@nx/vite:test` is not override the generated coverage directory path.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When the `@nx/vite:test` executor runs the option `reportsDirectory`
should override the option set inside `vite.config`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30223
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Angular migrations require @angular/core@19.2.0, to update to 19.2.0
## Expected Behavior
Angular migrations require @angular/core@19.1.0 to update to 19.2.0
## 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>
## Current Behavior
When generating a CI workflow (via creating a new workspace or invoking
the `ci-workflow` generator directly) in a workspace using the TS
solution setup, the `typecheck` task is not present in the affected
command that is generated in the CI workflow file.
## Expected Behavior
When generating a CI workflow in a workspace using the TS solution
setup, the `typecheck` task should be present in the affected command
that is generated in the CI workflow file.
## Related Issue(s)
Fixes #
When we run `nx graph --help` we see that the `--include` commands is
not available.
So the docs should also reflect the current options.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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#30212
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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.5.0-beta.2`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.5.0-rc.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 #
## Current Behavior
In the TS solution setup, several project generators produce the runtime
tsconfig files (e.g. `tsconfig.lib.json`) with the `outDir` set to
`out-tsc/<project name>`. This causes issues with the inferred
`typecheck` task because the project `package.json` has the `types`
export pointing to `dist/...`, which wouldn't be produced by
`typecheck`.
## Expected Behavior
In the TS solution setup, project generators should produce the runtime
tsconfig files (e.g. `tsconfig.lib.json`) with the `outDir` set to a
path (`dist`) that matches the value in the project `package.json`'s
`types` export.
## Related Issue(s)
Fixes #
This PR adds support for skipping `typecheck` targets when using
`@nx/js/typescript`. Inside `tsconfig.json` for each project, you can
set `nx.addTypecheckTarget` to `false` to not infer `typecheck`.
This allows use to skip `typecheck` for JS projects using `tsc` to
build. Since `tsc` is already used during build, we don't need to run
`typecheck` that is just duplicated work.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
JS libs using `tsc` to build will do typechecking twice. Once during
`build` and once during `typecheck`.
## Expected Behavior
JS libs using `tsc` do not infer `typecheck` by default. And users can
change this behavior by setting `nx.addTypecheckTarget` in
`tsconfig.json`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
No information on Powerpack perpetual Nx versions is displayed
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Perpetual Nx versions is displayed when running `nx report`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jason Jean <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
The documentation currently states that `v16` is still supported, while
the correct version is `v17`.
## Expected Behavior
After this update, the documentation will correctly display `v17` as the
supported version instead of `v16`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30046 (if applicable).
## Current Behavior
- Generating a non-buildable library in a workspace using the TS
solution setup where a plugin registration for `@nx/js/typescript`
already exists and doesn't configure a build target, results in that
plugin registration being updated excluding the new project and a new
registration being added including the project but inferring the build
target.
- Generating a library in a sub-directory that matches a pattern in the
package manager workspaces configuration, results in a more specific
pattern being added to the workspace configuration.
## Expected Behavior
- Generating a non-buildable library in a workspace using the TS
solution setup where a plugin registration for `@nx/js/typescript`
already exists and doesn't configure a build target, should not modify
that plugin registration and it should not add an extra one.
- Generating a library in a sub-directory that matches a pattern in the
package manager workspaces configuration, should not add a more specific
pattern.
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
-->
Make sure Cursor specific files are not git indexed as MCP servers might
be custom. If we ever continue adding cursorfiles etc that are shared
for the repo we can have a more fine-grained ignoring.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Copy assets plugin for Vite is not copying files in watch mode when
those files are changed.
This is due to the path being incorrect after calculation.
There is also no indication to the user that the copy completed at all.
## Expected Behavior
Fix path calculation to allow copy to occur correctly
Output the relative dest of the file after copy completed.
## Related Issue(s)
Fixes#30141
This PR is the same as https://github.com/nrwl/nx/pull/30187 but for
`@storybook` packages. We want to make sure that workspaces that have
other `@storybook/*` packages installed have their versions updated
along with the packages we use. Otherwise version mismatches can lead to
errors due to changing APIs.
This PR also adds a conformance rule that prevents mistakes from going
out in future migrations.
## Current Behavior
`@nx/vite:build` executor does not support Vite 6 Environments API
## Expected Behavior
`@nx/vite:build` executor builds all environments when Vite 6 is
detected
## Current Behavior
When TS Path Mappings are combined with an explicit extension of the
build outcome of a file, the `nxViteTsPaths` plugin cannot resolve the
file.
e.g.
```ts
import {something} from '@mylib/file.js';
// tsconfig paths
"@mylib/*": ["mylib/src/*"]
```
In this case, we fallback to the file system to try find the file, and
we do it by adding extensions to the end of the path.
e.g.
```ts
@mylib/file.js.js
@mylib/file.js.ts
@mylib/file.js.mts
etc
```
## Expected Behavior
Perform the usual logic first to try find the file in the file system.
If the file is still not resolved AND the path ends with an `extname`
that we support in `options.extensions`, strip the extension from the
path and try append the different extensions again and resolve against
the filesystem.
This allows for the case where someone has a file in their file system
that _is_ `file.js.js` to be resolve via `@mylib/file.js` as well as
when the explicit path is provided.
## Related Issues
Fixes#29948
## Current Behavior
When Vite build is run where:
- `nxViteTsPaths` plugin is enabled
- `--verbose` or `NX_VERBOSE_LOGGING=true` is set
The resulting logs can be quite noisy.
## Expected Behavior
When `debug` is explicitly set to false, ignore logs even when
`--verbose` is passed.
Usage:
```ts
nxViteTsPaths({ debug: false })
```
## Related Issue(s)
Fixes#29320
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Restores a package update group with a `requires` entry to handle
workspaces using `@typescript-eslint/eslint-plugin` and not
`typescript-eslint`.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When we generate a Next.js application with tailwindcss running with
`--turbo` fails due to how the globs are defined inside
`tailwind.config.js`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Relative paths a singular globs are required with this change tailwind
should work with HMR using `--turbo`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29946
The current sample rate for Grafana Faro is the default 100% and is
currently around $200 for the month. We want to be able to make changes
to it without needing code changes. Once this PR is merged, we can just
update the env var, and then redeploy.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 creating a new Next.js application and running the spec file it
fails OOTB.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running the spec file after creating a new Next.js application should
work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates `migrations.json` for `@nx/eslint` and `@nx/angular` so
that `@typescript-eslint/*` and `@angular-eslint/*` packages that are
installed in the workspaces are updated to the same version.
I've updated it for v20 and v19, but if we need to go back further we
could. This will also require patch versions for each major that we want
to fix.
**Note:** Previously there were two entries for `@nx/esilnt@20.4.0` that
handles cases where one of `typescript-eslint` or
`@typescript-eslint/eslint-plugin` are > 8. The packages in both entries
overlap, so I collapsed them down to one entry that checks
`typescript-eslint > 8`.
## Current Behavior
If user has `@typescript-eslint/rule-tester` or
`@angular-eslint/test-utils` installed, our migrations do not update
these versions. This makes them out of sync with
`@typescript-eslint/utils`, etc. which can lead to problems.
## Expected Behavior
Packages in the same `@typescript-eslint/*` and `@angular-eslint/*` are
updated together. If they are not installed, we don't add them to the
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 -->
Currently, when `--useGitHub` is passed the option is ignored so the
user is asked if they would like to use GitHub.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
With this change if the `--useGitHub` flag is passed it will be
respected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29722
## Current Behavior
* Using your own CI provider to distribute tasks is referred to in
multiple ways
* DTE configuration is beneath the Enterprise section of CI docs
## Expected Behavior
* Using your own CI provider to distribute tasks is referred to
consistently as "Manual DTE"
* DTE configuration is its own recipes section
## Related Issue(s)
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
This PR brings back the CRA migration that was missing since Nx 18.
## Current Behavior
<!-- This is the behavior we have today -->
`nx init` does not migrate CRA apps
## Expected Behavior
`nx init` migrates CRA apps to Vite since CRA is deprecated
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When the dist for a project lives in the projectRoot, the
`parseStaticRemotesConfig` util function for executors is not correctly
handling the outputPath and urlSegment
## Expected Behavior
Ensure that the parsed config is correct regardless of whether the dist
is in the projectRoot or not
## Related Issue(s)
Fixes#30138
## Current Behavior
`esbuild` has a security advisory for versions up to 0.24.
If users attempted to install a version greater than 0.19, they would
face peer dep issues with the `@nx/esbuild` package.
## Expected Behavior
Expand the peerDep range for `esbuild` on the `@nx/esbuild` package to
allow users to upgrade.
Keep the base version at a lower version to support older OS and VMs
which are unsupported by newer versions of `esbuild`.
Closes#30009
Fix a bug introduced in #30087
#### Current Behavior
The `@nx/js` plugins throw an error when the project is served in the
project root but not in the workspace root.
#### Expected Behavior
Ensure that `nx run $project:serve` works correctly both in the
workspace root and the project root, restoring the previous behavior.
#### Related Issue(s)
Fixes#30087
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 bundling rollup copies wrong readme which ends up in publishing a
root monorepo readme, not a package one
## Expected Behavior
It shoud take the right Readme.md
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29975
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Error when using rollup.config.ts
```
NX Failed to process project graph.
2 errors occurred while processing files for the @nx/rollup/plugin plugin.
- packages/codygen/rollup.config.cts: Unknown file extension ".cts" for /workspaces/codygen/packages/codygen/rollup.config.cts
- sample3/rollup.config.ts: Unknown file extension ".ts" for /workspaces/codygen/sample3/rollup.config.ts
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Plugin should be able to load rollup.config.ts
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29982
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Nest library generator fails because `readProjectConfiguration` is not
returning targets property:
```
NX Generating @nx/nest:library
NX Cannot set properties of undefined (setting 'build')
Pass --verbose to see the stacktrace.
* The terminal process "/bin/zsh '-l', '-c', 'npx nx generate @nx/nest:library --directory=packages/backend/feature-typeahead --buildable=true --linter=eslint --unitTestRunner=jest --controller=true --importPath=@listing-experience/feature-typeahead --name=feature-typeahead --service=true --tags=type:lib,scope:nest --no-interactive --dry-run'" terminated with exit code: 1.
* Terminal will be reused by tasks, press any key to close it.
```
## Expected Behavior
The library should be generated without issues
## Current Behavior
Webpack and Rspack currently use `sass` and its Legacy API with
`sass-loader`.
There is also no method to pass stylePreprocessorOptions other than
`includePaths` to the loaders.
## Expected Behavior
Switch to using `modern-compiler` api to remove deprecation warnings and
improve build performance.
Allow users to choose between `sass` and `sass-embedded` for sass
compiler implementation.
Expand the `stylePreprocesserOptions` interface to accept
`includePaths`, `sassOptions` and `lessOptions` that will be passed to
the appropriate loader.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 updating from nx@20.0.12 to nx@20.3.0 our docusaurus dep starts
blocking us from running any nx command because of the error described
in the linked issue
```bash
The "nx/js/dependencies-and-lockfile" plugin threw an error while creating dependencies: Target project does not exist: npm:react-helmet-async@npm:@slorber/react-helmet-async@*
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Packages with such deps, like: `"react-helmet-async":
"npm:@slorber/react-helmet-async@*"` shouldn't break any nx command
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27285
This PR fixes project matching such that the name must match on `-` as
well. For example, given two projects with the following names:
- `@acme/foo`
- `@acme/foo-e2e`
Running `nx serve foo` shoud match `@acme/foo`. Currently it will error
out because it matches both projects.
## Current Behavior
Project names can partially match, so `foo` matches `@acme/foo-e2e`.
## Expected Behavior
Project names must match the segment fully, including `-`, so `foo` does
not match `@acme/foo-e2e`, but `foo-e2e` does.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Our Rspack support currently leverages `fork-ts-checker-webpack-plugin`
to handle typechecking during build.
## Expected Behavior
Switch to using `ts-checker-rspack-plugin` for better memory management
and typecheck support.
## Current Behavior
`parseRemotesConfig` is naively handling detection of remote output
paths needed for standing up the single file server.
## Expected Behavior
Provide better detection of remote output paths that covers inference
and executor usage with fallback behaviour
## Current Behavior
When multiple processes/tasks are running in parallel for a single
project that produce tmp tsconfig files for buildable libraries, they
can clobber each other.
## Expected Behavior
Ensure the config file is generated with a unique id to prevent
clobbering
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
-->
<img width="561" alt="image"
src="https://github.com/user-attachments/assets/b343bc83-6423-4924-8695-a621cf98be11"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes broken reporting on nightly caused by breaking changes in
the `upload-artifact` and `download-artifact` GH actions
## 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 #
Locally, when running `nx serve-docs nx-dev`, you'll see errors coming
from `/blog` URLs due to instrumentation problems. This is caused by the
`@grafana/faro-web-tracing` packages as soon as it is imported in an app
router environment.
We don't need it for now, so we can just remove it. It means that we
will be missing tracing on HTTP requests like XHRs, but we still get
performance metrics and error reporting.
## Current Behavior
See errors in logs during development
## Expected Behavior
No errors in logs
## 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 -->
Since statuses are generated dynamically based off of commands executed,
enforcing old statuses on Github will result in a "Waiting for status"
message which can block in progress PRs. The recommendation is then to
only enforce status checks on the default branch and not enforce any Nx
Cloud related status checks.
## Expected Behavior
<!-- This is the behavior we should expect 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
The `updateTsConfigsToJs` helper from `@nx/devkit` doesn't handle
tsconfig files without the `include` or `exclude` properties.
## Expected Behavior
The `updateTsConfigsToJs` helper from `@nx/devkit` should handle
tsconfig files without the `include` or `exclude` properties.
## Related Issue(s)
Fixes#30067
## Current Behavior
- The persistent tsconfig files cache used by the `@nx/js/typescript`
plugin does not get invalidated when the tsconfig files it extends from
are updated.
- Absolute paths are stored in the cache, which would be incorrect when
distributing the cache.
- The plugin throws a cryptic error when the lock file doesn't exist.
## Expected Behavior
- The persistent tsconfig files cache used by the `@nx/js/typescript`
plugin should get invalidated when the tsconfig files it extends from
are updated.
- Paths should be stored relative to the workspace root.
- The plugin should handle when the lock file is missing.
Additionally, a few other performance improvements were made to offset
the overhead introduced by creating a stricter cache key:
- cache and reuse file reads between tsconfig reads and file hashing
(now each file is only read once, if read at all)
- initialize a pre-populate tsconfig files cache in a first pass to skip
checking cache entries' key in subsequent reads
- reduce the tsconfig file cached content we store to disk
- cache the check for external project references
## Related Issue(s)
Fixes#29429
## Current Behavior
If the lock file is missing the `@nx/rspack/plugin` plugin throws a
cryptic error.
## Expected Behavior
The `@nx/rspack/plugin` should handle a missing lock file.
## Related Issue(s)
Fixes #
Fix a bug introduced in https://github.com/nrwl/nx/pull/29774.
## Current Behavior
If a local plugin's `tsconfig.json` uses `extends`, the referenced base
config is not loaded.
## Expected Behavior
If a local plugin's `tsconfig.json` uses `extends`, the referenced base
config is loaded.
## Related Issue(s)
Fixes#30007
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Revised the description across documentation, metadata, and SEO content
to emphasize Nx's AI-powered architectural awareness alongside its
monorepo optimization and advanced CI capabilities.
## Current Behaviour
Currently, Module Federation with Nx is forced to use executors to
provide the best DX.
## Expected Behaviour
As part of the transition to inferred targets, we will need Rspack
plugins that replicates the DX provided by our executors.
Add `NxModuleFederationPlugin` and `NxModuleFederationDevServerPlugin`
to handle this.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 when we generate a `.gitignore` file we include a help link to
http://help.github.com/ignore-files/ which is no longer a valid url.
## Expected Behavior
It should link to the new help link
https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29794
Replaced an instance of `<strong>` with `<Strong>` to maintain
consistent tag usage across the component. It ensures readability and
uniformity in the codebase styling.
## Current Behavior
Rspack v1.2.3 was released with some issues around resolving and
transforming modules throwing errors at build time.
## Expected Behavior
Pin Rpsack to 1.2.2 until a solution for the above problem can be
resolved.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
- call init generator using implementationFactory, causing issue because
schema.json file isnt respected, and then NX_INTERACTIVE is never set to
true
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- change back to run init command
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR includes updates to the `nxCopyAssetsPlugin` function in the
`packages/vite/plugins/nx-copy-assets.plugin.ts` file to improve asset
handling and daemon integration.
The most important changes include adding a check for
`NX_GRAPH_CREATION`.
Additionally, it also contains a check to ensure that before attempting
to watch for file changes the daemon should be available.
Improve the perf of the `@nx/js/typescript` plugin both in cold and warm
scenarios. The main changes done are:
- Batch some processing to do it once instead of doing it per config
file (avoids some duplicated processing)
- Use a custom TS host to read tsconfig files to reduce I/O operations
- Cache tsconfig files' reads
Benchmark results in a repo with 656 TS projects:
```
# Before the changes
Cold (NX_CACHE_PROJECT_GRAPH=false): ~2285 ms
Warm (NX_CACHE_PROJECT_GRAPH=true): ~2142 ms
# After the changes
Cold (NX_CACHE_PROJECT_GRAPH=false): ~597 ms
Warm (NX_CACHE_PROJECT_GRAPH=true): ~220 ms
```
Note: Once https://github.com/nrwl/nx/pull/29935 is merged. I'll send
another change to batch the file hashes.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
Vite config temp files can sometimes cause errors to be thrown by
ESLint.
## Expected Behavior
Vite config temp files should be ignored by ESLint.
## Related Issue(s)
Fixes #
Add a `watchDependencies` options to the relevant webpack executors and
plugins to allow opting out of watching buildable dependencies.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes#29961
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The project graph construction can throw an error when the lock is not
created:
https://github.com/nrwl/nx/issues/29821#issuecomment-2653007563.
## Expected Behavior
The project graph construction should correctly handle the nullable
lock.
## Related Issue(s)
Fixes #
The duplicate PDF file in the `docs/shared/features` directory was
removed. The updated version of `NxPowerpack-Trial-v1.1.pdf` is now
properly placed in the `public/assets/powerpack` directory.
This PR updates the Rspack Plugin to be inferred by default.
### Currently
When you generate a project using rspack it would not be inferred and
would add the executor to `project.json`.
### After
Generating a project using rspack will add it to inferred plugins inside
`nx.json` and update the `rspack.config.js` to be a standard config and
use Nx plugins.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
got this error:
```
NX Cannot read properties of undefined (reading '1')
TypeError: Cannot read properties of undefined (reading '1')
at fileDataDepTarget (/Users/emily/code/tmp/spring-boot/.nx/installation/node_modules/nx/src/config/project-graph.js:13:18)
at ProjectGraphBuilder.calculateTargetDepsFromFiles (/Users/emily/code/tmp/spring-boot/.nx/installation/node_modules/nx/src/project-graph/project-graph-builder.js:271:74)
```
this happens because the project in the dependency file is in format
like `:spring-boot-project:spring-boot-autoconfigure (*)`. need to take
out the text after space.
## Expected Behavior
<!-- This is the behavior we should expect 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
Currently there doesn't seem to be support for pnpm catalogs in the
dependency check which throws an error.
## Expected Behavior
Catalog should be supported and at least not throw an error since its a
default rule in some generators.
I noticed that also that only `workspace:*` was implemented so I added
the other possible options.
https://pnpm.io/workspaces#publishing-workspace-packages
I copy and pasted a test twice to add tests for this.
I mean ideally I guess we would check the `pnpm-workspace` file and say
is this catalog defined, I don't think that's up my ally for this
purpose and I'm not sure if how its implemented does that for the
workspace protocols as well.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
closed#29903, #29959
Gave it a shot, not sure if this is gonna be comprehensive enough. But
let me know! happy to try and get this right.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
Added the webinar notifier and related links to reflect the new date of
February 26th. Revised webinar description to emphasize new topics.
Reintroduced and adjusted UI references in enterprise hero section for
better event promotion.
## Current Behavior
Nx currently supports Vite at version 5. Nx does not generate vite
configurations using Vite 6 which has been released.
## Expected Behavior
Nx should use Vite 6 for vite projects.
## TODO
- [x] Add Package Update Migrations for Existing Projects
- [x] Add AST migrations to handle breaking change in resolve.extensions
- [x] Add migration to install `jsx` or `jiti` to handle processing TS
postcss config files
## Current Behavior
Generating a buildable Angular library results in a block for the
`@nx/dependency-checks` being added to the root ESLint Flat Config file
every time.
## Expected Behavior
Generating a buildable Angular library should not add a block for the
`@nx/dependency-checks` to the root ESLint Flat Config file. The
configuration is meant to be added to the project configuration, which
it already does.
## Related Issue(s)
Fixes#29970
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 errors were misaligned to the plugin index they pertained to.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The errors are not misaligned to the plugin index they pertain 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 -->
- there is no option `fallbackCurrentVersionResolver: 'disk',`
- can't run release for newly created publishable libraries
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- move code to add release for publishable libraries into its own file
to be reused by other stacks
- add `fallbackCurrentVersionResolver: 'disk',` to project's
release.version. generatorOptions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/29723
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #
When flat compat is necessary, we don't ensure that `@eslint/eslintrc`
is installed, even though we import it. Depending on the package manager
and hoisting, it may still work, but as we see with pnpm v10, it is not
working without an explicit dependency in `package.json`.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 app generators are broken is we use eslint compat.
## Expected Behavior
App generators should work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29845
Introduced the Monorepo AI Support component and its corresponding
illustration to the homepage layout. Also updated the necessary exports
for proper integration.
…800)"
This reverts commit a5f13a28b1.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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/playwright` is published with improper peer dependencies because
`nx release` does not support this apparently.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`@nx/playwright` is published with `dependencies` again for now.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/29921
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 there are multiple plugins using in a workspace, all the
configuration paths are collected and used as 1 giant glob to test
against the workspace context files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Each plugin configuration glob is now handled separately and are not
joined together into one giant one. This allows each glob pattern to
have separate files for each plugin.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29473
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
This PR updates `@nx/jest/plugin` such that `disableJestRuntime` option
is true by default. Users will need to set it to false to bring in
`jest-config` and `jest-runtime` to compute atomized targets. We're
leaving it as an option if anyone runs into discrepancies between our
calculation and what jest-runtime calculates for test files within a
project.
## Current Behavior
Jest runtime is used by default and is potentially slow if you use many
transforms, presets, etc. in the jest config.
## Expected Behavior
Jest runtime is not used by default, and users have to option of
enabling it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We currently still generate Vitest configuration using Vitest v1.
Vitest v3 has released so Nx is pretty far behind now.
## Expected Behavior
Update vitest version to v3 and use it to configure new projects.
Existing workspaces using v1 will continue to use v1.
This PR fixes some inconsistencies when generating a TS solution
workspace (e.g. `npx create-nx-workspace --workspace`).
If the user chooses `None` stack (or `--preset=ts`), then we continue to
default to no Prettier (and ESLint, etc.). However, for React, Vue, and
Node, we want the defaults to be useful for users to run lint, test,
etc. Thus, they are now updated the default does not opt out of any
tooling, but users can still choose no to any of them.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 defaults for React, Vue, Node are inconsistent (e2e runner is there
by default, but not unit test runner, etc.)
## Expected Behavior
Defaults are consistent and useful, especially for tutorials.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Revised FAQ and hero section to clarify that Nx Powerpack is included in
Nx Enterprise, replacing references to OSS licenses with trial-related
messaging.
This pull request contains a few changes to enhance our swc support for
Next.js with a custom server.
### Issues
Currently, we have a few issues with our configuration when using
executors for Next.js with a custom server:
1. The custom server does not have an independent build configuration.
2. The custom server does not have an independent output directory.
3. Serving via `@nx/next-server` or via `@nx/js:node` with
configurations `production` and `development` does not always work.
(These are contained inside `project.json`).
### Changes
All the above issues have been addressed
1. We now have an independent swc build configuration
called`.server.swrc` (_follows the same format as `.eslintrc`,
`.babelrc`_) etc...
2. Now each custom server output will be named `{app}-server` such that
if you have multiple custom servers for multiple apps the names will not
clash.
3. Serving now works out of the box but can be adjusted to suit your
needs via updating the custom server entry file `main.ts`
This PR fixes a couple of issues for TS solution setup:
1. Expo library should generate with correct `package.json` file (e.g.
`exports` maps either to source or dist). See [spec
file](https://github.com/nrwl/nx/pull/29891/files#diff-ae2eb3d10d58786c17aa21f5603043b68043faaebafaec77912f3d69ac0c5295).
2. Nest library should generate `package.json` when non-buildable. See
[spec
file](https://github.com/nrwl/nx/pull/29891/files#diff-368467bcd2215def98ef14aaff9dcb056a915b0a724d0eb857f3a0badef8b40a).
**Notes:**
- Also removed an unsupported `standaloneConfig` option from
`@nx/nest:lib` generator. This was removed a long time ago in other
generators.
- Expo lib generator isn't crystalized when using Rollup for build. This
is a separate issue and we'll handle it in another task.
## Current Behavior
- Non-buildable Expo libs generate without `exports`
- Buildable Expo libs fail to generate due to error
- Non-buildable Nest libs do not generate `package.json`
## Expected Behavior
Expo and Nest libs generate correct `package.json` files depending on
whether they are build or non-buildable.
## 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 weird errors which do not have a message get thrown, a weird error
gets thrown by Nx saying cannot read `split` of `undefined`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When weird errors which do not have a message get thrown, the weird
error is `console.error`ed
## 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 -->
`preTaskExecution` hooks used a revocable proxy to monitor updates to
`process.env` then revoking them. Apparently, this also prevents them
from being accessed afterwards which is definitely not intentional.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`preTaskExecution` hooks use a normal (non-revocable) proxy and restores
`process.env.` to the un-proxied 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 -->
Errors when processing the project graph still result in the project
file map being cached causing invalid information to be used when
recalculating the project graph.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The project file map will not be cached if there are errors calculating
the project graph. The dependencies of the graph will be recalculated
from scratch the next time Nx runs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When we run inferred Jest tasks with workspaces enabled, it'll result in
an error like this:
```
npm ERR! A complete log of this run can be found in: /Users/jack/.npm/_logs/2025-02-05T13_41_51_079Z-debug-0.log
Error: Command failed: npm config set //localhost:4873/:_authToken "secretVerdaccioToken"
npm ERR! code ENOWORKSPACES
npm ERR! This command does not support workspaces.
```
This is because the cwd is the project root (e.g. `packages/mypkg-e2e`),
and `npm config set` cannot be run on packages inside the workspaces. By
passing `--ws=false`, it'll only be run in the workspace root and won't
error.
## Current Behavior
Jest e2e tests inferred from `@nx/jest/plugin` fail when starting a
local registry.
## Expected Behavior
Jest e2e tests should work even if they are inferred (or have cwd other
than workspace root).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Revised the heading to highlight trust by OSS and Fortune 500 companies and added a new description paragraph. Simplified the button text and removed the video-related click handler for streamlined functionality.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Test Snapshot is failing
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Test Snapshot is updated
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Currently, calculating nodes via the `@nx/rspack/plugin` takes a long
time because the hash generation attempts to hash every source file.
This is problematic because the targets that are inferred do not rely on
the source files themselves and rather just the config file.
It also means the time taken to infer the targets grows as the project
grows.
## Expected Behavior
Calculate the hash based off the config file and the installed
dependencies, allowing it to scale as the project grows and allowing it
to be invalidated if dependencies change.
## Tested Results
Application with 90k files
Previous: 2mins
New: 1.18s
Updated all Nx Powerpack-related links across documentation and UI components to include UTM parameters. This enhances referral tracking and improves analytics for link performance across different sources.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #
Updates some generators to ensure the build tool produces the output
contained within the project root for the TS solution setup.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
The `@nx/eslint-plugin` main entry point is untyped.
## Expected Behavior
The `@nx/eslint-plugin` main entry point should provide types.
## Related Issue(s)
Fixes#28448Fixes#29816
Introduced a new "Hetzner Cloud Testimonial" component showcasing a featured client story with video support. The `video-modal.tsx` component was moved to `ui-common` for reuse, and the homepage was updated to display it while commenting out the previous "Trusted By" section.
This PR ensures that our init generators are hidden, such that they
don't appear in Nx Console when running generators, for example.
The init generator is meant to be used when running other generators,
like app or lib, and should not be run directly.
## Current Behavior
Init is not hidden
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Init is hidden
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
@nx/webpack and @nx/vite are used for a single migration but pollute the
overall dep size of someone using @nx/playwright without both vite and
webpack. This change allows users to only install the one stack they are
using.
Main fixes:
- Identify dependencies from packages that only expose named exports (no
`.` export)
- Identify dependencies from exports containing wildcards (e.g.
`"./utils/*": "./src/utils/*.js`)
- Disallow identifying dependencies from restricted exports (e.g.
`"./foo": null`)
- Handle conditional exports (e.g. `"exports": { "import":
"./dist/index.js", "default": "./dist/index.js" }`
- Handle invalid `"exports": {}` (by not falling back to `main`)
- Handle projects included or not in package manager workspaces
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes#29486
## Current Behavior
`nx test angular` fail on windows
## Expected Behavior
`nx test angular` to pass on windows
## notes
in
`packages/angular/src/generators/utils/storybook-ast/component-info.ts`
file I used `join(moduleFolderPath)` to convert it from always being `/`
to be OS separator
there are two other options I can do, but I don't have enough knowledge
to take the decision
1. to generate `moduleFolderPath` with OS separator instead of always
`/`
2. to make `candidateFile` to always be `/`
## Related Issue(s)
it might Fixes#22248
because now I see that when a new file is added, it's added to the end
of the tree, but when you reset it's then added to its place
also it explain why same code sometimes hit cache in windows, but miss
cache on linux, as the returned result different between the OSs
this should make sure that the returned result is always the same
---------
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 -->
`postTaskExecution` hook is only called if `preTaskExecution` hook is
exported in the plugin.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`postTaskExecution` hook should be independent from `preTaskExecution`
hook. I.e., if `preTaskExecution` hook is not exported,
`postTaskExecution` hook should still be called after a task execution.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Fixed `postTaskExecution` hook
Co-authored-by: Jonathan Cammisuli <4332460+Cammisuli@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 #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 we resolve the config file for rspack, it can be provided in a few
different formats:
```
config
config.default
config.default.default
```
We do not handle if the config is provided in any of the named default
methods.
## Expected Behavior
Handle named defaults for the resolved user config for Rspack.
Reproduction repo: https://github.com/olaf-cichocki/sample
## Current Behavior
When using mjs config file we end up with following error:
```
⚠️ Unable to construct project graph.
Failed to process project graph. Run "nx reset" to fix this. Please report the issue if you keep seeing it.
Failed to process project graph. Run "nx reset" to fix this. Please report the issue if you keep seeing it.
An error occurred while processing files for the @nx/rspack/plugin plugin.
- apps/appA/rspack.config.mjs: require() of ES Module /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs not supported.
Instead change the require of /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs to a dynamic import() which is available in all CommonJS modules.
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs not supported.
Instead change the require of /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs to a dynamic import() which is available in all CommonJS modules.
at resolveUserDefinedRspackConfig (/Users/miro/Dev/Testbox/sample/node_modules/.pnpm/@nx+rspack@20.2.0-beta.3_@babel+traverse@7.25.9_@module-federation+enhanced@0.7.6_react-dom@1_7iwdcl66l7me4m7pewq22wegge/node_modules/@nx/rspack/src/utils/resolve-user-defined-rspack-config.js:19:16)
at createRspackTargets (/Users/miro/Dev/Testbox/sample/node_modules/.pnpm/@nx+rspack@20.2.0-beta.3_@babel+traverse@7.25.9_@module-federation+enhanced@0.7.6_react-dom@1_7iwdcl66l7me4m7pewq22wegge/node_modules/@nx/rspack/src/plugins/plugin.js:65:98)
at createNodesInternal (/Users/miro/Dev/Testbox/sample/node_modules/.pnpm/@nx+rspack@20.2.0-beta.3_@babel+traverse@7.25.9_@module-federation+enhanced@0.7.6_react-dom@1_7iwdcl66l7me4m7pewq22wegge/node_modules/@nx/rspack/src/plugins/plugin.js:51:34)
at async /Users/miro/Dev/Testbox/sample/node_modules/.pnpm/nx@20.2.0-beta.3/node_modules/nx/src/project-graph/plugins/utils.js:10:27
at async Promise.all (index 0)
```
## Expected Behavior
Using EU module config files is supported
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Thank you @olaf-cichocki for reporting the issue.
## Current Behavior
The `@nx/js/typescript` plugin infers tasks with `--verbose`. This can
prevent users from running the same task with `--clean.` It can also
produce a lot of logs that might not be too relevant.
## Expected Behavior
The `@nx/js/typescript` plugin should not infer tasks with `--verbose`.
This is more aligned with other tools.
A new plugin option `verboseOutput` is added to allow inferring all
tasks with `--verbose` if desired.
Note: This revealed that some things were working (e.g., `dependsOn`)
because all the `typecheck` commands inferred by the different plugins
matched. As soon as the command is different, the different inferred
tasks are not merged, which is expected. We shouldn't rely on that, and
each plugin inferring the task should set the right options/metadata.
The different plugins were updated in this PR accordingly (they don't
have the verbose option).
We'll follow up on this later, so only the `@nx/js/typescript` plugin
infers the `typecheck` task. This is a breaking change so it will be for
Nx v21.
## Related Issue(s)
Fixes#28677
## Current Behavior
Our Module Federation Config allows passing tuple remotes:
```js
remotes: [
["remote1", "http://localhost:4201/remoteEntry.js"]
]
```
However, if the Module Federation system is expecting the remotes to be
loaded as Global variables in the browser, then we erroneously pass just
the url to webpack/rspack's `extractUrlAndGlobal` method.
This expects a string of format `name@url`. For non-tuple remote
configurations, we create this correctly.
However, when a tuple is passed, we simply return the url.
## Expected Behavior
We should ensure that the string is massaged to `name@url` even when a
tuple is provided.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 cache project report, it caches buildFileToDepsMap,
which is a map of build file to path of dependencies.txt
- however, when we try to read dependencies.txt in create dependencies,
it might not exist
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- read the dependencies.txt file when process project report to cache
- cache dependencies as processed project report result
- no need to read dependencies.txt in create dependencies
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Small fix for using
jest-runner-groups(https://www.npmjs.com/package/jest-runner-groups)
with Nx.
## Current Behavior
When running jest executor with extra group argument like:
```
nx run app-nebula-explorer-api:test --group=unit
```
`jest-runner-groups` runs all tests, not only from selected group.
From my investigation, `jest-runner-groups` using process.argv to
extract `--group` args
https://github.com/eugene-manuilov/jest-runner-groups/blob/3c9d3cf4cb3e595bdea733100f2bdc8d64f871d7/index.js#L57
and `process.argv` passed to runner contains:
```javascript
[
'M:\\programs\\nodejs\\22\\node.exe',
'M:\\projects\\someproject\\node_modules\\.pnpm\\nx@19.3.2_@swc+core@1.6.6_@swc+helpers@0.5.11_\\node_modules\\nx\\bin\\run-executor.js'
]
```
## Expected Behavior
Running jest executor with jest-runner-groups runner and `--group` args
should run only tests from group.
## PR changes summary
I implemented fix as generic and any extra arg will be added to
`process.argv` .
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
All of the TS source trees are unnecessarily traversed when a local
plugin is being registered.
## Expected Behavior
TS source trees are not unnecessarily traversed.
## Related Issue(s)
Fixes#29102 (see issue for more context)
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
`@nx/module-federation` is currently pinned to depend on
`webpack@5.88.0`. However, other Nx packages such as `@nx/webpack`
depend on a range of versions `^5.80.0`.
This leads to peerDep issues when package managers attempt to resolve
the packages.
## Expected Behavior
Change `@nx/module-federation` to depend on a range of versions.
`wepback@^5.88.0`.
## Related Issue(s)
Fixes#29682
The fallback path resolution was only happening if the resolvedFile was
a falsy value, so it was returning inexistent filepaths.
This pull request includes a small but important change to the
`packages/vite/plugins/nx-tsconfig-paths.plugin.ts` file. The change
improves the reliability of resolving file paths by checking if the
resolved path exists before proceeding with fallback file matching.
*
[`packages/vite/plugins/nx-tsconfig-paths.plugin.ts`](diffhunk://#diff-ad026b24ed45d9df484cabc7e277fc9b4d7759560af36bf357cbc4186725ae0bL174-R176):
Added a check to verify if the resolved file path exists before using
fallback file matching.
*
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 resolver doesn't resolve the full file path, it ignores the file
extension. For example, for a path like this:
`import mergeClassNames from '@projects/global/utils/mergeClassNames'`
It resolves to
`absolutePath.../projects/libs/global/src/utils/mergeClassNames`
When vite is building a project, it doesn't find the file and it errors.
This happens because the resolved file path is not a falsy value, thus,
it doesn't run the fallback file path matching.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
What is expected is that it resolves to (notice the file extension)
`absolutePath.../projects/libs/global/src/utils/mergeClassNames.ts`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
---------
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 -->
The current docker image being used cannot fetch chrome.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The new docker image can fetch chrome and pipelines can run.
## 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 tasks in parallel, we can set prefixes. However, there is no way
to label our prefixes with colors. Currently the only way is to set the
entire line to the color we want. This is not ideal as users may want to
keep the default colors for the logs and only want to use the prefix
colors as identifiers.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
PR to add this option
## Screenshots (Examples)
Tested with example screenshots below
### Before (v20.2.2 latest release)
<img
src="https://github.com/user-attachments/assets/dcc9b3fa-1977-4096-9dd2-3b111570c8cd"
alt="description" width="300" />
### This PR (local release)
<img
src="https://github.com/user-attachments/assets/6dc9eb3a-bc83-49cd-aad1-778b4f2eb354"
alt="description" width="300" />
## 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 -->
If I set `skipFormat` to `true` when creating a JS library with the
rollup bundler, formatting is still run during the rollup configuration
creation step.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`skipFormat` flag should be respected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
I have a project that is utilizing the `@nx-go/nx-go` extension that's
used for supporting Go applications.
When I attempt to use the `@nx/workspace:move` generator to move a Go
library, it'll produce an error. (Please refer to the _Failure Logs_
section for said error.)
Sadly, there isn't a consistent means to get the bun to start showing
up, but once it does, the issue will persist throughout the workspace's
life cycle.
I was able to trace this to the compiled Javascript files within Nx's
installed project files under the `node_modules` directory, which is
where I found a workaround. That being to have the
`secondaryEntryPointImportPaths` variable (located within the
`updateImports` function) set with an empty array on the same line it's
declared.
However, this will produce a `tsconfig.base.json` file at the root of
the workspace with the text `undefined` contained within it and with no
actual JSON to speak of.
## Expected Behavior
I have a project that is utilizing the `@nx-go/nx-go` extension that's
used for supporting Go applications.
The `@nx/workspace:move` schematic generator should be able to move
libraries based in Go and other programming languages without any errors
popping up.
It should also do it without generating an empty `tsconfig.base.json`
file if one didn't exist previously. This tends to be the case when
there is no Typescript to speak of within the Nx workspace. For example,
an Nx workspace initiated with the `@nx-go/nx-go` preset.
## Related Issue(s)
- [#28349](https://github.com/nrwl/nx/issues/28349)
Co-authored-by: Kerick Howlett <88661181+KerickHowlett@users.noreply.github.com>
## Current Behavior
Running Nx in multiple processes at the same time with the daemon
disabled can cripple a system due to excess memory usage when creating
the graph. This is due to plugin workers being started per-parent
process when there is no daemon. This change enables a file lock to
prevent the simultaneous processing, and read from the cache when the
first run completes.
Currently, running `nx show projects` 30 times in parallel looks
something like this:
30 processes exited within 37535ms
## Expected Behavior
30 processes exited within 6435ms
## Test Script
```js
//@ts-check
const { spawn } = require('child_process');
let alive = new Set();
let start = Date.now();
let iterations = 30;
for (let i = 0; i < iterations; i++) {
const cp = spawn('npx nx show projects', [], {
shell: true,
env: {
...process.env,
NX_DAEMON: 'false',
NX_VERBOSE_LOGGING: 'true',
},
});
alive.add(i);
// cp.stdout.on('data', (data) => {
// console.log(`stdout [${i}]: ${data}`);
// });
cp.stderr.on('data', (data) => {
console.error(`stderr [${i}]: ${data}`);
});
cp.on('exit', (code) => {
console.log(`child process ${i} exited with code ${code}`);
alive.delete(i);
});
}
const i = setInterval(() => {
if (alive.size > 0) {
} else {
clearInterval(i);
console.log(
`${iterations} processes exited within ${Date.now() - start}ms`
);
}
}, 1);
```
This PR fixes an issue with React 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#28245
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Removes the `node-fetch` dependency and uses the native fetch global for
the `isPackagerRunning()` check
## Current Behavior
- Dependency `node-fetch` is used.
## Expected Behavior
- Removed the `node-fetch` dependency.
- Used the native `fetch` global.
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
There is a bug when `outputFile` is specified in `playright.config.ts`,
and atomizer is enabled via `ciTargetName`, then the path of the output
file is wrong.
For example, if you have this reporters entry:
```
reporter: [
[
'junit',
{
outputFile: 'dist/report.xml',
},
],
],
```
Then the atomized output file would be something like
`dist/report.xml/example-spec-ts`, where `report.xml` is a directory.
The correct output file should be `dist/example-spec-ts/report.xml` to
avoid conflict with the non-atomized output of `dist/report.xml`.
## Current Behavior
If you run `nx e2e proj` then `nx e2e-ci proj` then you can run into an
issue where `report.xml` (or whatever the file name is) is a directory
in the cache, but it is a file currently -- or vice versa. This happens
due to the bug described above.
## Expected Behavior
The `outputFile` should never cause a conflict where a path should be a
directory but is currently a file, or vice versa.
## 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 -->
Left a log by accident.
`master` is broken because of migrations misalignment..
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Log is removed
migrations docs are aligned.
## 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 specific API for running things before and after tasks run.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR adds an API akin to npm's `preinstall` and `postinstall`.
Plugins can now specify `preTasksExecution` and `postTasksExecution`
functions which run before and after Nx runs tasks respectively.
```ts
import type { PreTasksExecutionContext, PostTasksExecutionContext } from '@nx/devkit';
interface PluginOptions {
field: any;
}
export function preTasksExecution(options: PluginOptions, context: PreTasksExecutionContext) {
console.log('prerun')
}
export function postTasksExecution(options: PluginOptions, context: PostTasksExecutionContext) {
console.log('postrun', context.taskResults)
}
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Reverts nrwl/nx#29577
There is an issue with workspaces using tsconfig path alias, and when an
invalid import is found, it'll match on the wrong package due to the
name matching the prefix.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
-->
Nx should install and depend on a version of express without security
vulnerabilities.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Co-authored-by: Igor Loskutov <igor.loskutoff@gmail.com>
Co-authored-by: Colum Ferry <cferry09@gmail.com>
- Fix server file location for the `@nx/remix:library` generator
- Do not error when generating a buildable Remix library in the TS
solution setup
- Install the correct versions of react-related packages when generating
a React library
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
Currently, the add-e2e.ts generator has redundant lines for the
webServerAddress and webServerCommand configuration when generating
Playwright configuration.
Produces `TypeError: Invalid URL` when running playwright tests on a
clean create-nx-workspace project.
## Expected Behavior
The generator should configure webServerAddress and webServerCommand
correctly. The changes fix the configuration generation for Playwright
tests.
## Current Behavior
`npx create-nx-workspace`, when fastify is chosen, generates fastify 4
boilerplate
## Expected Behavior
fastify bumped their major version, and many latest plugins require v5
(e.g. [cors](https://github.com/fastify/fastify-cors))
## Related Issue(s)
no
- the combination of versions works on my setup
- the combinations of versions is the latest at the moment
---------
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. -->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29514
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
## Current Behavior
After adding `@nx/detox` to a newly-generated project, Detox E2E apps
will either fail to build or run with intermittent crashes on Android.
## Expected Behavior
Detox E2E apps should run as they normally did with React Native
0.74/Expo v51.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
```bash
@coreproject-moe/monorepo@ /home/moonlitgrace/Projects/coreproject-monorepo
├─┬ @coreproject-moe/icons@0.0.65 -> ./packages/icons
│ └─┬ jest-config@29.7.0
│ └─┬ jest-circus@29.7.0
│ └─┬ dedent@1.5.3
│ └── babel-plugin-macros@2.8.0 deduped invalid: "^3.1.0" from node_modules/dedent
└─┬ @nx/js@20.0.5
└── babel-plugin-macros@2.8.0
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
No conflicts, without overriding `package.json`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28620
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 20.3.0-rc.0
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 20.4.0-beta.2
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Creating a new workspace does not prompt for the unit test runner.
## Expected Behavior
Creating a new workspace should prompt for the unit test runner.
For now, this new behavior will be behind the `--workspaces` flag.
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Running an e2e task using the `@nx/cypress:cypress` executor that starts
a dev server by running another task that uses the `@nx/js:node`
executor result in the process to hang after the e2e tests have finished
running.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The async generator returned by starting the dev server and consumed by
the `@nx/cypress:cypress` executor should be finished, and the
`@nx/js:node` executor should properly clean up its child process once
the generator is finished.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29571
This reverts commit c3709b2b84.
The change can result in tasks hanging when underlying processes are not
properly managed (can be processes created from third-party plugins or
user's code). A hanging task is a more serious issue than what this was
originally solving. We'll revisit this soon.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 our generators to no longer generate with `nx` in
`package.json` by default. The only times it is needed is if you pass
add `tags` or `implicitDependencies` to the project config.
This PR replaces our `projectType` checks to use the `getProjectType`
util from `@nx/js` to prefer the project config, but otherwise will
check for our conventions (e.g. using `exports` for libs,
`tsconfig.lib.json` vs `tsconfig.app.json`).
## Impact
- There shouldn't be any behavioral changes to existing projects that
have explicit `projectType`, `name`, etc. in with `project.json` or
`package.json` (via `nx` property).
- For new projects created under the new TS setup, the `nx` property
will no longer be there. Generators with logic that depend on
`projectType` will now check for `tsconfig.lib.json` and
`tsconfig.app.json` (so all of our generators are covered). If none of
those tsconfig files are found, then we check `package.json`, since
libraries are required to have `exports` to be consumed.
## Current Behavior
When using the TS solution setup and `jest` is used, `ts-jest` is used
as the transformer in most cases (except when the build compiler is
`swc`). The `ts-jest` transformer doesn't support modern module
resolutions like `nodenext` and it doesn't support TS project references
either.
## Expected Behavior
When using the TS solution setup and `jest` is used, `@swc/jest` should
be used as the transformer in cases where previously `ts-jest` was being
used and regardless of using `swc` as the build compiler.
## Related Issue(s)
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
When you run `nx run <lib>:test --watch` it only works correctly if
there are no failing tests. In case you have some failing test, the
process finishes immediately after all tests are finished.
## Expected Behavior
Watch mode should work the same as with Jest or when you use `vitest` on
its own.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
The logic seems to be broken with introduction of
https://github.com/nrwl/nx/pull/27722Fixes#28050
This PR fixes and issue where generating Nest app in the new TS setup
results in a build error due to missing `experimentalDecorators` option
in tsconfig. Decorators are required for Nest to work, but we do not set
it anymore in `tsconfig.base.json` by default.
## Current Behavior
Nest apps are broken
## Expected Behavior
Nest apps work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request includes changes to support multi-configuration mode
for both Rspack and Webpack.
## Currently
Currently our plugin only supports single configurations
```js
module.exports = {
...config
}
```
Which works in most cases but some applications can have mutliple
configs that serve different platforms.
## Changes
With these changes, the Webpack and Rspack plugins will also support
multi-configuration.
```js
module.exports = [
{ ...clientConfig },
{ ...serverConfig }
]
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
-->
Also includes update ENV variables
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Renames the NPM workspaces tutorial to TypeScript Packages tutorial and
updates the intro text a bit. The content is all still valid for ts
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
The root workspace package is not generated correctly when using Yarn v4
## Expected Behavior
yarn.lock should be created correctly
## Related Issue(s)
Fixes#29451
This PR is a prerequisite to removing `nx` property from `package.json`
files in the new TS setup. It fixes two issues:
1. We always write `nx` property in `package.json` even if it is empty.
This should be done for root projects.
2. Adding an entry to `pnpm-workspace.yaml` is not picked up because
`readProjectConfiguration` only reads the file from disk, not from
virtual `Tree`
This is the next PR to remove the property:
https://github.com/nrwl/nx/pull/29705
…ng 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 -->
## Expected Behavior
<!-- This is the behavior we should expect 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="1025" alt="Screenshot 2024-12-21 at 9 51 18 PM"
src="https://github.com/user-attachments/assets/32815566-c532-4186-bc94-4b017b0a84c2"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This pull request includes changes to migrate ESLint configuration files
from CommonJS (`.cjs`) to ECMAScript modules (`.mjs`) as the default.
### ESLint Configuration Generation Changes
The changes also ensure consistent generated eslint configs based on the
base eslint config.
- If the workspace root has an `eslint.config.cjs` or `eslint.config.js`
with `module.exports`. When you create a library or application it will
generate an accompanying config at path
`{projectRoot}/eslint.config.cjs` of the same format.
- If the workspace root has an `eslint.config.mjs` or
`eslint.config.mjs` with `export default`. When you create a library or
application it will generate an accompanying config at path
`{projectRoot}/eslint.config.mjs`.
- If no eslint config is found at the workspace root one will be created
`eslint.config.mjs`
## Current Behavior
We currently have no support for React 19, generating only React 18
applications.
## Expected Behavior
Add utils to determine what version of React is installed in the
workspace.
If React 18 is the main version of react installed, continue to generate
React 18 projects.
If React 19 is the main version of react installed, generate React 19
projects.
If no React version is installed or can be determined, generate React 19
projects.
## Current Behavior
When running the `configuration` generator from `@nx/playwright` and
`@nx/cypress` for existing appliactions - they currently generate a
config that is likely to be invalid becaue there is not enough
information to correctly assume the port, target and baseUrl for the
application.
This data is provided by the application generators that call the
`configuration` generator - but that means that users running it
manually must remember to pass the information via flags.
## Expected Behavior
If the serve data is missing, prompt the user to input the correct
information to ensure the config generation is as accurate as possible.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 initial version of the docs only allow the use of assignment rules
with Nx Agents.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The updated docs include an overview and example of how to configure
assignment rules to work with self provisioned agents (and DTE in
'manual' mode).
## 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 updates the `@nx/detox:app` generator to match the new TS
solution setup. The `@nx/cypress:configuration` and
`@nx/cypress:configuration` generators are also updated so that they can
be run on existing projects and generator the correct tsconfig files.
The Playwright/Cypress example can be seen as follows:
```shell
# Skip e2e
nx g @nx/react:app apps/demo --bundler vite --e2eTestRunner none
# now configure e2e
nx g @nx/playwright --project demo
```
Now if you add this line to `apps/demo/e2e/example.spec.ts`:
```
const x: number = 'a';
```
And run `nx typecheck demo`, it will pass. This happens because the
`e2e/**/*.ts` pattern is missing. Thus, we need to ensure that a
`tsconfig.e2e.json` project is added for the Playwright spec files. Same
thing with Cypress.
The Detox generator does not support adding configuration to existing
project, so we don't quite get the same problem. The fix for Detox is
just to make sure the tsconfig content is not following the old
(integrated) version, but the updated TS solution version.
## Current Behavior
Detox TS setup is incorrect. Running Cypress and Playwright
configuration generator on existing projects generate invalid setup,
such that spec files are not typechecked.
## Expected Behavior
E2E generators should all generate correct TS setup.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Generating a js library with esbuild or rollup as bundlers and vitest as
the unit test runner, results in an eslint configuration where the
bundler config file is not ignored from the `@nx/dependency-checks`
rule.
## Expected Behavior
Generating a js library with esbuild or rollup as bundlers and vitest as
the unit test runner, should result in an eslint configuration where the
bundler config file is ignored from the `@nx/dependency-checks` rule.
## Related Issue(s)
Fixes #
## Current Behavior
When generating a non-buildable js library in a workspace using the
integrated setup, a `package.json` file is generated.
## Expected Behavior
When generating a non-buildable js library in a workspace using the
integrated setup, a `package.json` file should not be generated.
## Related Issue(s)
Fixes #
…ts 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
The version generator option `updateDependents` is misspelled as
`updatedDependents` in one of the Nx release docs pages.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
n/a
Fixes #
## Current Behavior
<!-- This is the behavior we have today -->
Creating a new workspace using the TS solution setup always generates a
`tsconfig.base.json` with `module: nodenext` and `moduleResolution:
nodenext`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Creating a new workspace using the TS solution setup should generate a
`tsconfig.base.json` with `module: nodenext`/`moduleResolution:
nodenext` for Node stacks and `module: esnext`/`moduleResolution:
bundler` for Web stacks (React, Vue).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates our app/lib generators such that `package.json` files
generated have fields in idiomatic order.
e.g.
```json
{
"name": "...",
"version": "...",
"private": true,
"type": "module",
"main": "...",
...
"dependencies": { ... }
}
```
The import fields such as name, version, private, and type are at the
top. Dep fields that could be noisy are at the bottom.
## 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
-->
throw an error when `./gradlew wrapper` or `java -version` failed to
run:
<img width="949" alt="Screenshot 2025-01-09 at 5 33 38 PM"
src="https://github.com/user-attachments/assets/f0b99adc-ff80-4962-8dfe-c1ad11944cac"
/>
<img width="933" alt="Screenshot 2025-01-09 at 5 32 20 PM"
src="https://github.com/user-attachments/assets/11d2286a-cc04-48a0-9839-b67cc93d5cfc"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We currently have a `serveTargetName` that defaults to `serve` in the
`@nx/vite/plugin`.
This infers a `vite serve` command for the `serve` task to vite
projects.
While not incorrect, it could be abrasive for users coming from the
`vite` ecosystem to Nx.
The command to start the Vite Dev Server is `vite`, so we should infer
this.
`create-vite` also creates a package.json script with `"dev": "vite"`
meaning users are likely running `npm run dev`.
This creates two points of differences for vite ecosystem users.
## Expected Behavior
Deprecate `serveTargetName` in favour of `devTargetName` to more closely
align with lanugage from the Vite ecosystem.
Infer the command `vite` instead of `vite serve` for the `serve` and
`dev` 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 -->
We currently second guess our inactivity timer by checking if there are
any open connections. However, there's also a strong chance that plugin
workers will remain open as long as the daemon is open. This means the
daemon stays alive forever and the daemon never shuts down even though
it is inactive.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Instead of checking for open connections in general, the daemon server
will only check for open file watchers. Most Daemon client requests will
restart the server when sending messages so we can safely shut the
server down in most cases. The only case where shutting down the daemon
would cause a disruption is if a file watcher is registered. In those
cases, the daemon will not shutdown due to inactivity.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We currently set Subresource Integrity (SRI) on all scripts injected via
`HtmlRspackPlugin`.
This should be configurable.
## Expected Behavior
Expose an option to set SRI - mark false by default to match Rspack's
`HtmlRspackPlugin` behaviour
## Current Behavior
In Nx 20.2.0, the `ng-packagr-lite` executor stopped producing the
ESM2022 outputs and started producing the FESM2022 outputs. This was due
to the Angular Package Format (APF) dropping the ESM2022 outputs, which
was reflected in the upstream `ng-packagr` implementation. Due to this
change, the libraries' build time and memory increased compared to the
previous versions.
## Expected Behavior
The `ng-packagr-lite` executor should only produce ESM2022 outputs and
avoid running an extra step to bundle the outputs to produce the
FESM2022.
Given the `ng-packagr-lite` executor is not meant to produce publishable
artifacts, its output doesn't need to strictly comply with the APF and
can focus more on build performance.
## Related Issue(s)
Fixes#29519
This PR adds `build-deps` and `watch-deps` targets to buildable JS
projects to help with incremental builds.
A use-case for this is if an app (e.g. Vite React app) has buildable
dependencies that need to be rebuilt when they change.
Say, you create a React app and lib as follows:
```
nx g @nx/react:app apps/react-app --bundler vite
nx g @nx/react:lib packages/react-lib --bundler vite
```
And import `react-lib` inside the app.
```jsx
import { ReactLib } from '@acme/react-lib';
//...
return <ReactLib />
```
The user can then run:
```
nx watch-deps react-app
```
And then serve the app in another terminal:
```
nx serve react-app
```
Then whenever code is updated for a buildable dependency, it'll be
rebuilt and then reloaded in the app.
In the new TS solution setup, non-buildable libraries should still`type:
module`. This can lead to problem since ESM is used but the type will
default to CJS.
This PR also updates `nx sync` for TS references such that transitive
deps are not sycned by default, unless
`NX_ENABLE_TS_SYNC_TRANSITIVE_DEPENDENCIES=true` env var is setup.
Previously, the transitive deps are synced unless the env var disables
it. There isn't a good reason to enable it by default, and it is much
cleaner to not sync by default. This means that if we have libs `a`,
`b`, and `c`, where `a -> b` and `b -> c` dependency edges are formed,
then running:
```
nx sync
```
Will update `a/tsconfig.json` to contain refs to `b` but not `c`.
Whereas:
```
NX_ENABLE_TS_SYNC_TRANSITIVE_DEPENDENCIES=true nx sync
```
Will update `a/tsconfig.json` to contain refs to both `b` and `c`.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
`type` is missing
## Expected Behavior
`type: module` is set in `package.json`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Sub-errors are hidden when any project graph error is encountered. This
is detrimental, as things like "missing comma in JSON" get hidden and
make people think that Nx is broken, when in fact their config files are
invalid.
## Expected Behavior
Sub errors are shown regardless of verbose logging (but including their
stack trace if verbose logging is enabled)
### Without Verbose
### With Verbose
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When we have an inferred target command that matches the entry point of
the cli tool, there is a chance we do not replace package scripts
correctly
e.g.
```
{
"dev": "vite",
"build": "tsc -b && vite build",
"preview": "vite preview"
}
```
this could result in package scripts being updated to
```
{
"dev": "nx dev",
"build": "tsc -b && nx vite:build",
"preview": "nx dev preview"
}
```
## Expected Behavior
We should update the package scripts correctly to match the desired
inferred target
```
{
"preview": "nx preview"
}
```
<!--
_[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
## @klerick/nx-angular-mf
Custom builder for Angular projects designed to simplify the development
and production of microfrontend applications using native esm module.
The builder integrates with NX to provide seamless support for
development, testing, and deployment of Angular microfrontends.
## Features
- **Microfrontend Support**: Built-in support of native esm module with
dynamic imports them.
- **Server-Side Rendering (SSR)**: Improved SSR compatibility, including
custom module loaders and import maps.
- **Customizable Build Process**: Flexible options for managing
dependencies and extending build configurations.
- **Dev Server Enhancements**:
- Incremental hydration support.
- Dynamic `importmap` generation.
- Automatic dependency resolution and rebuilds.
- **Seamless NX Integration**: Fully compatible with NX workspace for
streamlined project management.
Improves our error handling for swc when using `@nx/js:swc` 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 -->
The executor fails to build if the workspace has a newer versions of
`@swc/cli` e.g.(`0.6.0`) is installed since it now uses stderr instead
of message to log errors.
RE: https://github.com/swc-project/pkgs/pull/53
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The executor should pass in this scenario.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29599
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 library with any bundler other than `vite` and with the
`vitest` test runner results in an explicit `test` task in the project
configuration.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Generating a js library with any bundler other than `vite` and with the
`vitest` test runner should not generate an explicit `test` task in the
project configuration. The `test` task should be inferred.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Introduced custom event tracking for ebook downloads and sales contact buttons using `sendCustomEvent`. Enhanced call-to-action designs by replacing links with `ButtonLink` components and adjusted styling and text for clarity. Updated webinar links and refined headings for consistency.
Re-enabled the `WebinarNotifier` component in the app layout and updated the webinar date and localStorage key to reflect the new event on January 22, 2025.
- Update React Native, React, Remix and Vue library generators to
produce `exports` in the `package.json` for the TS solution setup
- Fix an issue in `@nx/rollup/with-nx` where an unhandled `undefined`
plugin was causing an error to be thrown
- Fix output path of the build task for React Native libraries in the TS
solution setup
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 the new TS setup support to `@nx/web:app` generator.
Previously it errored out since it was not handled.
## Current Behavior
Cannot generate webapp in new setup/
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Can generate webapp in new setup
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Sibling dependencies that rely exclusively on subpath exports are
excluded from the dependency graph because there is no exact match.
This adds a fallback to look for subpath exports if the exact match is
not found.
This also adds logic to respect conditional exports independent from
subpath exports.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Importing a workspace dependency via subpath export fails to match the
package name, and so is not included in the dependency graph.
### Example
```apps/api/package.json```
```json
"name": "@my-org/api",
"dependencies": {
"@my-org/services": "workspace:*"
}
```
```libs/services/package.json```
```json
"name": "@my-org/services",
"exports": {
"./email": "./dist/email.js"
}
```
The `@my-org/api` app should be able to import the email service with
`import { EmailService } from "@my-org/services/email"`.
However, the `getPackageEntryPointsToProjectMap` implementation results
in an object with a key of `@my-org/services/email`, but not
`@my-org/services`. This is not specifically a problem, except that
`findDependencyInWorkspaceProjects` only considers exact matches within
those object keys.
## Expected Behavior
Importing a workspace dependency via subpath export should be included
in the dependency graph.
I also addressed a related issue where the following resulted in keys of
`@my-org/services/default` and `@my-org/services/types`, which is
incorrect according to the subpath/conditional export rules.
```json
"exports": {
"default": "./dist/index.js",
"types": "./dist/index.d.ts"
}
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29486
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
- Update project generators to add the project to the workspaces setup
in the new TS solution setup
- Update some library generators that were not running package
installation
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
The Module Federation `NxRuntimeLibraryControlPlugin` relies on an
environment variable that is set during the build/serve process.
This could potentially lead to issues with cache restoration.
The impact should be minimal as the runtime control plugin should only
be added to the module federation config when the env var is set.
It should only be set by the `module-federation-dev-server` executor
which is invoked during serve - a non-cacheable task already.
## Expected Behavior
Ensure the env var is set as an input to ensure maximum accuracy with
module federation builds via rspack 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 #
- Ensure libs are generated with `exports` in `package.json`
- Generate `types` instead of `typings` in package.json
- Update js lib with rollup to only output esm
- Update `tsconfig.spec.json` for js libraries with rollup to set
`module: esnext` and `moduleResolution: bundler` (they use `@swc/jest`)
- Fix `@nx/js/typescript` issue with absolute paths when normalizing
inputs/outputs
- Fix `@nx/js/typescript` issue identifying buildable libs
- Fix express app generator not installing `@types/express`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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>
Since we simplified `tsconfig.base.json`'s `compilerOptions` to not
include values that match defaults (as per Jake's feedback), the logic
to detect TS solution setup should check that `declaration` is
explicitly set to `false`, rather than that it is falsy.
Clean up PR: https://github.com/nrwl/nx/pull/29550
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 not detecting TS solution setup correctly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Detection 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When projects use only `package.json` and not `project.json`, we need to
set the simple name in the `nx` property of `package.json`. This isn't
ideal because it's yet another Nx-specific thing that needs to be
configured when our goal is to reduce boilerplate.
This PR allows users to pass a substring that matches exactly one
project when running a task.
For example, if `@acme/foo` is the name in `package.json`, then running
`nx build foo` will match it.
If more than one projects match, then an error is thrown showing all the
matched projects, and the user has to be more specific or type in the
fully qualified 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
Users need to pass exact matches for project names when running tasks.
## Expected Behavior
User can pass a substring matching the project name.
## 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 `rootDir` to check if the project is buildable. This
might not be correct in the case where the transpiled files are inside
source.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It should work the for projects as long as the main / exports files are
not source files.
## 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 #
migrates `@nx/jest` from `chalk` to `picocolors`
Part of https://github.com/es-tooling/ecosystem-cleanup/issues/117
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
It is not possible to pass custom cors headers to the
`@nx/web:file-server` executor despite `http-server` supporting it.
## Expected Behavior
`@nx/web:file-server` should pass-through a string of custom cors
headers to `http-server`.
## Related Issue(s)
migrates `@nx/angular` from `chalk` to `picocolors`
Part of https://github.com/es-tooling/ecosystem-cleanup/issues/117
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 option `ciGroupName` to the `@nx/jest/plugin` to allow customizing
the `Jest` atomized taks group on CI.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 Atomizer on Jest for **unit tests** (via the `"ciTargetName":
"test-ci"`), the atomized tasks will be grouped under the misleading
name **"E2E (CI)"**.
Worst, if Atomizer is enabled for both **unit** and **e2e** tests, it
will result on E2E atomized tasks being overwritten by the one from unit
tests... when run on Nx Cloud.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Allow customizing the name of the atomized tasks group. The group name
can be derived from the `ciTargetName` , when not explicitly provided.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28066
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
Default plugins are launched twice when loading plugins in a workspace
that has local plugins:
- Once to resolve the local plugin
- Once to be used as an actual plugin
## Expected Behavior
Default plugins are launched once and reused
## 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>
For the new TS setup, we currently use nested glob patterns: `apps/**`,
`libs/**`, and `packages/**`.
Nested paths can result into too many projects being matched. For
example, if `libs/mylib/src/__fixtures__/package.json` is there for
testing, it will be matched as a project and likely result in an error.
Other tools like turborepo also caution against this:
https://turbo.build/repo/docs/crafting-your-repository/structuring-a-repository#declaring-directories-for-packages
If users want to, they could change to nested `**` paths, but we should
not use it by default.
Note: For CNW, we only use `apps/*` by default since that is where the
project lives. When users do `nx g lib packages/foo` then `packages/*`
will be added automatically.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Use nested `**` paths.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Don't use nested `**` paths.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Simplify generated `tsconfig.base.json` file in the TS solution setup by
removing compiler options set to their default values.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 js libraries for bundlers `esbuild`, `swc`, and `tsc` to
produce ESM output when using the TS solution setup.
- Fix `esbuild` and `swc` executors so they generate declaration files
even when skipping type-checking.
- Add `cjs` and `cts` to the `ignoredFiles` pattern for the rollup
config file in the eslint config.
- Ensure running an install after a js library is generated when using
the TS solution setup.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 `@nx/playwright/plugin` to properly handle absolute paths set in
the playwright config to infer outputs correctly.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
We currently use version `0.7.6` of `@module-federation/enhanced`.
This version does not contain the `externalRuntime` experiment to reduce
the remoteEntry bundle size.
## Expected Behavior
Upgrade Nx dependency of `@module-federation/enhanced` to version
`0.8.8`.
This PR fixes an issue with React 19 and our `@nx/react/plugins/jest`
transform. The current transform uses an unsupported `$$typeof` symbol,
and also uses the deprecated `forwardRef` API.
The updated transform will use new API for React 19 and older, while
maintaining the previous API for React 18 and earlier. The backwards
compatibility may be needed if the test is using `ref`, which requires
`forwardRef` older versions.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
SVGR fails in Jest tests with React 19
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
SVGR 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
When the tsconfig has `rootDir` and `outDir` both defined, then the
`*.tsbuildinfo` file is not cached. This makes incremental tsc not work
through distribution (e.g. agents).
For example, given this `tsconfig.lib.json` file:
```json
{
"compilerOptions": {
"outDir": "out-tsc/lib-1",
"rootDir": "src"
}
}
```
The outputs (e.g. `*.d.ts` files) are under
`{projectRoot}/out-tsc/lib-1`, but the tsbuild info file is under
`{projectRoot}/out-tsc/tsconfig.lib.tsbuildinfo`.
## Current Behavior
tsbuildinfo file is not cached
## Expected Behavior
tsbuildinfo file is cached
## 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 -->
When there is a path mapping like:
```
"match-lib-deep/": ["libs/lib1/src/*"],
"match-lib-top-level": ["libs/lib2/src/*"],
"match-lib/*": ["libs/lib3/src/*"],
```
Imports to `match-lib-deep` or `match-lib-top-level` will try and use
the last `match-lib` path mapping as the trailing `/` is not accounted
for in the `startsWith` check.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The correct path mapping is matched.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A
library path corrected for storybook-host 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 #
This change omits references to implicit dependency tsconfigs for
typescript projects in the sync generator, since given that they are not
referenced directly in code there is no need for project references.
## Current Behavior
TypeScript sync generator adds references to any dependency project
which has a tsconfig (where composite is true), including implicit
dependencies where these references are unnecessary and can potentially
cause build failures.
See [example
repo](https://github.com/cogwirrel/nx-sync-generator-implicit-deps-example).
## Expected Behavior
Only explicit dependencies should be referenced in tsconfigs.
## Related Issue(s)
Fixes#28997
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Spaces in some places between word and backquote has been missed.
## Current Behavior
No spaces between formatted strings in some places.
## Expected Behavior
Spaces should appear between formatted string.
## Related Issue(s)
Not found any related issues. I have decided just create PR.
Replaced internal Nx Cloud links with full URLs containing UTM parameters for better tracking of user interactions across various components. Additionally, minor improvements were made to React type definitions for clarity and consistency.
Replaced the old `graphs.jpg` image with two new `.avif` images to support light and dark mode. Updated the component to switch between the light and dark neuron visuals based on theme.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Daemon spinner doesn't show up
## Expected Behavior
Daemon spinner shows 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 -->
- in serve target, it uses executor `@nx/webpack:dev-server`
- in `packages/webpack/src/executors/dev-server/dev-server.impl.ts`,
when buildLibsFromSource is false, it calls createTmpTsConfig to create
a temp config
- in webpack.config.js, it has `module.exports =
composePlugins(withNx()`. in withNx, it calls
NxTsconfigPathsWebpackPlugin.
- when buildLibsFromSource is false, it called createTmpTsConfig again
based on the temp config. it created an infinite loop because it creates
a tsconfig that extends itself.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- do not create a temp config if it is a generated ts config
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/28006
Original text was:
e.g. `nx@19.2.0` and `@nx/js@20.2.0` should be used together.
Surely it should be...
e.g. `nx@19.2.0` and `@nx/js@19.2.0` should be used together.
## Current Behavior
On a new workspace with nuxt preset (`npx create-nx-workspace@latest
--preset=nuxt`), a `tsconfig.json` file is create on the nuxt server
side directory (path: `apps/nuxt-test/src/server/tsconfig.json`). The
file extends the building nuxt server tsconfig file (path:
`apps/nuxt-test/.nuxt/tsconfig.server.json`) with the following value :
```json
{
"extends": "../.nuxt/tsconfig.server.json"
}
```
## Expected Behavior
This `tconfig.json` file generate need to extends the
`tsconfig.server.json` with the good path
Fixes #
The correct value is
```json
{
"extends": "../../.nuxt/tsconfig.server.json"
}
```
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 Plugin do not have the option to use Vitest as test runner
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR allow us to use Vitest as test runner in plugins projects.
Vitest for e2e targets is still missing and a new PR will be raised
after https://github.com/nrwl/nx/issues/29139 is fixed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22882
## Current Behavior
During the update to support Angular 19, the host and remote generators'
`updateSsrSetup` function was missed.
This led to the creation of a second `server.ts` file, which would
result in the node server trying to instantiate twice.
## Expected Behavior
Fix the path normalization dependent on angular major version to ensure
only one server will be instantiated.
## Related Issue(s)
Fixes#29442
Update the yarn-parser so that yarn.lock file generation works with yarn
v4
## Current Behavior
yarn.lock is not correctly created when using yarn v4
```
"":
version: 1.22.8
resolution: "resolve@patch:resolve@npm%3A1.22.8#optional!builtin<compat/resolve>::version=1.22.8&hash=c3c19d"
dependencies:
is-core-module: "npm:^2.13.0"
path-parse: "npm:^1.0.7"
supports-preserve-symlinks-flag: "npm:^1.0.0"
bin:
resolve: bin/resolve
checksum: 0446f024439cd2e50c6c8fa8ba77eaa8370b4180f401a96abf3d1ebc770ac51c1955e12764cde449fde3fff480a61f84388e3505ecdbab778f4bef5f8212c729
languageName: node
linkType: hard
```
## Expected Behavior
yarn.lock should be created correctly with no missing keys
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#19881
## Current Behavior
Spinners are not updated properly
## Expected Behavior
Spinners are updated properly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
After migration of existing remotes beyond Nx 19.8, dynamic manifest
federation files may be updated to match the normalized names of JS
variables (`_` instead of `-`).
Project names will not have been migrated, and therefore the logic to
find the projects based on the remote names is broken.
## Expected Behavior
Check the project graph for remote names as-is and by transforming `_`
to `-` to see if the project exists
## Current Behavior
Vitest TS config files produce timestamp temp files during project graph
creation which are cleaned up.
However, the creation and deletion of these files triggers the daemon to
recalculate graph.
It ends up in a loop.
The vite timestamp files were already added to the gitignore to prevent
this.
## Expected Behavior
Add vitest timestamp files to gitignore
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 passing a project name with a `/` in it to the library generator,
this name passes through to the `component` generator.
The `component` generator may then attempt to build a selector from this
name, however, it does not normalize the `/`.
## Expected Behavior
Ensure the `/` is normalized from the name when building the selector
## Related Issue(s)
Fixes#29229
closed#29411
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 resolve function from ts.System returning the full path, and so
including the workspaceRoot that is also append by the FsTree
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Resolution within node_modules are correctly followed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29411
## Current Behavior
The Rsbuild plugin is exported at `@nx/rsbuild/plugin`
## Expected Behavior
Export the plugin from `@nx/rsbuild` i.e. the root of the package.
## Current Behavior
The `@nx/module-federation` package is a direct dependency of some of
the other packages in the Nx Plugin ecosystem.
It should be resolved correctly by package managers such that it can be
used when setting up MF projects.
However, some users are facing issues with module resolutions where the
package is not found as expected.
## Expected Behavior
Install the package directly for the user to ensure module resolution
works as expected.
## Related Issue(s)
Fixes#29269
This PR updates our generators to use `eslint.config.cjs` instead of
`eslint.config.js` so that Node resolution will treat it as CommonJS.
This solves an issue where having `"type": "module"` in `package.json`
will result in an error when Node tries to resolve the config file as
ESM.
Also allows us to clean up out Remix generators to not have to rename to
`eslint.config.cjs` to solve the same issue.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 are excluding non-buildable libs from the
`@nx/js/typescript` plugin. Although that allows non-buildable projects
from have the build target being inferred it also as a side-effect
removes the `typecheck` target which is unintended. Additionally, to
breaks the pattern of being self containment that TS project solutions
brings as we were modifying the root `nx.json`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
1. Non-buildable libs should not have a build target.
2. Non-buildable libs should have the typecheck target.
3. Buildable libs remain unchanged and should have both a build and
typecheck target.
4. Remove the `exclude` from `nx.json` for non-buildable libs.
## 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 -->
Multiple workspaces using the cache directory is causing mismatches with
the db in the workspace data directory.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We don't need the separate cache directory so we'll go back to using the
default in the 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 -->
This PR address a few things:
1. When we generate an app or a library using the new TS Solution they
are not added to the workspaces/packages option.
2. Currently, when we use `pnpm` to generate a workspace the
`pnpm-workspace.yaml` looks like below which is not correct
```
packages:
- packages/**
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
1. Libraries and apps should be referenced correctly out of the box so
that they can be symlinked after installation.
2. The intended `pnpm-workspace.yaml` should look similar to:
```
packages:
- 'packages/**'
- 'demo'
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
## Current Behavior
We do not have a generator that can scaffold a react or vue app using
rsbuild.
## Expected Behavior
Update the react application generator to support a bundler option of
rsbuild
Update the vue application generator to support a bundler option of
rsbuild
We use `libs` a lot in our content, and use it ourselves in our own
monorepo. Some teams prefer it to `packages` so we should include it 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
For Nx plugins that use the the new TS solution setup, we need to
account for `generators.json`, `executors.json`, and `migrations.json`
pointing to `dist` rather than source.
This PR adds two options, `rootDir` and `outDir`, that allows the lint
rule to check the source files rather than depend on build artifacts.
The defaults are what we generate our plugins with.
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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: 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. -->
This is just a simple url update, you can observe the old url is no
longer valid because the structure of the git repo has changed
Co-authored-by: Michael Haas <michael.haas@futurewiseinsurance.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 a workspace is setup to use ts project references the move/remove
generators from `@nx/workspace` do not work correctly or result in an
incorrect state for the workspace.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This should work 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 -->
`./gradlew projectReport` is run everytime Nx calculates the graph.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Results of `./gradlew projectReport` are cached until gradle files have
been changed. This improves the performance of the gradle graph plugin.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Create a common task names concept page.
The main purpose of this page is to have a good search result for people
searching for "build", "test" or "lint" in our docs search. These terms
are regularly in the top 10 most searched terms.
Display the testimonial image associated to Hetzner Cloud on
enterprise's mobile screen. Adjusted styles and dimensions for improved
design consistency across breakpoints. Updated iframe dimensions to
better fit the layout.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 tries to install all plugins at once. if failed, it will stop the
remaining plugins from being installed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
it will continue if one plugin failed.
success message:
<img width="301" alt="Screenshot 2024-12-11 at 11 36 14 AM"
src="https://github.com/user-attachments/assets/2bc389f0-4fda-4959-afab-57594c9d600b">
failed message:
<img width="894" alt="Screenshot 2024-12-12 at 2 58 17 PM"
src="https://github.com/user-attachments/assets/7b51d5e9-f308-48c3-9b7d-bc4219802acb"
/>
## 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. -->
Sometimes graph computation can take longer than may be expected. In
these cases we can show a spinner, and if only one plugin is still
running **and the daemon is disabled** also show the plugin names.
Fix misc generation issues related to the new TS solution setup:
- Improve Cypress config default formatting (when no prettier)
- Remove leftover compiler options from `tsconfig.json` files
- Do not add TS path mappings
- Update `outDir` for `typecheck` tasks to be `out-tsc/...`
- Generate Nx configuration in `package.json` files for e2e test runner
projects
- Fix issue with `@nx/js:library` and `--bundler=vite`
- Other smaller changes
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #
Introduced a modal feature to allow video playback for the Hetzner Cloud
customer testimonial. Adds tracking on play button clicks and
integrating analytics events. Updated styles, improved accessibility,
and replaced `img` with Next.js `Image`.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 have a monorepo with ~450 packages and run tasks with 16x parallelism
in CI. We've recently noticed that running tasks with `static` logging
can lead to random tasks losing logs. Even if the task is a simple `echo
SOMETHING`, logs get lost sporadically.
After digging into the task runner, I found that the forked task runner
currently collects logs from `stdout` and `stderr`, then joins those
when the process `exit` event is emitted. The problem appears to stem
from the fact that the `exit` event is _occasionally_ emitted _before_
the `stdout` and `stderr` streams are closed, leading to lost logs.
## Expected Behavior
_All_ logs should be collected, even if they are emitted after the
process `exit` event.
I've updated the task runner to wait for the `stdout` and `stderr`
streams to end before collecting logs.
Note: I didn't see any tests specifically for this file, but it should
still run all the new code if theres is a happy path case of forked
tasks with static logging.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #
Moved the external script loading logic to a dynamic handler triggered
on route changes using `useEffect`. This ensures the script is reloaded
with each route change and prevents duplicates by removing any
pre-existing 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 -->
When using package manager workspaces and having a dependency between
buildable projects that define their entry points in the `package.json`
to point to the outputs, the imports from source files can't be resolved
to the corresponding workspace project.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using package manager workspaces and having a dependency between
buildable projects that define their entry points in the `package.json`
to point to the outputs, the imports from source files should be
resolved to the corresponding workspace project.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
```sh
nx build app --development
```
should be
```sh
nx build app --configuration development
```
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 -->
Local Nx plugins in the new TS setup can't be resolved properly if they
aren't built first. Graph plugins can't be built either because the
graph is needed to run a task, but the plugin must be built to construct
the graph.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Local Nx plugins should work in the new TS setup. A custom resolution is
added to resolve the local plugin artifacts from the source.
It will try to use a `development` condition from the `exports` entry in
`package.json` if it exists. If it doesn't, it will fall back to guess
the source based on the artifact path and some commonly known/used
source dirs: `.`, `./src`, `./src/lib`.
## 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
Migration fails if polyfills is a string
## Expected Behavior
Migration should work even if polyfills is a string
## 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 #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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>
Use `basename` for retrieving the filename in `findFile` function from
`nx-tsconfig-paths.plugin` that previously led to an unresolved error
for files with dot suffixes e.g.`/dir/file.suffix.ext`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
For files that have the same name but one of them has a suffix, e.g.
```ts
- lib1
- file.ts
- file.i18n.ts
- apps
- app1
- main.ts
- tsconfig.base.json // with { "paths": { "@lib1/*": ["lib1/*"] }}
```
The resolving process is incorrect because the `import value from
'@lib1/file.i18n'` from `apps/app1/main.ts` every time resolves to
`file.ts,` and the `parse` method from the `node:path` splits away the
suffix from the name.
## Expected Behavior
`import value from '@lib1/file.i18n'` should work correctly if you
import them from another package
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27852
---------
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 #
Co-authored-by: Hassan Khan <h@twodoors.dev>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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/27954
## Current Behavior
Nx currently does not offer a generator to help scaffold configuration
for an Rsbuild project
## Expected Behavior
Add a `configuration` generator to the `@nx/rsbuild` package to help
scaffold a configuration for a basic app
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`withReact` in `rspack` adds svg rules to support svgs as assets/urls
and React components.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Svgr docs use `url` as resourceQuery value,
https://react-svgr.com/docs/webpack/#use-svgr-and-asset-svg-in-the-same-project
Having resource query match on `react` is confusing because you would
want the inverse, treat the url as a resource if it has the query and as
a React component otherwise.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #
For Angular > 18 schema hmr option was ignored, it was impossible to
disable hmr and default value changed in ng19
https://github.com/angular/angular/issues/59058
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 #
I would like to be able to use rollup.config.ts. Same way it's used by
rollup and vite teams too.
## Current Behavior
Currently nx plugin does not reconize project containing
rollup.config.ts. It expects only {c|m}js files
## Expected Behavior
When project has rollup.config.ts rollup plugin infers build target
automatically. This build target should be able to find the
rollup.config.ts. For that purpose a special [configPlugin
](https://rollupjs.org/command-line-interface/#configplugin-plugin)CLI
parameter should be used
## Related Issue(s)
Feature request [#28226](https://github.com/nrwl/nx/discussions/28226)
---------
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 -->
This repo uses Nx `20.2.0-beta.7` and Powerpack `1.1.0-beta.6`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `20.3.0-beta.0` and Powerpack `1.1.0-beta.9`
## 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/28802
Fixes a couple of things:
1. React application should ignore `eslint.config.js`,
`eslint.config.cjs`, and `eslint.config.mjs` files since they are not
part of the app runtime.
2. React lib generators should always run `npm install`. It currently
runs only when `package.json` has changed, but we need to run it to link
packages regardless of `package.json` changes.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
The new `@nx/rsbuild` package is not listed as part of the Nx package
group.
This can lead to issues with reporting and migrations.
## Expected Behavior
Ensure `@nx/rsbuild` package is listed in the packageGroup
- Updates the list of champions
- Restyles that champions list to be shown in a grid, rather than a
masonry layout (so that the champions list can be a single list and not
manually balanced between 3 arrays)
- Randomizes the champions list on page refresh so different champions
are shown at the top
## Current Behavior
`@nx/vite:vitest` generator does not provide Angular support in the
`uiFramework` options.
## Expected Behavior
`angular` option should generate the vitest configuration just like
`@nx/angular:application` and `@nx/angular/library` do.
The `removeSvgLoaderIfPresent` method in `apply-react-config.ts`
iterates through each Webpack rule, calls `toString` on each `test`
property, and checks for the presence of the string `"svg"` to see if
any existing SVG plugins need to be removed.
Some of the Webpack rules in the config don't have the test property,
and calling `toString` without asserting the test property is defined
first throws type errors.
This commit introduces a very small change that simply asserts that
`rule.test` is not `undefined` before calling `.toString()`.
## Current Behavior
Running a React Webpack library with `svgr` enabled causes compilation
errors.
<img width="1171" alt="Screenshot 2024-08-20 at 10 36 09 AM"
src="https://github.com/user-attachments/assets/cb28d1ca-10d2-4d20-aa78-e69339a8273b">
<img width="487" alt="Screenshot 2024-08-20 at 10 39 28 AM"
src="https://github.com/user-attachments/assets/c170e0d8-8674-43b0-97a3-a5dffd398c17">
## Expected Behavior
Enabling SVGR in the `NxReactWebpackPlugin` config should compile as
normal.
---------
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 plugins in `nx.json` are changed, the daemon can no longer
communicate with plugin workers and create the graph. It will just hang
waiting for messages to go through.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Proper cleanup is done when plugins in `nx.json` are changed and the
daemon continues responding properly with project graphs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`@nx/module-federation` is not listed in the `nx` package's
`packageGroup`.
This reports it incorrectly in `nx report` and can impact `nx migrate`.
## Expected Behavior
`@nx/module-federation` should be listed in the `packageGroup`
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
createNodesV1 is used during init
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
createNodesV2 is used during init
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Based on PR #28091
… output<!-- Please make sure you have read the submission guidelines
before posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 `startLocalRegistry()` always assumed that the local registry was
started on `localhost` , which is not necessary the case, if for example
user has set the `listenAddress` option in the underlying `verdaccio
executor` or via the `verdaccio config
file`https://github.com/nrwl/nx/blob/128778e7d1a8d7f2b078b2401d47270c0c15a2ce/packages/js/src/executors/verdaccio/verdaccio.impl.ts#L130
As a result the `startLocalregistry()`, will never return as, it is
waiting forever to detect the local registry URL in the process output:
https://github.com/nrwl/nx/blob/128778e7d1a8d7f2b078b2401d47270c0c15a2ce/packages/js/src/plugins/jest/start-local-registry.ts#L40
This customization of `verdaccio` listen address is something required,
namely when running within a **devcontainer**. In that case, the address
must be set to `0.0.0.0`, so that the registry can be accessed from
`http://localhost:4873` from host machine.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Allow customizing the `listenAddress` when starting the local registry,
via an additional option that can be provided when calling the method.
It default value will be `localhost`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/28238
## Current Behavior
There is currently no way to execute Rsbuild targets via Nx.
## Expected Behavior
Add a `@nx/rsbuild/plugin` to infer targets based on the
`rsbuild.config` files in the workspace.
Also add an `init` generator to allow for `nx init` in existing rsbuild
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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29276
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 migration to remove Angular ESLint rules that were removed in v19
does not handle these rules in the root eslint config files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The migration to remove Angular ESLint rules that were removed in v19
should handle these rules in the root eslint config files.
## 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 #
BREAKING CHANGE
When generating projects that use Vite, the Vite configuration will be
set to use the ESM format only. Previously, the configuration was set to
produce both ESM and CJS, but the dual format was not correctly
configured in the libraries' `package.json` files, nor was it producing
the correct declaration 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 #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-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 when react native generators are used. They won't exclude
`.test` extension files.
## Expected Behavior
React native generators should exclude `.test` files in tsconfig lib
## Related Issue(s)
Fixes #
Co-authored-by: vivek ajage <vajage@signifyhealth.com>
## Current Behavior
When envs are not set metro fails in `.babelrc.js` on
`process.env.NX_TASK_TARGET_TARGET.includes('storybook')`
## Expected Behavior
When envs are not set don't fail on the if and just precede.
If we are using the new TS setup we should opt out of doing type
checking during build since we already have a typecheck target and it
may lead to doing type checking twice.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Hashing files via the workspace context sometimes resulted in a falsely
identical hashes when files are renamed.. but remain in the same order
alphabetically. This should be somewhat rare and most likely other
changes would accompany the rename which would change the overall hash.
This hashing was not used in task hashing though so it would not affect
that.
Debugging hashing inconsistencies is currently difficult as there is an
overload of logging:
<details>
```sh
~/p/nx-test (master↓24|✔) [1]$ NX_NATIVE_LOGGING='nx::native::tasks::hashers::hash_workspace_files=trace' NX_DAEMON=false nx lint nx
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/nx.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.gitignore
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.nxignore
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/nx.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.gitignore
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.nxignore
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/babel.config.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.nx/workflows/agents.yaml
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.circleci/config.yml
TRACE nx::native::tasks::hashers::hash_workspace_files: ".circleci/config.yml" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "babel.config.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml"]
TRACE nx::native::tasks::hashers::hash_workspace_files: ".gitignore" was found with glob ["nx.json", ".gitignore", ".nxignore"]
TRACE nx::native::tasks::hashers::hash_workspace_files: ".nxignore" was found with glob ["nx.json", ".gitignore", ".nxignore"]
TRACE nx::native::tasks::hashers::hash_workspace_files: ".gitignore" was found with glob ["nx.json", ".gitignore", ".nxignore"]
TRACE nx::native::tasks::hashers::hash_workspace_files: ".nxignore" was found with glob ["nx.json", ".gitignore", ".nxignore"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "nx.json" was found with glob ["nx.json", ".gitignore", ".nxignore"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "nx.json" was found with glob ["nx.json", ".gitignore", ".nxignore"]
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/babel.config.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.nx/workflows/agents.yaml
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.circleci/config.yml
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.eslintrc.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/tools/eslint-rules/**/*
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/babel.config.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.nx/workflows/agents.yaml
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.circleci/config.yml
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/nx.json
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.gitignore
TRACE nx::native::tasks::hashers::hash_workspace_files: Workspace file set: {workspaceRoot}/.nxignore
TRACE nx::native::tasks::hashers::hash_workspace_files: ".circleci/config.yml" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: ".eslintrc.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "babel.config.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/index.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/jest.config.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/project.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/raw-file-parser.js" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/rules/ensure-pnpm-lock-version.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/rules/valid-command-object.spec.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/rules/valid-command-object.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/rules/valid-schema-description.spec.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/rules/valid-schema-description.ts" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/tsconfig.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/tsconfig.lint.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
TRACE nx::native::tasks::hashers::hash_workspace_files: "tools/eslint-rules/tsconfig.spec.json" was found with glob ["babel.config.json", ".nx/workflows/agents.yaml", ".circleci/config.yml", ".eslintrc.json", "tools/eslint-rules/**/*"]
```
</details>
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Hashing files via the workspace context no longer produces falsely
identical hashes when files are named.
Debugging hashing inconsistencies is better now. It produces the hash
and the file it is adding to the workspace file hashset in the order
which it is added. Different filesets are still handled in parallel with
one another so the logging is best filtered through `grep` for a
particular fileset:
<details>
```sh
~/p/nx (hash-logging|✔) $ NX_NATIVE_LOGGING='nx::native::tasks::hashers::hash_workspace_files=debug' NX_DAEMON=false nx lint nx | grep "nx.json"
DEBUG nx::native::tasks::hashers::hash_workspace_files: Hashing workspace fileset{cache_key="nx.json,.gitignore,.nxignore"}: Adding "5069375034190792089" (".gitignore") to hash
DEBUG nx::native::tasks::hashers::hash_workspace_files: Hashing workspace fileset{cache_key="nx.json,.gitignore,.nxignore"}: Adding "10752854809791558346" (".nxignore") to hash
DEBUG nx::native::tasks::hashers::hash_workspace_files: Hashing workspace fileset{cache_key="nx.json,.gitignore,.nxignore"}: Adding "9876981562233255395" ("nx.json") to hash
DEBUG nx::native::tasks::hashers::hash_workspace_files: Hashing workspace fileset{cache_key="nx.json,.gitignore,.nxignore"}: Hash Value: "12458994942476116599"
```
</details>
## 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 -->
Artifact generators don't handle consistently receiving a file extension
in the `path` option.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Artifact generators should handle receiving a file extension in the
`path` option. If the file extension is passed, the file path will be
treated as "complete" and used fully as provided. If the `path` provided
doesn't contain a file extension, the default extension will be appended
to it (or the one provided in a related option, e.g. `--language`,
`--js`, etc) together with the suffix for generators that use it.
## 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 db cleanup handler does not exit the process and thus does not
handle `SIGINT` properly.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nx processes handle SIGINT properly.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This commit removes the ShaderGradientElement and its associated
functionality from the Hero component, reducing complexity and
dependencies. The return type of the Hero component is also updated for
consistency. These changes lead to a more streamlined codebase with
potentially fewer runtime considerations and increase client
compatibility.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 fail to release with the new typescript version
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Docs can be released and release flow can be tested via `--dryRun`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Corrected a typo in a job title and removed redundant GDPR information
across multiple components. Enhanced the sales team section with new
imports and testimonials to improve visual appeal and clarity.
---------
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 #
## Current Behavior
The `storybook` package is required to be installed to correctly find
paths correctly.
It acts almost like a shim.
It was not being installed for non-crystal workspaces
## Expected Behavior
Ensure `storybook` is installed
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 import to a path where is not in the workspaces, it currently
just shows a warning. however, it will cause an error like "module not
found" because there are packages not installed.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- automatically add to the workspaces
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Storybook 7 requires `react` and `react-dom` to be installed as they are
peer deps of the storybook package.
Storybook 8 does not require these deps to be installed as they are now
bundled correctly into storybook
## Expected Behavior
When user's version of storybook < 8, install `react` and `react-dom`,
otherwise, do not.
## Related Issue(s)
Fixes#29213
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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
We do not currently have a package or plugin to officially support
Rsbuild (http://rsbuild.dev)
## Expected Behavior
We should have a package to manage Rsbuild support
This update introduces a revamp to the Nx Enterprise page. The code
changes involved the addition of new image files, amending several
components for improved UI/UX. This refactor also includes an alteration
to the Call-to-Action section and an introduction of a new Carousel
component for better navigation. These adjustments aim to provide an
improved user experience and enhanced readability.
---------
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 #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the 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 -->
Some gradle tasks are not real tasks. They exist in `tasks.txt` because it is derived from subprojects should not be a real target for that project.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Gradle projects only have real gradle tasks which are not derived from their subproject tasks.
## 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/28865
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Only targets using `tsc` trigger the `@nx/js:typescript-sync` generator
to run.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Generating projects with other bundlers should also infer the
`@nx/js:typescript-sync` generator in their relevant targets.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
2024-12-05 17:42:16 +01:00
3520 changed files with 478683 additions and 34945 deletions
echo "Skip E2E tests for macOS as there are no changes in React Native projects."
fi
no_output_timeout:45m
- run:echo "We are in the process of transitioning from Circle CI to GitHub Actions. For details about your build results, consult github actions build logs."
If `nx report` doesn't work, please provide the name and the version of your package manager.
You can get version information by running `yarn --version`, `pnpm --version` or `npm --version`, depending on the package manager used.
You can get version information by running `PACKAGE_MANAGER --version`, where PACKAGE_MANAGER is any of `yarn`, `pnpm`, `bun` or `npm`, depending on the package manager used.
Nx is a build system, optimized for monorepos, with plugins for popular frameworks and tools and advanced CI capabilities including caching and distribution.
Build system, optimized for monorepos, with AI-powered architectural awareness and advanced CI capabilities.
description: "Learn how to scale your CI pipeline using two distribution strategies: binning for workload distribution and Nx Cloud's distributed task execution for optimal performance."
---
As your Nx workspaces grow, running CI on a single agent becomes unworkable. Nx's code change analysis and computation caching allows you to do the minimum amount of computation needed to verify that the PR is good to merge, but it only helps with the average case CI time. No matter how smart Nx is, in the worst case you need to rebuild/retest everything. **That's why any sizable workspace has to distribute CI across multiple agents.**
In this post we look at two ways to do that.
## Approach 1: Binning
Binning is an approach to distribution where the planning job divides the work into equally-weighted bins, one for each worker job. Then every worker executes the work prepared for it.
Nx has always provided affordances to do that, and many workspaces took advantage of it. Most of the setups look similar. This is an [example of implementing binning using Azure Pipelines](/ci/recipes/set-up/monorepo-ci-azure).
The planning job invokes _print-affected_. This command executes the same logic as _"affected:\*"_ but instead of running the tasks, it returns the tasks' descriptions. The job invokes this command for each target such as build/test/lint/e2e. After that, each worker agent runs the tasks assigned to it.
Binning is very common. For instance, [the CircleCI support for running tests in parallel](https://circleci.com/docs/2.0/parallelism-faster-jobs/) uses binning.
We at Nrwl helped many large companies distribute CI using different variations of binning. It works reasonably well for simple cases, but not without issues.
## Issues with Binning
### Binning doesn't partition the work in the optimal way.
First, you cannot partition tasks into bins without knowing how long every task takes. Most binning solutions collect timings (including the one in the Azure example above) which works imperfectly.
Second, when using binning you split tasks of the same type: some agents run tests, some agents run lints. If you have a fixed set of agents, you often have a situation where one group of agents (say executing lints) finishes before the other group (say executing tests). **You cannot balance them well.**
Additionally, you have to clone the repo and restore installed dependencies three times, consequently: once for planning, once for testing, and once for deployment. If this step takes 3 minutes, you have a 9-minute setup cost.
### Binning splits semantic commands into many chunks.
If you partition your tests into five bins, you have five agents with separate log files. When some of them fail, you have to go through all the logs to see what has happened. Even though this is not a deal-breaker, in a large workspace with dozens of agents executing every CI run, this becomes a real issue.
More importantly, you often need all the file outputs for a given target on the same machine to do post-processing. For instance, **you can run the tests on 5 agents, but you need all the coverage reports in the same place to combine them and send them to SonarQube.** Doing this is challenging.
### Binning doesn't work for builds.
Any time you run a command in a monorepo, Nx creates a task graph, which it then executes.
**The biggest limitation of binning is that it only works when the task graph is a list.** The moment you have dependencies between tasks, you have to distribute tasks dynamically using some sort of coordinator, move the needed files between agents and so forth.
This is common when you have libraries that depend on other libraries.
In this example, the Child 1 and Child 2 libraries have to be built first. Parent 1 can start only when Child 1 has been built because it needs the Child 1's dist folder. Parent 2 has to wait for both Child 1 and Child 2. And they can all be built on different agents, so their dist folders will have to be moved from agent to agent. You cannot implement it using binning. This problem also occurs for tests that require the libraries or applications to be built first.
That's why you often see tool authors talking about distributing tests and not builds. **Distributing tests is relatively straightforward. Distributing builds is hard.**
### Binning complicates CI/CD Setup.
Maintaining a CI setup that uses binning is often an ongoing effort. Because you don't have a proper coordinator, your CI has to be the coordinator, which complicates things.
We at Nrwl are in the business of helping companies use monorepos, so we have been dealing with these issues for many years. Nx Cloud 2.0's support for Distributed Task Execution is our solution for this problem. It solves all the problems listed above and more.
## How Does Distributed Task Execution Work?
This is an example CircleCI configuration that runs all commands on a single agent.
As you can see there is not much that changed. We added the agent job, registered it 3 times, added the `NX_CLOUD_DISTRIBUTED_EXECUTION` env variable, and added an extra step to stop all the agents. That is it.
**What happens when it runs `nx affected --build`?**
It won't run the build locally. Instead, it sends the Task Graph to Nx Cloud. Nx Cloud Agents pick up the tasks they can run and execute them.
> The Nx Cloud agents here are CI jobs that run `npx nx-cloud start-agent` so they can can be defined in any CI env.
This happens transparently. If an agent builds `app1`, it fetches the outputs for lib if it doesn't have it already.
As agents complete tasks, the main job where you invoked `nx affected --build` l starts receiving created files and terminal outputs.
After `nx affected --build` completes, the main job has the built artifacts and all the terminal outputs as if it ran it locally.
Let's reexamine the issues above to see how we addressed them.
### Nx Cloud partitions the work in the optimal way.
In theory every agent could pull one task at a time to partition things evenly, but it doesn't work well in practice. The network overhead can add up for very small tasks, and it's often faster to run several tasks in parallel because of the batching capabilities Nx has.
As you run commands in your repo, Nx Cloud collects the timings and uses those to partition the work into well-sized batches, such that if one agent is slow, the CI isn't blocked. Agents also run tasks of different types (tests/lints), so the pool of agents is shared evenly.
### Nx Cloud does not split commands.
To stress one more time the main job contains all the terminal outputs and all the files from all the tasks that ran on the agents, as if it ran locally. There is one place to look for errors. The created Nx Cloud run will contain all the information from all the agents.
**Finally, because all the files are copied into the main job, you can combine any outputs in post-processing steps, in exactly the same way you did it before enabling distribution.**
### Nx Cloud distributes builds.
**Nx Cloud is a proper coordinator and it can process any task graph**. An Nx Cloud agent asks for tasks to execute. The Nx Cloud service looks at the commands currently running and will see if there are any tasks that have no unfulfilled dependencies. If there are some, the Nx Cloud service will use the collected timings to create a well-size batch of tasks that it will send to the agent.
The agent sees if it has all the files required to run those tasks (`dist` folders from previous tasks). And if it doesn't, it downloads them. When it's done running the task, it lets the Nx Cloud service know to "unblock" other tasks in the graph. At the same time, the Nx Cloud service sends the created files and terminal outputs to the main job.
### Nx Cloud does not require you to rewrite the CI setup.
As you saw above, the CI setup, by and large, remained the same. And nothing had to change in the workspace itself. For instance, the `npx nx affected --target=test --parallel --maxParallel=3` command looks exactly the same. The meaning of `--max-parallel` changes its meaning from run up to 3 test tasks on the main job to run up to 3 test tasks on each agent.
If you want to change this command without distribution, add `NX_CLOUD_DISTRIBUTED_EXECUTION` as follows: `NX_CLOUD_DISTRIBUTED_EXECUTION=false npx nx affected --target=test --parallel --maxParallel=3`.
### Works With any CI System
When using distributed task execution all the communication is done from your agents to Nx Cloud. This means that it works with any CI system, including your private Jenkins installations. See some examples [here](/ci/recipes/set-up). And even works locally if you create a docker image from the state of repo and push it to say ECS. It also works with Nx Private Cloud.
## Summary
In this post we looked at two ways to distribute your CI: binning and using Nx Cloud's distributed task execution.
Binning has been supported from Day 1 and works well for a variety of workspaces. It has drawbacks: the resource allocation, the developer ergonomics, the inability to distribute builds, and a much more complex Ci setup.
Nx Cloud distributed task execution addresses the drawbacks.
[Learn more about Nx Cloud 2.0 and its support for distributed task execution](/nx-cloud).
description: Learn how to set up a monorepo with Nx to manage React Native mobile and React web apps with shared libraries, demonstrated through a daily horoscope app example.
---
Do you want to have both mobile and web apps in the same repo? Do you wish that you could share code between mobile and web apps? This blog post shows you how to create a React Native mobile app and a React web app in the same repo with shared libraries using Nx.
In the app’s package.json at `apps/daily-horoscope-app/package.json`, under dependencies, add the above packages:
In the app's package.json at `apps/daily-horoscope-app/package.json`, under dependencies, add the above packages:
```json5
{
@@ -166,7 +167,7 @@ export enum AdhZodiacSign {
}
```
**Note**: the enum has a prefix “Adh” to indicate it is a model under domain “aztro-daily-horoscope”. Add this prefix to distinguish model names from component names.
**Note**: the enum has a prefix "Adh" to indicate it is a model under domain "aztro-daily-horoscope". Add this prefix to distinguish model names from component names.
This example uses icons from [Material Community Icons](https://materialdesignicons.com/). You need to create a list that contains the zodiac sign name and its matching icon.
Since the code is running in simulators, how to use the Redux Devtools extension and view the Redux Logger?
Open the debug menu in the simulator by entering `d` in the terminal that runs the start command. Then in the debug menu, choose “Debug with Chrome” for iOS and “Debug” for Android.
Open the debug menu in the simulator by entering `d` in the terminal that runs the start command. Then in the debug menu, choose "Debug with Chrome" for iOS and "Debug" for Android.
Now you need to add this screen to your app. In file `apps/daily-horoscope-app/src/app/App.tsx`, you need to update it to add a stack screen for the `horoscope-card` component:
```tsx
import { store } from '@aztro-daily-horoscope/store';
import {
ZodiacSignListContainer,
HoroscopeCard,
} from '@aztro-daily-horoscope/ui';
import { NavigationContainer } from '@react-navigation/native';
import { createStackNavigator } from '@react-navigation/stack';
In the `libs/ui/src/lib/zodiac-sign-list/zodiac-sign-list.tsx`, you need to trigger navigation when the list item got pressed.
Below code uses [`useNavigation`](https://reactnavigation.org/docs/use-navigation/) hook from [React Navigation](https://reactnavigation.org/) library. When the list item got pressed, it is going to call `navigation.navigate(‘Horoscope Card’)` to navigate the `horoscope-card` component you created above.
- `aztro-horoscope-response.interface.ts` defines what the response object looks like. It has a transform function to transform response data to the app domain model.
- `aztro.service.ts` calls the API to get the user’s horoscope based on the zodiac sign and day.
- `aztro.service.ts` calls the API to get the user's horoscope based on the zodiac sign and day.
description: Learn how to organize growing Nx repositories using module boundaries and ESLint rules to enforce clean architecture and prevent unwanted dependencies between domains.
---
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.
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.
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.
@@ -47,13 +48,13 @@ When you generate the first project in your workspace using one of our generator
}
```
Let’s dissect what each of these properties does.
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.
> 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.
@@ -91,7 +92,7 @@ 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:
Let's define the types of projects. We will use the following tags:
- `type:app` for application
- `type:feature` for feature library
@@ -147,12 +148,12 @@ Now, that we have marked all of our projects, we can continue to define the rule
## Adding a second dimension
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.
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.
_Project graph with type tags and technology badges_
Let’s add another dimension to allow such restrictions. We will define the necessary scope tags:
Let's add another dimension to allow such restrictions. We will define the necessary scope tags:
- `scope:store` for store app-related projects
- `scope:admin` for admin app related projects
@@ -266,9 +267,9 @@ Using the wildcard `*` to match multiple projects e.g. `react*` we can save ours
## 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.
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.
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.
description: Nx 13.4 brings single file monorepo configuration, custom workspace presets, enhanced Tailwind support for Angular, and dedicated TypeScript/JavaScript support with @nrwl/js.
---
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.
@@ -25,13 +26,13 @@ With the latest release of Nx and add-nx-to-monorepo 2.0, there is only the **nx
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)
> 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.
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.
@@ -47,7 +48,7 @@ This allows you to enhance the initial experience for new workspaces directly fo
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.
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.
@@ -58,7 +59,7 @@ Read all the details on [our new TypeScript guide](/getting-started/intro) or ch
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.
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.
description: Nx 13.5 brings a new dynamic terminal output, 2.3x faster operations, Chrome DevTools profiling support, and improved project graph visualization.
---
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.
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.
@@ -19,14 +20,14 @@ It clearly separates the terminal output into an upper part where all the comple
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.
- **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
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
@@ -37,7 +38,7 @@ And we will not rest 😉.
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.
That's why we introduced the ability to profile and visualize Nx commands in the Chrome Devtools.
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)
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
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
@@ -85,7 +86,7 @@ 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` )
- 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
description: Learn how to integrate Tailwind CSS with Angular in an Nx monorepo, including setup, configuration, and best practices for applications and libraries.
---
[**Tailwind CSS**](https://tailwindcss.com/) is a utility-first CSS framework packed with a lot of good functionality out of the box while providing a high level of customization. It has gained a lot of attention since it came out and it’s a good option when it comes to styling our applications.
[**Tailwind CSS**](https://tailwindcss.com/) is a utility-first CSS framework packed with a lot of good functionality out of the box while providing a high level of customization. It has gained a lot of attention since it came out and it's a good option when it comes to styling our applications.
In this blog post, we are going to see how we can use **Tailwind CSS** with [**Angular**](https://angular.io/) in an **Nx** monorepo. We are going to be looking at different scenarios and how to approach them.
Let’s get started!
Let's get started!
> Please note that this blog post is not meant to be a **Tailwind CSS** or **Angular** tutorial. The purpose is to show how to use them together and how **Nx** can help to improve the developer experience and expand the native **Angular** capabilities when working with **Tailwind CSS**.
@@ -23,16 +24,16 @@ We are going to create 2 simple applications with the following layout:
We’ll start by creating one application with the required markup and **Tailwind CSS** utility classes to achieve the above layout. Then, we’re going to leverage **Nx**’s library support and extract some common UI components into 2 different shared libraries:
We'll start by creating one application with the required markup and **Tailwind CSS** utility classes to achieve the above layout. Then, we're going to leverage **Nx**'s library support and extract some common UI components into 2 different shared libraries:
- a regular non-buildable library containing the header,
- a buildable library containing the card elements.
At that point, we’ll create the second application using the components exposed by those shared libraries. Finally, we’ll extract the button elements to a publishable library and adjust both applications to use them.
At that point, we'll create the second application using the components exposed by those shared libraries. Finally, we'll extract the button elements to a publishable library and adjust both applications to use them.
The idea is to show how different applications can still use the same components and have them styled differently using **Tailwind CSS**. Both applications in this blog post will share the same layout, but the approach explained here would apply to applications with different layouts sharing the same UI components.
> Discussing the different types of libraries and the motivation to use them goes beyond the scope of this blog post. We’ll use the three different types just to showcase how to use **Tailwind CSS** with each of them. To know more about them, please check [/concepts/decisions/project-size](/concepts/decisions/project-size) and [/concepts/buildable-and-publishable-libraries](/concepts/buildable-and-publishable-libraries).
> Discussing the different types of libraries and the motivation to use them goes beyond the scope of this blog post. We'll use the three different types just to showcase how to use **Tailwind CSS** with each of them. To know more about them, please check [/concepts/decisions/project-size](/concepts/decisions/project-size) and [/concepts/buildable-and-publishable-libraries](/concepts/buildable-and-publishable-libraries).
The above command creates a workspace called `angular-tailwind-nx` and asks us a few questions to help us set up the workspace. We chose the `angular` preset, provided `app1` for the initial **Angular** application name, chose `css` as the stylesheet to use, and this time chose not to use [**Nx Cloud**](/nx-cloud) but feel free to opt-in to use the **Nx Cloud** free tier to benefit from distributing the computation caching of your projects.
> Any of the stylesheet options can be used. Also, using **Nx Cloud** or not doesn’t affect setting up **Tailwind CSS**.
> Any of the stylesheet options can be used. Also, using **Nx Cloud** or not doesn't affect setting up **Tailwind CSS**.
Now that we have a workspace with an **Angular** application ready to be used, let’s start adding some **Tailwind CSS** magic!
Now that we have a workspace with an **Angular** application ready to be used, let's start adding some **Tailwind CSS** magic!
## Adding Tailwind CSS
@@ -70,7 +71,7 @@ The above command will do a few things for us:
> The above generator supports **Tailwind CSS** v2 and v3.
Let’s take a look at the generated `apps/app1/tailwind.config.js` file:
Let's take a look at the generated `apps/app1/tailwind.config.js` file:
We can see the `content` property is configured to scan for all the HTML and TypeScript files within our application and besides that, there’s also a call to a function called `createGlobPatternsForDependencies`. This is a pretty handy function that will identify the dependencies of the application and return the glob patterns for them. This ensures that **Tailwind CSS** utility classes that are used in the application’s dependencies are also taken into account and included in the final CSS of the application.
We can see the `content` property is configured to scan for all the HTML and TypeScript files within our application and besides that, there's also a call to a function called `createGlobPatternsForDependencies`. This is a pretty handy function that will identify the dependencies of the application and return the glob patterns for them. This ensures that **Tailwind CSS** utility classes that are used in the application's dependencies are also taken into account and included in the final CSS of the application.
> Instead of using the `createGlobPatternsForDependencies`, we could just add the `_libs/**/*_` glob pattern that captures all libraries, but that could lead to bundling more CSS than needed in monorepos with multiple applications. This would happen because all applications would be scanning all libraries, regardless of whether they are dependencies or not. Such a glob pattern could also lead to scaling issues in large monorepos due to the amount of libraries to scan.
@@ -100,17 +101,14 @@ We can also see that the generator updated the `apps/app1/src/styles.css` file w
@tailwind utilities;
```
And that’s all we need. We can now go ahead and add our custom theme and layout to achieve the desired design.
And that's all we need. We can now go ahead and add our custom theme and layout to achieve the desired design.
## Adding a custom theme and the application markup
First, we are going to update the `theme` section of the generated `apps/app1/tailwind.config.js`. We are going to overwrite the **Tailwind CSS** default theme and provide the custom palette of colors and spacing of our theme to be used throughout the application:
```javascript {% fileName="tailwind.config.js" %}
...
module.exports = {
...
theme: {
colors: {
primary: {
@@ -133,7 +131,7 @@ module.exports = {
xl: '2rem',
},
},
...
plugins: [],
};
```
@@ -192,7 +190,7 @@ Next, we update the `apps/app1/src/app/app.component.html` file with the require
</div>
```
With all set, let’s see it in action by running:
With all set, let's see it in action by running:
```shell
npx nx run app1:serve
@@ -203,7 +201,7 @@ Visiting [https://localhost:4200](https://localhost:4200) in your browser should
That’s it! We have successfully created our application to fulfill the requirements we had. Next, we are going to start extracting pieces of the UI into shared libraries to reuse them with the second application.
That's it! We have successfully created our application to fulfill the requirements we had. Next, we are going to start extracting pieces of the UI into shared libraries to reuse them with the second application.
## Tailwind CSS and Angular libraries in an Nx workspace
@@ -215,13 +213,13 @@ From [**Tailwind CSS** docs](https://tailwindcss.com/docs/installation):
Any project can use the [**Tailwind CSS** CLI](https://tailwindcss.com/blog/standalone-cli) or [**PostCSS**](https://postcss.org/) with the `tailwindcss` plugin to scan the relevant files in the project and collect the usage of the **Tailwind CSS** utility classes, functions, and custom CSS directives (custom CSS [at-rules](https://developer.mozilla.org/en-US/docs/Web/CSS/At-rule)). With that information, the final CSS styles are generated.
**Angular** uses **PostCSS** to support **Tailwind CSS**. As we saw in a previous section, with the help of an **Nx** generator, it’s pretty straightforward to configure a **Tailwind CSS** for applications. Libraries can also be easily configured, but there are some nuances regarding how they are processed and whether they need to be configured or not.
**Angular** uses **PostCSS** to support **Tailwind CSS**. As we saw in a previous section, with the help of an **Nx** generator, it's pretty straightforward to configure a **Tailwind CSS** for applications. Libraries can also be easily configured, but there are some nuances regarding how they are processed and whether they need to be configured or not.
In an **Nx** workspace, a regular library (non-buildable and non-publishable) is just a slice of an application that is only built as part of the build process of an application that consumes it. Because of that, as long as the application that consumes it has **Tailwind CSS** configured, the library code will be processed as expected even though the library itself doesn’t have a **Tailwind CSS** configuration. In fact, adding a `tailwind.config.js` file to the library won’t have any effect whatsoever (it’ll be ignored) because the library is never built on its own.
In an **Nx** workspace, a regular library (non-buildable and non-publishable) is just a slice of an application that is only built as part of the build process of an application that consumes it. Because of that, as long as the application that consumes it has **Tailwind CSS** configured, the library code will be processed as expected even though the library itself doesn't have a **Tailwind CSS** configuration. In fact, adding a `tailwind.config.js` file to the library won't have any effect whatsoever (it'll be ignored) because the library is never built on its own.
On the other hand, buildable and publishable libraries are meant to be built on their own and their compiled output to be shared with the consumers. Therefore, they need to be able to process any **Tailwind CSS** directive or function (e.g. `@apply`, `theme()`) when they are built. If no **Tailwind CSS** directive or function is used, then the configuration is not needed.
> Providing the configuration to a buildable or publishable library that doesn’t need it adds some unnecessary overhead to the build process. The executor will still load the configuration and the **PostCSS** plugin will process the stylesheets unnecessarily.
> Providing the configuration to a buildable or publishable library that doesn't need it adds some unnecessary overhead to the build process. The executor will still load the configuration and the **PostCSS** plugin will process the stylesheets unnecessarily.
How does this work?
@@ -238,7 +236,7 @@ When the **PostCSS** plugin processes a file containing these, it processes them
But we do use **Tailwind CSS** utility classes in the libraries and CSS needs to be generated for them. So, how is the CSS generated for those classes if the libraries are not configured?
If we recall from a previous section, in our application’s `tailwind.config.js` file, we have the following:
If we recall from a previous section, in our application's `tailwind.config.js` file, we have the following:
```javascript {% fileName="tailwind.config.js" %}
...
@@ -252,11 +250,11 @@ module.exports = {
};
```
The `content` property of the configuration tells **Tailwind CSS** where to look for usages of utility classes. When the **PostCSS** plugin finds a file using the `@tailwind` directive, it will collect all the utility classes for the layer specified by the directive in the files matching the glob patterns set in the `content` property of the configuration, and it will produce the CSS replacing the directive. It’s worth noting that the **PostCSS** plugin only scans the files collecting the utility classes that are used, it doesn’t process them. Only the file containing the `@tailwind` directive is updated with the resulting CSS.
The `content` property of the configuration tells **Tailwind CSS** where to look for usages of utility classes. When the **PostCSS** plugin finds a file using the `@tailwind` directive, it will collect all the utility classes for the layer specified by the directive in the files matching the glob patterns set in the `content` property of the configuration, and it will produce the CSS replacing the directive. It's worth noting that the **PostCSS** plugin only scans the files collecting the utility classes that are used, it doesn't process them. Only the file containing the `@tailwind` directive is updated with the resulting CSS.
Since we have our application configured to scan the relevant files within itself and also within its dependencies, the utility classes used in the libraries that are dependencies of the application will be picked up correctly and the CSS will be generated for them.
> It’s important to note that the support for **Tailwind CSS** for **Angular** libraries is only available using the `@nrwl/angular:ng-packagr-lite` executor for buildable libraries and the `@nrwl/angular:package` executor for publishable libraries.
> It's important to note that the support for **Tailwind CSS** for **Angular** libraries is only available using the `@nrwl/angular:ng-packagr-lite` executor for buildable libraries and the `@nrwl/angular:package` executor for publishable libraries.
Below is a small decision tree to check whether a **Tailwind CSS** configuration is needed for your library in an **Nx** workspace:
@@ -265,11 +263,11 @@ _Decision tree for the need of Tailwind CSS configuration in Angular libraries_
## Extracting the header into a library
Our application is looking good. At the same time, there’s a great opportunity to reuse some of its components in another application. Therefore, we are going to extract the shared components into several shared libraries.
Our application is looking good. At the same time, there's a great opportunity to reuse some of its components in another application. Therefore, we are going to extract the shared components into several shared libraries.
> The applications of this blog post are very simple and it’s probably not worthy to extract the components into multiple libraries. We are doing it for illustrative purposes to cover the different scenarios we might find in real-life applications.
> The applications of this blog post are very simple and it's probably not worthy to extract the components into multiple libraries. We are doing it for illustrative purposes to cover the different scenarios we might find in real-life applications.
We’ll start by extracting the header of the application into a reusable component and placing it into a library. To do so, we start by creating a new **Angular** library in our workspace by running:
We'll start by extracting the header of the application into a reusable component and placing it into a library. To do so, we start by creating a new **Angular** library in our workspace by running:
```shell
npx nx generate @nrwl/angular:lib lib1
@@ -289,7 +287,7 @@ Add the markup for the header to the `libs/lib1/src/lib/header/header.component.
</header>
```
Import `Lib1Module` into our application’s `AppModule`:
Import `Lib1Module` into our application's `AppModule`:
As explained in a previous section when we did the same for the application, the above command will install any required dependencies if needed, create the `tailwind.config.js` file and in the specific case of libraries, it will also add the `tailwindConfig` property to the `build` target of the project configuration.
> **Angular** applications, buildable and publishable libraries can be created with **Tailwind CSS** support with a single command. We’ll see that in the upcoming section. The `_@nrwl/angular:setup-tailwind_` generator is used to add **Tailwind CSS** support to existing projects.
> **Angular** applications, buildable and publishable libraries can be created with **Tailwind CSS** support with a single command. We'll see that in the upcoming section. The `_@nrwl/angular:setup-tailwind_` generator is used to add **Tailwind CSS** support to existing projects.
Then, we create the card component:
@@ -383,7 +381,7 @@ export class CardComponent {
</div>
```
Import `Lib2Module` into our application’s `AppModule`:
Import `Lib2Module` into our application's `AppModule`:
```typescript {% fileName="app.module.ts" %}
...
@@ -420,7 +418,7 @@ And finally, replace the existing markup for the cards in the `apps/app1/src/app
</div>
```
With that in place, we can serve the application and it should be working exactly as before, but our application is still not fully set up to consume the library build output. As it stands right now, when the application that’s consuming it is built, the library will be built together with it and its files will be processed as part of the application build pipeline.
With that in place, we can serve the application and it should be working exactly as before, but our application is still not fully set up to consume the library build output. As it stands right now, when the application that's consuming it is built, the library will be built together with it and its files will be processed as part of the application build pipeline.
To finish the buildable library setup, we can follow the instructions in [/recipes/angular/setup-incremental-builds-angular](/recipes/angular/setup-incremental-builds-angular). We need to install the `@nrwl/web` package, change the application `build` target executor to `@nrwl/angular:webpack-browser`, and change the application `serve` target executor to `@nrwl/web:file-server`:
You can now go ahead and serve the application to check everything is working as expected. You should see the buildable library being built on its own before the application is built and served.
> The `@nrwl/web:file-server` executor uses the [http-server](https://www.npmjs.com/package/http-server) package to serve the built artifacts of our application. This is a lightweight HTTP server and it doesn’t do things like live-reload or HMR. Be sure to refresh your browser while making changes to see them reflected.
> The `@nrwl/web:file-server` executor uses the [http-server](https://www.npmjs.com/package/http-server) package to serve the built artifacts of our application. This is a lightweight HTTP server and it doesn't do things like live-reload or HMR. Be sure to refresh your browser while making changes to see them reflected.
## Using Tailwind CSS directives and functions in buildable libraries
Our application is consuming a buildable library and still working as intended, but if we think about it, we didn’t configure our theme in the library’s `tailwind.config.js` file. So, how is it still working?
Our application is consuming a buildable library and still working as intended, but if we think about it, we didn't configure our theme in the library's `tailwind.config.js` file. So, how is it still working?
If we go back to the decision tree shared in a previous section, we’ll see that a buildable library only needs a **Tailwind CSS** configuration if we use a **Tailwind CSS** directive or function. As of right now, our library is not using any. We are just using some utility classes and those are processed correctly as part of the application build. You could go ahead and delete the `tailwind.config.js` file from the library and check that everything still works the same (if you do, please make sure to restore it before we continue).
If we go back to the decision tree shared in a previous section, we'll see that a buildable library only needs a **Tailwind CSS** configuration if we use a **Tailwind CSS** directive or function. As of right now, our library is not using any. We are just using some utility classes and those are processed correctly as part of the application build. You could go ahead and delete the `tailwind.config.js` file from the library and check that everything still works the same (if you do, please make sure to restore it before we continue).
Next, we are going to refactor our newly created card component to make use of some of these directives and functions and see the implications.
@@ -498,9 +496,9 @@ Update the card component files content as shown below:
We created some CSS classes where we are applying the same styles we had in the component template. We are applying those styles by using a combination of the `@apply` directive and the `theme` function.
> Please note we are not recommending creating CSS classes for scenarios like the above. The card component is already a reusable component and there’s no need to extract CSS classes to style it. We are only extracting these classes to showcase how **Tailwind CSS** directives and functions can be correctly processed in buildable libraries. Make sure to check out the [**Tailwind CSS** recommendations for reusing styles](https://tailwindcss.com/docs/reusing-styles).
> Please note we are not recommending creating CSS classes for scenarios like the above. The card component is already a reusable component and there's no need to extract CSS classes to style it. We are only extracting these classes to showcase how **Tailwind CSS** directives and functions can be correctly processed in buildable libraries. Make sure to check out the [**Tailwind CSS** recommendations for reusing styles](https://tailwindcss.com/docs/reusing-styles).
If we now serve our application (or build the library), we’ll find ourselves with the following error:
If we now serve our application (or build the library), we'll find ourselves with the following error:
@@ -509,9 +507,9 @@ Building entry point '@angular-tailwind-nx/lib2'
/angular-tailwind-nx/libs/lib2/src/lib/card/card.component.css:2:3: The `p-lg` class does not exist. If `p-lg` is a custom class, make sure it is defined within a `@layer` directive.
```
This is to be expected. The library build is failing because now we are using some **Tailwind CSS** directives and functions, and therefore, those directives and functions are being processed within the library context. Since we haven’t touched the `tailwind.config.js` file, **Tailwind CSS** doesn’t know about our custom theme.
This is to be expected. The library build is failing because now we are using some **Tailwind CSS** directives and functions, and therefore, those directives and functions are being processed within the library context. Since we haven't touched the `tailwind.config.js` file, **Tailwind CSS** doesn't know about our custom theme.
To solve the issue, we need to configure the library to be aware of our custom theme so it can process the library’s files correctly. Let’s update the `theme` property of the `libs/lib2/tailwind.config.js` file to match our application theme:
To solve the issue, we need to configure the library to be aware of our custom theme so it can process the library's files correctly. Let's update the `theme` property of the `libs/lib2/tailwind.config.js` file to match our application theme:
```javascript {% fileName="tailwind.config.js" %}
...
@@ -550,12 +548,12 @@ Well, no need to fret!
If we think about it, the same reasoning behind creating shared libraries applies to this. We just need to share the **Tailwind CSS** configuration. To do so, we have a couple of options:
- Create a shared file containing and exporting the theme so it can be imported by every project’s `tailwind.config.js` file.
- Create a shared file containing and exporting the theme so it can be imported by every project's `tailwind.config.js` file.
- Create a [**Tailwind CSS** preset](https://tailwindcss.com/docs/presets) to expose a base configuration for your projects.
The last option is the better one. We can take advantage of the **Tailwind CSS** built-in support for defining a base configuration to be reused across different projects. The first option is almost the same, with the difference that we have to manually handle merging the configurations.
We’ll go ahead and create a **Tailwind CSS** preset and we’ll then use it in our projects. Start by creating a `tailwind.config.js` file in the root of the workspace with the following content:
We'll go ahead and create a **Tailwind CSS** preset and we'll then use it in our projects. Start by creating a `tailwind.config.js` file in the root of the workspace with the following content:
```javascript {% fileName="tailwind.config.js" %}
module.exports = {
@@ -603,19 +601,19 @@ module.exports = {
};
```
Notice how we added the preset and removed almost all the configuration because it’s already defined in the preset.
Notice how we added the preset and removed almost all the configuration because it's already defined in the preset.
That’s all it takes. You can go ahead and serve the application (or refresh the browser if you are already serving it) to check everything is running correctly.
That's all it takes. You can go ahead and serve the application (or refresh the browser if you are already serving it) to check everything is running correctly.
## Sharing the Tailwind CSS preset in a library
We now only have to maintain our theme in a single place as opposed to keeping in sync the configuration of all the different projects. But we can still improve the experience. As it stands, if you now make a change on the `tailwind.config.js` file located at the root of the workspace (our preset), the file server doesn’t pick up the change and therefore, it doesn’t rebuild the affected projects.
We now only have to maintain our theme in a single place as opposed to keeping in sync the configuration of all the different projects. But we can still improve the experience. As it stands, if you now make a change on the `tailwind.config.js` file located at the root of the workspace (our preset), the file server doesn't pick up the change and therefore, it doesn't rebuild the affected projects.
This happens because the file server is watching for changes under the `apps` and `libs` folders. The preset configuration is not under those directories, it’s in the root of the workspace.
This happens because the file server is watching for changes under the `apps` and `libs` folders. The preset configuration is not under those directories, it's in the root of the workspace.
It would be better if we place the preset configuration in a small shared library. By doing that, we not only solve the issue regarding detecting changes on it, but we also make its library appear on the [**Nx** project graph](/concepts/mental-model), and with that, we benefit from all the goodies associated with the project graph (affected commands, enforcing module boundaries constraints, etc.).
This library is only going to contain the `tailwind.config.js` file and no targets in the project configuration. There’s no generator among the **Nx** core plugins that generate such an empty library. We could use one of the library generators and remove some content, but let’s create it manually.
This library is only going to contain the `tailwind.config.js` file and no targets in the project configuration. There's no generator among the **Nx** core plugins that generate such an empty library. We could use one of the library generators and remove some content, but let's create it manually.
Start by creating a new folder `libs/tailwind-preset` and moving the `tailwind.config.js` file we created in the previous section at the root of the workspace to that folder.
Once again, if we serve our application everything should still be working as expected, but now our file server will pick up the changes made to the **Tailwind CSS** preset configuration.
Also, if we visualize the workspace projects we’ll see how `app1` and `lib2` now have a dependency on `tailwind-preset`:
Also, if we visualize the workspace projects we'll see how `app1` and `lib2` now have a dependency on `tailwind-preset`:
_Project graph showing dependencies between the projects in the workspace_
## Creating the second application
We are now at a stage where we can develop our second application without having to duplicate the common functionality. So, before going ahead and distributing our buttons in a publishable library, let’s first create the second application to see how we can reuse what we have been putting into libraries.
We are now at a stage where we can develop our second application without having to duplicate the common functionality. So, before going ahead and distributing our buttons in a publishable library, let's first create the second application to see how we can reuse what we have been putting into libraries.
There’s one important thing to note though, this new application will have a different theme.
There's one important thing to note though, this new application will have a different theme.
Generate the application by running the following command:
@@ -674,7 +672,7 @@ The above command will generate the new application and it will configure **Tail
> The `--addTailwind` flag is available in both `@nrwl/angular:app` and `@nrwl/angular:lib` generators.
Let’s now update the application to use the shared components and achieve the layout we are after. Start by updating the `apps/app2/src/app/app.module.ts` to import `Lib1Module` and `Lib2Module`:
Let's now update the application to use the shared components and achieve the layout we are after. Start by updating the `apps/app2/src/app/app.module.ts` to import `Lib1Module` and `Lib2Module`:
```typescript {% fileName="app.module.ts" %}
...
@@ -689,7 +687,7 @@ import { Lib2Module } from '@angular-tailwind-nx/lib2';
export class AppModule {}
```
Next, update the `apps/app2/src/app/app.component.html` file with the required markup and **Tailwind CSS** utility classes to achieve our application’s layout and using the component exported by the shared libraries we previously created:
Next, update the `apps/app2/src/app/app.component.html` file with the required markup and **Tailwind CSS** utility classes to achieve our application's layout and using the component exported by the shared libraries we previously created:
@@ -740,7 +738,7 @@ Like we did with `app1`, we also need to update the `build` and `serve` targets
}
```
Last but not least, we need to configure **Tailwind CSS** with our custom theme for `app2`. We’ll do that by updating the `apps/app2/tailwind.config.js` file with the following:
Last but not least, we need to configure **Tailwind CSS** with our custom theme for `app2`. We'll do that by updating the `apps/app2/tailwind.config.js` file with the following:
```javascript {% fileName="tailwind.config.js" %}
...
@@ -772,31 +770,31 @@ module.exports = {
};
```
Now that we have the second application configured, let’s run it:
Now that we have the second application configured, let's run it:
```shell
npx nx run app2:serve
```
> You can pass a `--port=4201` to the above command to run it in a different port if it’s in use or if you want to have both applications running side-by-side.
> You can pass a `--port=4201` to the above command to run it in a different port if it's in use or if you want to have both applications running side-by-side.
Now, open your browser and navigate to it where you should see the application looking like the following screenshot:
That does indeed look different, but something is off. The card background color is not right, it’s still the same used for `app1` even though we provided a different theme. Also, some of the spacing for the elements within the card doesn’t seem to have changed according to our configuration.
That does indeed look different, but something is off. The card background color is not right, it's still the same used for `app1` even though we provided a different theme. Also, some of the spacing for the elements within the card doesn't seem to have changed according to our configuration.
What is going on here?
You might have realized a couple of things by now:
- The card component comes from `lib2` which is a buildable library and as such, it’s built on its own using its own **Tailwind CSS** configuration
- The card component comes from `lib2` which is a buildable library and as such, it's built on its own using its own **Tailwind CSS** configuration
- `app1` and `lib2` use a **Tailwind CSS** preset to share the common configuration, while `app2` is adding its own
So, the first bullet point above would explain why the card component looks like the one rendered using the theme for `app1`. But that’s not exactly what we are seeing, the buttons inside the card look different than what we have in `app1`. This is explained by the fact that the buttons are styled without using any **Tailwind CSS** directive or function, they just use utility classes, so the CSS for them is generated in the `app2` build using the application configuration. The rest of the card does use directives and functions, so the CSS for that is generated in the `lib2` build using the library configuration.
So, the first bullet point above would explain why the card component looks like the one rendered using the theme for `app1`. But that's not exactly what we are seeing, the buttons inside the card look different than what we have in `app1`. This is explained by the fact that the buttons are styled without using any **Tailwind CSS** directive or function, they just use utility classes, so the CSS for them is generated in the `app2` build using the application configuration. The rest of the card does use directives and functions, so the CSS for that is generated in the `lib2` build using the library configuration.
Also, we previously created a **Tailwind CSS** preset so we could share the base configuration among different projects. The problem is that all those projects shared a common theme, but `app2` requires a different one, so we can’t just use the preset as it is right now.
Also, we previously created a **Tailwind CSS** preset so we could share the base configuration among different projects. The problem is that all those projects shared a common theme, but `app2` requires a different one, so we can't just use the preset as it is right now.
So, how do we solve this?
@@ -804,7 +802,7 @@ Enter CSS variables!
We can configure the **Tailwind CSS** preset to use CSS variables. This will allow each application to provide its own values for the variables and therefore, it enables us to have multiple themes using the same **Tailwind CSS** configuration.
Let’s update our preset in the `libs/tailwind-preset/tailwind.config.js` file to use CSS variables instead of literal values:
Let's update our preset in the `libs/tailwind-preset/tailwind.config.js` file to use CSS variables instead of literal values:
```javascript {% fileName="tailwind.config.js" %}
module.exports = {
@@ -894,7 +892,7 @@ We need to do the same for `app1`. Edit the `apps/app1/src/styles.css` file with
}
```
Let’s serve again `app2` and navigate to it to check the results of our changes:
Let's serve again `app2` and navigate to it to check the results of our changes:
@@ -1000,11 +998,11 @@ Once more, we can check both applications and make sure everything is still work
## Distributing the publishable library styles
The recently created publishable library is already being used successfully by both applications, but it’s still not ready for distribution. If we were to share it now, external consumers will need to provide their own CSS for it because the library itself is not bundling any CSS with the styling for the button. We only used some **Tailwind CSS** utility classes and as we have seen throughout this blog post, the CSS for them is generated in files containing `@tailwind` directives (normally in application style entry points).
The recently created publishable library is already being used successfully by both applications, but it's still not ready for distribution. If we were to share it now, external consumers would need to provide their own CSS for it because the library itself is not bundling any CSS with the styling for the button. We only used some **Tailwind CSS** utility classes and as we have seen throughout this blog post, the CSS for them is generated in files containing `@tailwind` directives (normally in application style entry points).
> Within the workspace, it works as expected because the applications consuming it use the same shared **Tailwind CSS** preset and their dependencies are included in the `content` of their configuration.
The library needs to contain everything that’s needed for it to work and to achieve this, we are going to do something we already did with our buildable library: create our own classes using the `@apply` directive.
The library needs to contain everything that's needed for it to work and to achieve this, we are going to do something we already did with our buildable library: create our own classes using the `@apply` directive.
As we learned in a previous section, the `@apply` directive will be transformed into the CSS corresponding to the **Tailwind CSS** classes being applied. Thanks to this, our button component will contain the CSS needed to style it.
@@ -1024,7 +1022,7 @@ Go ahead and update the button component files with a new CSS class for the butt
I used the prefix `atn` (initials of **A**ngular, **T**ailwind CSS, and **N**x) for the CSS class name to prevent potential name collisions with the consumers' applications CSS.
Also, let’s update the `libs/lib3/src/lib/button/button.component.ts` file to set the component’s `encapsulation` to `ViewEncapsulation.None` to allow consumers to overwrite its styles more easily:
Also, let's update the `libs/lib3/src/lib/button/button.component.ts` file to set the component's `encapsulation` to `ViewEncapsulation.None` to allow consumers to overwrite its styles more easily:
@@ -1043,7 +1041,7 @@ If we build our library now, the styles for the button component will be correct
We need to provide an initial theme that sets those CSS variables so the library components can be consumed without any additional setup. Actually, we are going to generate a couple of theme options so we can see how multiple themes can be provided.
Let’s start by creating a `libs/lib3/src/styles/teal.css` theme file where we are going to import the **Tailwind CSS** `components` and `utilities` layers and define the values for the CSS variables of our theme:
Let's start by creating a `libs/lib3/src/styles/teal.css` theme file where we are going to import the **Tailwind CSS** `components` and `utilities` layers and define the values for the CSS variables of our theme:
```css {% fileName="teal.css" %}
@tailwind components;
@@ -1068,7 +1066,7 @@ Let’s start by creating a `libs/lib3/src/styles/teal.css` theme file where we
}
```
Notice that we didn’t include the `base` layer like we have done so far in the applications style entry points. This is because this is a component library and the `base` layer generates a set of application-wide base styles and that’s not what we want to generate here.
Notice that we didn't include the `base` layer like we have done so far in the applications style entry points. This is because this is a component library and the `base` layer generates a set of application-wide base styles and that's not what we want to generate here.
Next, we generate our second theme by creating the `libs/lib3/src/styles/indigo.css` theme file with different values for the CSS variables:
@@ -1095,11 +1093,11 @@ Next, we generate our second theme by creating the `libs/lib3/src/styles/indigo.
}
```
With that in place, we now need to make sure those theme files are processed when we build the library. The `@nrwl/angular:package` executor is powered by the [**ng-packagr**](https://github.com/ng-packagr/ng-packagr) package to build the library. This is a tool recommended by **Angular** to ensure libraries are distributed using the [Angular Package Format](https://angular.io/guide/angular-package-format). Unfortunately, it doesn’t have native support for building standalone stylesheets that are not referenced by a component, so we need to configure it ourselves.
With that in place, we now need to make sure those theme files are processed when we build the library. The `@nrwl/angular:package` executor is powered by the [**ng-packagr**](https://github.com/ng-packagr/ng-packagr) package to build the library. This is a tool recommended by **Angular** to ensure libraries are distributed using the [Angular Package Format](https://angular.io/guide/angular-package-format). Unfortunately, it doesn't have native support for building standalone stylesheets that are not referenced by a component, so we need to configure it ourselves.
To do so, we are going to use the **Tailwind CSS** CLI to process our stylesheets when the library is built and we’ll do it in parallel since they don’t depend on each other. One aspect to consider is that the `@nrwl/angular:package` executor will delete the destination folder before building. When running both processes in parallel, the styles might be generated first and then the directory containing them is deleted by the `@nrwl/angular:package` executor. Therefore, we are going to disable that behavior and we are going to control when to delete the destination folder to avoid any issues.
To do so, we are going to use the **Tailwind CSS** CLI to process our stylesheets when the library is built and we'll do it in parallel since they don't depend on each other. One aspect to consider is that the `@nrwl/angular:package` executor will delete the destination folder before building. When running both processes in parallel, the styles might be generated first and then the directory containing them is deleted by the `@nrwl/angular:package` executor. Therefore, we are going to disable that behavior and we are going to control when to delete the destination folder to avoid any issues.
Another thing to consider is that the **Tailwind CSS** CLI only supports processing one file at a time, it doesn’t accept glob patterns or directories. We’ll need to run a command per theme in our library.
Another thing to consider is that the **Tailwind CSS** CLI only supports processing one file at a time, it doesn't accept glob patterns or directories. We'll need to run a command per theme in our library.
To orchestrate this, we are going to make the following changes to the `lib3` project configuration:
@@ -1198,7 +1196,7 @@ We can now build the library by running:
npx nx run lib3:build
```
If we check the output folder `dist/libs/lib3`, we’ll see there’s a `themes` folder in it with a couple of files `indigo.css` and `teal.css`:
If we check the output folder `dist/libs/lib3`, we'll see there's a `themes` folder in it with a couple of files `indigo.css` and `teal.css`:
description: Learn how to create and manage React web and React Native mobile apps in an Nx monorepo, with guidance on sharing code and handling platform differences.
---
**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:
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.
> 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`
@@ -68,7 +69,7 @@ Even though our goal is to share as much as possible between our React web app a
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.
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**
@@ -246,7 +247,7 @@ Nx comes with a set of different options for [handling environment variables](/r
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`.
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
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).
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.
@@ -267,11 +268,11 @@ export function getEnv(envName: string) {
}
```
To access the environment variable `NX_REQUEST_BASE_URL`, we can then simply use the above function:`getEnv(‘NX_REQUEST_BASE_URL’)`.
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`.
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).
@@ -466,7 +467,7 @@ _Screenshots of Mobile App (left: iOS, right: Android)_
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.
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.
description: Introducing @nrwl/expo for seamless Expo integration in Nx monorepos, with a tutorial on building a poetry app using Expo's development tools.
---
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.
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).
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.
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:
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:
description: Discover Nx as a powerful CLI for React development with built-in project generation, build tools, and pre-configured integrations for modern tooling.
---
_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._
_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.
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.
**Prefer the video version?**
@@ -18,32 +19,30 @@ While speed is of major importance, developer ergonomics shouldn’t be left beh
## Update (Aug 2023): Want a non-monorepo setup?
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):
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 the standalone tutorial (including video).
## Why use a devtool CLI?
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.
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.
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
## 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
From a bird's eye view, Nx comes with
- Code generators to generate new projects, configuration but also components, Redux setup, routes…
- 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.
But let's have a deeper look at how Nx works exactly.
## Using Nx
@@ -57,20 +56,20 @@ Open your favorite terminal window and type:
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_`
> _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
`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.
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 🙂.
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.
@@ -85,7 +84,7 @@ To serve our React app, run
npx nx serve happynrwl
```
> _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_`_._
> _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`.
@@ -107,13 +106,13 @@ _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.
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.
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:
Let's for instance generate a new component for our React application:
```shell
npx nx generate @nrwl/react:component HelloWorld
@@ -133,11 +132,11 @@ Many of these generators come with a rich set of flags. For example, passing `--
- **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.
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
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
@@ -147,7 +146,7 @@ When setting up a new React project (that also holds for Angular, Node, Next.js,
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.
Let's have a closer look.
## TypeScript as a first-class citizen!
@@ -174,7 +173,7 @@ npx nx lint happynrwl
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.
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.
@@ -189,8 +188,8 @@ 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
-…
- `--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:
@@ -206,7 +205,7 @@ Whenever you generate a new project in an Nx workspace, you have the option to a
_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
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)
@@ -220,7 +219,7 @@ 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!
## 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.
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).
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)_._
- (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.
- (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:
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.
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.
@@ -274,7 +273,7 @@ One of the advantages of using Nx over — say CRA or a custom starter template
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
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
@@ -307,7 +306,7 @@ Here are some common questions developers have. Have some more? Feel free to pin
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:
Here's the `project.json` for our `happynrwl` React application. I clipped out the non-relevant parts here:
```json5
{
@@ -347,13 +346,13 @@ Here’s the `project.json` for our `happynrwl` React application. I clipped out
}
```
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).
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)
> _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.
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.
@@ -362,7 +361,7 @@ Nx’s extensibility and customizability have really no limits, allowing it to r
## 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.
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:
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?
## 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).
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](/concepts/decisions/project-size).
You can change this setup in `nx.json` by adjustijng the `workspaceLayout` property which has an `appsDir` and `libsDir` configuration.
@@ -428,15 +427,15 @@ Agreed. Luckily Nx is plugin based, so you can start with the bare minimum (see
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?
## 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.
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.
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/)_._
> _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?
## 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.
description: Nx 13.10 brings core package consolidation, Nx Daemon by default, local plugin development, enhanced visualization, new lint rules, and React 18 support.
---
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
## 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.
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.
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
## 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.
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_
@@ -41,7 +42,7 @@ This illustration should give you a rough idea. obviously some of the plugins ma
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).
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:
@@ -70,13 +71,13 @@ This creates a new library with a pre-configured setup to develop a Nx plugin. S
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
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.
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.
@@ -87,9 +88,9 @@ We keep improving our project graph and make it more and more useful for visuall
_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!
And this is just a sneak peak of what's coming in Nx v14, so stay tuned!
## New “notDependOnLibsWithTags” Linter option
## 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.
@@ -144,13 +145,13 @@ So far you have only been able to specify which tags a library is allowed to dep
## 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.
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.
_Lint error about relative import across library boundaries_
@@ -178,11 +179,11 @@ _Automatic fixes for cross-library imports_
## React 18 support
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.
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
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)
@@ -199,7 +200,7 @@ or use Nx Console to get some more help in generating the Storybook setup.
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 🙂
If however you're curious, you can now append `--allPrompts` to get all possible questions asked 🙂
```shell
npx create-nx-workspace@next myorg --allPrompts
@@ -219,14 +220,14 @@ 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.
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.
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_
@@ -241,9 +242,9 @@ Learn more in this short video walkthrough:
## Our docs keep getting more and more awesome
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.
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:
Check out Benjamin Cabanes' tweet with some short videos:
description: Learn how to integrate and configure Storybook with Nx React Native apps, including solutions for common navigation and Redux store integration issues.
---
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.
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)
@@ -104,7 +105,7 @@ module.exports = {
};
```
Also, notice that in your app’s main file, the import of the App changed to `storybook/toggle-storybook`:
Also, notice that in your app's main file, the import of the App changed to `storybook/toggle-storybook`:
```typescript
import App from './storybook/toggle-storybook';
@@ -148,12 +149,12 @@ Then just run the command to start your app, you should see the storybook for yo
## Troubleshooting
### Error: Couldn’t find a navigation object
### 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:
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:
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**.
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.
@@ -16,7 +17,7 @@ Those last 6 months have been incredible and Nx probably got the biggest boost e
## 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!
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!
@@ -30,7 +31,7 @@ We saw that coming and made it easy for people to migrate to Nx.
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/)
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.
@@ -38,13 +39,13 @@ The future for monorepo tools looks bright as the awareness of monorepos, especi
## Nx Console reaches 1 million installs
While we’re talking numbers. We just hit another milestone 🎉
While we're talking numbers. We just hit another milestone 🎉
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
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!
@@ -61,11 +62,11 @@ How can Nx be so fast? One thing we did introduce after v13 and [recently enable
> **_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.
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.
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._
@@ -83,7 +84,7 @@ Nx is also able now to directly pick up your `package.json` scripts which are co
## 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
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_ 🙂*)*
@@ -95,7 +96,7 @@ We now even filter out the build of dependent projects. Say you build the `react
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
## "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:
@@ -136,13 +137,13 @@ Or just use [Nx Console](/getting-started/editor-setup), as always.
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).
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.
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.
@@ -156,13 +157,13 @@ Until now, you had to have a task that is being executed through Nx Cloud. But w
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.
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.
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:
@@ -186,24 +187,24 @@ 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.
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.
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)
Read more in 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)
Read more in our docs: [/concepts/module-federation/micro-frontend-architecture](/concepts/module-federation/micro-frontend-architecture)
## Dark mode for Project Graph as well as path tracking
@@ -211,15 +212,15 @@ You asked for it, the community responded. [Luís Carvalho](https://github.com/L
@@ -239,9 +240,9 @@ Oh wait, you didn’t want the shortest path? There’s a button for showing all
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.
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)
Read all the details in our docs: [/getting-started/intro](/getting-started/intro)
## React
@@ -249,7 +250,7 @@ Nx v14 ships with React 18 support for React DOM and React Native. The latter ha
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)
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
@@ -268,13 +269,13 @@ Docs are hard! But we keep investing and a lot of work has gone into making docs
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
-"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
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!
description: Nrwl takes over Lerna.js stewardship, promising continued maintenance, critical updates, and future Nx integration while supporting the existing community.
---
If you’re in a hurry, here’s the **TL;DR:**
If you're in a hurry, here's the **TL;DR:**
> _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!_
> _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?
@@ -19,35 +20,35 @@ We (Nrwl) are the company behind Nx ([GitHub](https://github.com/nrwl/nx)) and w
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.
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?
## 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)*
_(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.
- 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.
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.
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.
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.
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!
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
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)
description: Lerna v5.1 introduces the useNx flag for dramatic performance gains, making it 5.3x faster than Turborepo with added caching and task execution features.
---
**_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._
@@ -11,7 +12,7 @@ tags: [nx]
> _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.
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.
And it got fast, like really fast!!
@@ -25,11 +26,11 @@ Here you go
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.
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.
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:
Here's a gif of running the benchmark of Lerna+Nx and Turborepo:
@@ -50,7 +51,7 @@ Finally, add the following to your `lerna.json`.
}
```
That’s mostly it. You can continue using the usual Lerna commands, but at this point Lerna would delegate its operations to Nx underneath.
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:
@@ -76,11 +77,11 @@ So how does this work on a technical level. So far Lerna (`lerna run` to be more
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?
## What's more?
By having Nx integrated, you not just get faster builds but also some other Nx’s features for free!
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.
[**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.
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.
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 😃.
Another release packed with cool features and improvements just got released: [Nx 14.2](https://github.com/nrwl/nx/releases/tag/14.2.2). Read all about the Angular v14 upgrade that comes with it, TypeScript and other 3rd party package upgrades, improved Angular CLI to Nx migrations, optional `nx.json` and speed improvements.
## Angular v14
Angular v14 just got released last week. Read all about [the news here](https://blog.angular.io/angular-v14-is-now-available-391a6db736af). Huge kudos and congrats to the Angular team for again shipping on time based on their 6 months major release cycle. We've been collaborating with the team closely over the last couple of weeks to test early RCs, give feedback about upcoming features and foremost, make sure the new version not only works great in Nx, but also in the broader ecosystem that Nx supports such as Jest, ESLint, Storybook, Cypress and more.
We're excited about the new features that landed in Angular v14 which bring some fresh air and long-awaited innovations to the framework (\* cough \* Standalone Components, \* cough \* typed Angular forms).
As such, if you upgrade to Nx 14.2 (`npx nx migrate latest`), Nx will make sure to also trigger all the Angular v14 related migration scripts to update your workspace to the latest Angular version.
## TypeScript 4.7 and Prettier 2.6
With this release we also automatically update:
- TypeScript to version v4.7 ([announcement](https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/))
- Prettier to v2.6 ([announcement](https://prettier.io/blog/2022/03/16/2.6.0.html))
## Storybook 6.5
Nx 14.2 upgrades Storybook to the latest 6.5 version automatically for you.
Storybook support has been in Nx for a long time and we had our custom executor (builder) to preconfigure Storybook in a way that it works best within an Angular monorepo setup. We're glad that the Storybook support for Angular improved a lot over the last couple of releases s.t. we can **now directly use the Storybook native builders for Angular** (`@storybook/angular:start-storybook`, `@storybook/angular:build-storybook`). In your `project.json` (or `workspace.json` / `angular.json`) you should see the executor now being set to:
```json
"storybook":{
"executor":"@storybook/angular:start-storybook",
...
},
```
This avoids any potential downsides of options being different or not available and lowers the maintenance burden on our side going forward.
Storybook 6.5 also comes with support for using TS based Storybook configurations files, such as `main.ts` , `preview.ts` etc. We added support for that to our Storybook configuration generators.
For all the other cool Storybook features, please refer to their release [announcement](https://storybook.js.org/releases/6.5).
## Easy migration from Angular CLI to Nx
Nx is not only for large monorepos, but works really well for single-project Angular workspaces too! Why switch to Nx? We need an entire blog post for that (spoiler: coming soon 😉), but in a nutshell:
- everything from the Angular CLI still works
- you get faster builds, test runs, linting etc powered by Nx's task scheduling and caching
- more schematics (we call them generators in Nx) with specific support for SCAM, NgRX setup, module federation and micro frontend setup and much more to come (looking at you Standalone Components)
- better, out of the box integration with community tools such as Jest for unit testing, ESLint, Cypress, Storybook,…
- improved developer experience powered by the [Nx Console VSCode extension](/getting-started/editor-setup)
- …
In the last couple of weeks we've been working hard on making an automated migration from the Angular CLI to Nx as seamless as it can possibly get. And this can be tricky, believe us. We always had automated migrations, but we improved our existing ones and in addition also added support for multi-project Angular CLI workspaces.
All you need to do is to run the following command on your existing Angular CLI setup.
```
ng add @nrwl/angular
```
We try to infer your current setup and configuration and automatically migrate it, in addition to providing useful warnings and logs for the things we couldn't migrate along the way, such that you have the possibility to manually adjust things.
## More lightweight Nx
When you setup a new Nx workspace you can choose from a variety of presets (templates) that preconfigure your workspace in the best possible way, already setting up tool like Prettier, Jest, ESLint and Cypress. For some folks however, this might seem too much.
For that, Nx always already had the — what we call — "Nx Core" setup. You can read more about [that on our guide](/getting-started/intro), but it basically allows Nx to be used without its plugins, just for the fast, powerful task scheduling and caching capabilities.
In v14 we already simplified Nx (we have a whole section in [our release blog post](/blog/nx-v14-is-out-here-is-all-you-need-to-know)) and in v14.2 we even go a step further: **we made `nx.json` optional**, providing some reasonable defaults. Now, if you want to add Nx's powerful task scheduler to an existing repository, all you need to do is to add the `nx` package as a dependency and you're all set up.
Whenever you need to fine-tune the default settings you can run the following command to get a `nx.json` generated or you can obviously create it by hand:
```shell
npx nx init
```
## Run Nx graph on any monorepo!
Speaking about lightweight Nx. With Nx v14.2.3 you can now just run
```shell
npx nx graph
```
to download the Nx package, have it analyze your monorepo's project graph and visualize it in its powerful project graph UI. Give it a try. Here's Victor demoing it on the Next.js and Babel.js repository!
Part of our team has been heads-down on Lerna in the past month since we [took over stewardship of Lerna](/blog/lerna-is-dead-long-live-lerna). And apart from releasing Lerna 5 with important package upgrades, we wanted to solve Lerna's biggest pain point: being slow. [We published an article](/blog/lerna-used-to-walk-now-it-can-fly) on how we envision that strategy 2 weeks ago and as part of that we've been digging deep into the Nx core and have been doing some proper profiling.
The result: Nx itself got faster as well 😃.
Here's the result of running our benchmark using the latest version of Nx 14.2:
```plaintext
* average lage time is: 10203.6
* average turbo time is: 1532.3
* average lerna (powered by nx) time is: 272.2
* average nx time is: 194.8
* nx is 52.379876796714576x faster than lage
* nx is 7.866016427104722x faster than turbo
* nx is 1.3973305954825461x faster than lerna (powered by nx)
```
(as always, feel free to [reproduce it here](https://github.com/vsavkin/large-monorepo))
## Dedicated Linting support for Nx Plugins
Only the possibility of being able to tailor and customize the processes and behavior of your monorepo tooling to your own needs, makes working with it pleasant and allows you to get most out of it. Whether it is to customize the code generation aspect to your company coding styleguide and best practices, to automate the setup of new projects or even add support for languages such as Go, .Net or Flutter. [Nx Plugins](/community) enable such support and really help you make Nx work in the best possible way for your current scenario.
Nx plugin support has been around for a while. Just have a look at our [Nx community plugins page](/community). And we keep improving it. We added support for [Nx Plugin presets](https://www.youtube.com/watch?v=yGUrF0-uqaU) and [lately also the ability for local plugins](/blog/nx-v14-is-out-here-is-all-you-need-to-know). In this release, we add proper **linting support for Nx Plugin development**.
Ever happened to you that you mistyped the implementation file in your `generators.json` configuration file of your plugin? Well guess what, now the linting process would warn you about:
If you have an existing plugin, you can run the following generator to add the new lint rules:
```shell
npx nx g @nrwl/nx-plugin:plugin-lint-checks --projectName=awesomeplugin
```
## 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're already deep into following our v15 [roadmap](https://github.com/nrwl/nx/discussions/9716) with a lot of cool stuff coming up on the horizon.
Makes 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)!
description: 'Nx 14.4 enhances build caching with configurable inputs, simplifies workspace setup with optional npm scope, and optimizes CI performance with project graph improvements.'
---
Our [last release blog post](/blog/nx-14-2-angular-v14-storybook-update-lightweight-nx-and-more) has been published not even a month ago and we already released 2 more minors. You missed the releases? No worries, we've got you covered. Here's all you need to know.
## targetDependencies -> targetDefaults
To get things started, `targetDependencies` got renamed to `targetDefaults`. We originally named them `targetDependencies` because you were able to define dependencies among project targets (e.g. to run the `build` target of dependent projects). See the next section for some more info about that.
You could always do more though. However, with our current mission to reduce configuration duplication, the now-called `targetDefaults` will get more powerful by allowing you to define sensible defaults for your project configs in a central place.
> _Don't worry, if you're using `nx migrate` it'll handle the rewriting for you._
## Syntactic sugar for "dependsOn"
One of the key features of the Nx task scheduling system is that it is able to automatically build/test/lint/{name your operation} dependencies of your project. If you have `proj-a` which has a dependency on `proj-b` and we run `nx build proj-a` then Nx automatically builds `proj-b` before building `proj-a`. Why? Because `proj-a` depends on the output of `proj-b`.
These target defaults can be defined
- globally at the `nx.json` level for all the projects in the workspace
- per project level in the `project.json`/`package.json` depending whether you use the [project.json config option](/reference/project-configuration) or [package.json](/reference/project-configuration)
You can still use the same notation as you did until now:
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
"dependsOn": [
{
"target": "build",
"projects": "dependencies"
}
]
}
},
...
}
```
With this release we introduce another, much more concise and elegant way of expressing the same:
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
"dependsOn": ["^build"]
}
},
...
}
```
Similarly, if you don't specify the `^` it would be the same as writing the following:
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
"dependsOn": [
{
"target": "prebuild",
"projects": "self"
}
]
}
},
...
}
```
In that case target `prebuild` on the project itself is invoked before running its `build` target.
## Inputs, Named Inputs, ENV and runtime variables
In order to improve cache hits we added the possibility to define `inputs`. For example on the `build` target, you could define the following input glob pattern to avoid cache invalidation when only spec files got changed.
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
"inputs": ["!{projectRoot}/**/*.spec.ts"]
}
}
}
```
You can have as many inputs as you like. Also, in order to avoid ambiguity when specifying the path, you need to use either `{projectRoot}` or `{workspaceRoot}` in the glob pattern.
Since you might want to **reuse certain patterns across multiple targets**, we also introduced `namedInputs`, which allows you to define a set of patterns that can then be referenced in the various `targetDefaults`:
```json {% fileName="nx.json" %}
{
...
"namedInputs": {
"prodFiles": ["!{projectRoot}/**/*.spec.ts"]
},
"targetDefaults": {
"build": {
"inputs": ["prodFiles", "^prodFiles"]
},
"publish": {
"inputs": ["prodFiles", "^prodFiles"]
}
}
}
```
Note, by also adding `^` in front of the named input pattern, it also gets applied to all dependent projects, just like with the `dependsOn` definition.
**Inputs can not only just be file globs, but also runtime or environment variables**. This makes the `inputs` even more powerful and helps improve cache hits. In the following example, the environment variable "SELECTED_CLI", as well as the runtime output of running `node -v` would be included in the computation of the hash used for storing the cached result.
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"e2e": {
"inputs": [
{
"env": "SELECTED_CLI"
},
{
"runtime": "node -v"
}
]
}
}
}
```
> _Note that `targetDefaults` is just a way to specify project-specific settings in a central place within the `nx.json`. All of these can directly also be added to the `package.json` or `project.json` (depending on which approach you use for configuring your projects)._
Check out the following video which goes into some of the details on the example of a [Lerna](https://lerna.js.org/) monorepo that uses the new Nx inputs configuration.
{% youtube src="https://youtu.be/u91YHPwddEM" /%}
## Optional npmScope
When you create a new Nx workspace it sets up a "npm scope" which you can find in the `nx.json`.
```json {% fileName="nx.json" %}
{
"npmScope": "myorg",
...
}
```
Although most of the time you might want to use one, it is not mandatory any more. This contributes to our mission of simplifying Nx and making it more flexible.
## Speeding up workspace config computation
Project configuration calculations can take up quite some time in large workspaces. Starting with v14.4 we offloaded that part to the [Nx Daemon](/concepts/nx-daemon), optimizing the overall command execution time in particular for large workspaces.
## New NX_PROJECT_GRAPH_CACHE_DIRECTORY
When using shared volumes on CI, different consumers of the cache can write a different project graph to the cache, thus overwriting one that may be in use by other consumers. Up until now, there was no way to specify a different cache directory just for the project graph.
With this release, we introduce a new `NX_PROJECT_GRAPH_CACHE_DIRECTORY` environment variable to dictate where Nx (and the Nx Daemon) should store the project graph cache.
## Angular updates
In Nx v14.2 we [also shipped the Angular v14 migrations](/blog/nx-14-2-angular-v14-storybook-update-lightweight-nx-and-more) which went smoothly. We keep improving our support. In this release in particular we
- added support to generate Storybook stories also for Angular standalone components
- upgraded `@angular-eslint/*` to version 14
- added support for `ngrx` version 14
## 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're already deep into following our v15 [roadmap](https://github.com/nrwl/nx/discussions/9716) with a lot of cool stuff coming up on the horizon.
Makes 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)!
description: Learn to set up a monorepo with PNPM workspaces for Remix and React projects, then enhance it with Nx's task scheduling and caching features.
---
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.
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.
@@ -37,9 +38,9 @@ In this article we’re going to have a deep dive into setting up a new monorepo
## Initialize a new PNPM workspace
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.
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.
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
@@ -53,7 +54,7 @@ It is probably also handy to initialize a new Git repository such that we can co
git init
```
At this point let’s also create a `.gitignore` file to immediately exclude things like `node_modules` and common build output folders.
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
@@ -68,7 +69,7 @@ The structure of a monorepo might vary depending on what you plan to use it for.
- **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.
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`:
@@ -76,7 +77,7 @@ 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:
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:
@@ -88,7 +89,7 @@ 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.
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._
@@ -99,7 +100,7 @@ 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 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:
@@ -122,7 +123,7 @@ Usually, in a monorepo you want to run commands from the root of the repository
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`:
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
{
@@ -143,7 +144,7 @@ pnpm --filter my-remix-app dev
## Create a Shared UI library
Now that we have our app set up, let’s create a library package that can be consumed by our application.
Now that we have our app set up, let's create a library package that can be consumed by our application.
```shell
@@ -152,7 +153,7 @@ mkdir shared-ui
```
Next, let’s create a `package.json` with the following content (you can also use `pnpm init` and adjust it):
Next, let's create a `package.json` with the following content (you can also use `pnpm init` and adjust it):
```json
{
@@ -170,7 +171,7 @@ Next, let’s create a `package.json` with the following content (you can also u
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:
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
@@ -196,7 +197,7 @@ We also want to have a public API where we export components to be used outside
export * from './Button';
```
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.
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.
@@ -376,13 +377,13 @@ This is exactly where Nx can help. It is optimized for monorepo scenarios and co
## 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`.
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.
That's it.
## Running tasks with Nx
@@ -394,7 +395,7 @@ 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:
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._
> _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.
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
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" %}
{
@@ -456,7 +457,7 @@ In order to enable caching, let’s configure our cacheable operations. To do th
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.
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.
```shell
npx nx build my-remix-app
@@ -480,7 +481,7 @@ 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.”
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.
@@ -600,7 +601,7 @@ Next, we also want to define a targetDefault for our Remix `dev` command, such t
}
```
Here’s the entire `nx.json` file again as a reference point:
Here's the entire `nx.json` file again as a reference point:
```json
{
@@ -635,7 +636,7 @@ _Nx highlights dependent projects being built, but it keeps the main attention t
## 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).
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>
@@ -648,7 +649,7 @@ You can use any target you have defined in your workspace. For example
- `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:
**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:
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
@@ -680,7 +681,7 @@ 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:
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?
@@ -718,12 +719,12 @@ _Terminal output of Nx dynamically showing the parallel tasks being computed as
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.
This launches an interactive visualization of the workspace's project graph with some advanced capabilities of filtering, debugging your workspace structure and more.
description: 'Nx 14.5 adds Cypress v10 with component testing, glob-based outputs for better caching, and improved React Tailwind integration.'
---
Here we go! After not even a month of [releasing v14.4](/blog/nx-14-4-inputs-optional-npm-scope-project-graph-cache-directory-and-more), Nx v14.5 is out!! Here's all you need to know.
Cypress v10 is probably the most significant update since Cypress was released. It comes with a new, exciting [Cypress App](https://docs.cypress.io/guides/core-concepts/cypress-app), component testing beta, a new JS/TS-based configuration file and much more. Read all the details in [their official announcement](https://www.cypress.io/blog/2022/06/01/cypress-10-release/).
One of the strengths of Nx is to integrate various tools into a cohesive, high-quality experience. Working together with other companies and open source projects is key to making sure we meet this goal. We have had an ongoing relationship with the folks over at Cypress for years already and have been working closely with them since earlier this year to integrate v10 into Nx in the best possible way.
This includes an upgrade script to automatically migrate Nx users using Cypress v9 seamlessly to v10. By running…
```shell
nx g @nrwl/cypress:migrate-to-cypress-10
```
…your workspace will be automatically upgraded to the latest Cypress version.
Cypress v10 also comes with a beta version of [Component Testing](https://docs.cypress.io/guides/component-testing/writing-your-first-component-test). Nx v14.5 comes with an integrated generator to add component testing support to React-based project:
```shell
nx g @nrwl/react:cypress-component-configuration --project=my-react-project --generate-tests
```
You can also append the `--generate-tests` to automatically generate Cypress component tests for the existing components in the target project (`my-react-project`).
```shell
nx g @nrwl/react:cypress-component-configuration --project=my-react-project --generate-tests
```
Check out our [generator docs](/nx-api/react/generators/cypress-component-configuration) for more info.
{% youtube src="https://youtu.be/QDWN4C7T-Ck" /%}
## Globs for Task Outputs
In v14.4 we [introduced inputs and namedInputs](/blog/nx-14-4-inputs-optional-npm-scope-project-graph-cache-directory-and-more). They allow you to fine-tune how caching works and when it should be invalidated.
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
"inputs": ["!{projectRoot}/**/*.spec.ts"]
}
}
}
```
Specifying such inputs can drastically increase the number of cache hits!
In this release, we also allow specifying globs for `outputs`. Outputs are optional as Nx comes with reasonable defaults, but you can specify your own if your setup differs from the most commonly used ones:
```json {% fileName="nx.json" %}
{
...
"targetDefaults": {
"build": {
...
"outputs": ["dist/libs/mylib"]
}
}
}
```
Globs are particularly useful when multiple targets write to the same directory. Say you have a `build-js` and `build-css` command and both write into `dist/libs/mylib`. For reasons of clarity, if possible, our recommendation is to split them up. Like:
```json {% fileName="nx.json" %}
{
"build-js": {
"outputs": ["dist/libs/mylib/js"]
},
"build-css": {
"outputs": ["dist/libs/mylib/css"]
}
}
```
Sometimes that's not feasible though. In that case, globs come in handy:
```json {% fileName="nx.json" %}
{
"build-js": {
"outputs": ["dist/libs/mylib/**/*.js"]
},
"build-css": {
"outputs": ["dist/libs/mylib/**/*.css"]
}
}
```
[Read more in our docs](/reference/project-configuration)
## Parameter Forwarding when building dependent projects
Besides the speed aspect, one key feature of Nx is the ability to build dependent projects automatically. Let's say you have `project-a` which depends on `project-b`, then whenever you run the build for `project-a`, thanks to its project graph, Nx will automatically run the build for `project-b` first. You can define such dependencies either directly in your [project.json](/reference/project-configuration) or [package.json](/reference/project-configuration) file, or globally for an entire workspace in `nx.json`:
...and defines that the `build` task should be run for all its dependencies first.
> _You have a PNPM,NPM or Yarn workspace? Adding Nx doesn't only benefit you in terms of speed improvements, but also to define such build dependencies. Have a look at this video to learn more:_ [_Setup a monorepo with PNPM workspaces and add Nx for speed: Defining task dependencies aka build pipelines_](https://youtu.be/ngdoUQBvAjo?t=1485)
What happens to parameters when invoking the target on a project's dependencies? By default, they are not forwarded but starting with 14.5 you can. Here are some configuration options:
```json
"build": {
// forward params passed to this target to the dependency targets
Replacing `Sets`, `foreach`, `reduce` with plain `for` loops can often have quite a significant impact. You won't notice much on smaller projects, but on large Nx workspaces with 500+ projects you should see some huge improvements 🚀.
## Support for banned external imports lint checks on transitive dependencies
The [Nx Module Boundary lint rule](/features/enforce-module-boundaries) is a powerful concept especially when it comes to the maintainability aspect of projects and monorepos. Learn more in our blog article on [Taming Code Organization with Module Boundaries in Nx](/blog/mastering-the-project-boundaries-in-nx).
The Module Boundary rule allows for much more though. It also allows to ban external imports. Say you have a frontend project where you want to make sure none of the "backend-type" dependencies accidentally get imported. Or vice-versa, a backend project where you wouldn't necessarily want to depend on any "frontend-type" package references. You can use the `bannedExternalImports` for that. For example:
```json {% fileName=".eslintrc.json" %}
{
// ... more ESLint config here // nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
"error",
{
"allow": [],
// update depConstraints based on your tags
"depConstraints": [
// projects tagged with "frontend" can't import from "@nestjs/common"
{
"sourceTag": "frontend",
"bannedExternalImports": ["@nestjs/common"]
},
// projects tagged with "backend" can't import from "@angular/core"
{
"sourceTag": "backend",
"bannedExternalImports": ["@angular/core"]
}
]
}
] // ... more ESLint config here
}
```
Note, the `frontend` and `backend` `sourceTag` definition is something you define. You could have easily named it differently. It is a string that can be attached to a project by adding it to the `tag` property of its `project.json` configuration file. Read more about banned external imports [in our docs](/features/enforce-module-boundaries).
Starting with 14.5 we now support such checks also on transitive dependencies. Assume we have `project-a` and `project-b`, both of which are tagged as `framework-agnostic` and have `react` in their banned external imports. Also, assume there's a relationship like `project-a -> project-b`. If `project-b` imports `react` and we run linting, it fails correctly. However, if we run linting on `project-a`, it succeeds as `project-a` is not importing `react` at all, thus not breaking the lint rule. In most situations, this is fine because linting happens at a project level, but sometimes you might want to have a "transitive" behavior where linting would also fail for `project-a` because it imports `project-a` which imports `react`.
You can now enable such behavior by setting `checkNestedExternalImports` to `true`:
```json {% fileName=".eslintrc.json" %}
{
// ... more ESLint config here // nx-enforce-module-boundaries should already exist at the top-level of your config
"nx-enforce-module-boundaries": [
"error",
{
"allow": [],
"checkNestedExternalImports": true,
// update depConstraints based on your tags
"depConstraints": [
// projects tagged with "frontend" can't import from "@nestjs/common"
In v13.10 we introduced automated fixes for the Nx Module Boundary rules. Wrong relative imports such as the following can be easily adjusted automatically by providing the `--fix` when running linting on the project.
This is a huge time saver, especially on large projects. With Nx v14.5 the automated fixes now also support automated resolution of absolute imports across library boundaries, such as
```typescript
// WRONG
import { libSayHi } from 'libs/tslib-a/src/index';
// automatically fixed to
import { libSayHi } from '@myorg/tslib-a';
```
## Nx Migrate improvements and Nx Repair
We improved our log output from the Nx automated code migration run to make it more clear what a code migration actually changes. Also, those migrations that don't do anything because they don't apply to your workspace are not shown in the output at all.
This automatically sets up your project with a PostCSS and Tailwind configuration.
## React Native: Add Detox config to Expo apps
We also improved our React Native support by adding the possibility to generate a [Detox](https://wix.github.io/Detox/) config for Expo applications.
## Deprecating Angular Protractor e2e tests
[Protractor](https://github.com/angular/protractor/issues/5502) has been deprecated for a while on the Angular CLI side and given Nx has had [Cypress](https://cypress.io/) support for a while it has never been a popular choice. Starting with this release we're deprecating the generator for setting up Protractor and we're planning on removing support entirely in Nx v15.
## Other Package updates
Here are some more package updates that come with this release and will automatically be bumped when you run the Nx migration:
- Angular v14.1.0
- Express 14.18.1
- Nest v9
- Next.js v12.2.2
- React Native 0.69.1
- React Native Metro v0.71.3
- React 18.0.15
- `eslint-plugin-jsx-a11y` v6.6.1
For an exhaustive list check our release changelog on GitHub: [https://github.com/nrwl/nx/releases/tag/14.5.0](https://github.com/nrwl/nx/releases/tag/14.5.0)
## 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)
description: "Discover how Nx's caching and computation-saving features have saved over 200 years of compute time, reducing CO2 emissions through efficient task execution."
---
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?**
@@ -44,7 +45,7 @@ Calculating the CO2 emissions can be tricky. It really depends on what machines
## 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.
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
@@ -93,5 +94,5 @@ How to enable it? [Read more on the Lerna docs](https://lerna.js.org/docs/featur
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
description: Lerna v6 brings default Nx integration, remote caching, PNPM support, dynamic terminal output, and improved task management to speed up your monorepo builds.
---
Lerna v6 is out!! Here’s everything you need to know about the **new Lerna experience!**
Lerna v6 is out!! Here's everything you need to know about the **new Lerna experience!**
**Table of Contents**
@@ -26,7 +27,7 @@ Lerna v6 is out!! Here’s everything you need to know about the **new Lerna exp
## 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.
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!**
@@ -34,7 +35,7 @@ Since we took over, in May 2022, it has been an absolute rollercoaster. We launc
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`:
So far you had to enable "Nx support" by setting the `useNx` flag in `lerna.json`:
```
// lerna.json
@@ -44,7 +45,7 @@ So far you had to enable “Nx support” by setting the `useNx` flag in `lerna.
}
```
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.
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:
@@ -63,144 +64,6 @@ To experience fast caching, ensure you have a `nx.json` file at the root of your
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.
description: 'Explore the major features and improvements introduced in Nx version 15, including enhanced performance and developer experience.'
---
Nx v15 is finally here! Let's go through all the great features that went into this major release.
{% toc /%}
## Growing fast!
Nx is currently at **~2.7 million NPM downloads per week**, which is incredible given we just crossed the 1 million downloads/week at the beginning of this year.
Expect it to see growing much faster even in the coming months.
## Performance — Core, Nx Daemon
Performance optimizations are a recurring theme for us. We're continuously optimizing Nx to make it even faster than it is now.
For example, when a cache hit needs to restore artifacts to some "dist" folder, we don't touch the file system if it is not needed (because FS operations are costly). As a result, this would also not mess with any "watch" process on your dist folder, which you might use. And obviously, we detect whenever a file is missing. If you delete a single file from your "dist" folder, Nx will know and restore it properly.
This is possible because we offload some of the computation to a daemon process. This runs in the background to compute heavy operations like ensuring the project graph is always in sync, watching cache output locations and more.
You can read more about it here: [/concepts/nx-daemon](/concepts/nx-daemon)
## Package-based and Integrated Style Monorepos
In our 5 years of working with small and huge monorepos we've seen various setups. We've narrowed them down to two approaches:
- **package-based monorepos** — a collection of packages where each package within the monorepo is treated as a fully independent package. Meaning they have their own `package.json` with dependencies declared. To share and link packages locally within the monorepo, the "workspaces" feature from NPM/Yarn/PNPM can be used. Tools for this style are Nx, Lerna, Lage and Turbo.
- **integrated monorepos** — is usually a pre-configured and managed setup. You don't have to rely on NPM/Yarn/PNPM workspaces for local linking and tooling helps with the low-level tooling setup and integrating various tools. Tools for this style are Nx and Bazel.
We improved and optimized Nx to be the best solution for both approaches. As part of this optimization, starting with Nx v15, when you run
```shell
npx create-nx-workspace
```
...you will now get a new question about whether you want to create a package-based monorepo or integrated style monorepo.
There will be more content around choosing which style and even how to mix the two. Go with what works best for you and your current situation, and Nx will be there to handle the rest.
We also updated our docs to have two super short tutorials that illustrate the two approaches:
You can also read more about the concept here: [/deprecated/integrated-vs-package-based](/deprecated/integrated-vs-package-based)
## New Compact Syntax for Task Pipelines
Monorepos typically do not just have dependencies among projects but also among tasks. Let's say you have a Remix app that depends on some `shared-ui` React-based library. Whenever you build or serve your app, `shared-ui` gets built before. This is required - especially in a package-based monorepo - because connected packages depend on the build artifacts, that is the compiled JS files.
You can define such a relationship easily in the `nx.json` by specifying the `targetDefaults` property. Nx had this for a while, but as part of some v14 minor version, we made it more concise.
Here's an example:
```json {% fileName="nx.json" %}
{
"targetDefaults": {
// run the build of all dependent packages first
"build": {
"dependsOn": ["^build"]
},
"dev": {
"dependsOn": ["^build"]
},
// run a package's build task before running publish
"publish": {
"dependsOn": ["build"]
}
}
}
```
You can read more here: [/concepts/task-pipeline-configuration](/concepts/task-pipeline-configuration)
## Fine-tune Caching with Inputs
Nx's caching is already powerful, but you can get even more out of it by fine-tuning it to your workspace's needs. This is done by defining `inputs` in `nx.json` for the various targets.
Here, for instance, we define that the `build` target should include all the files of a given project but not include test-related files. As a result, changing a Jest spec won't invalidate your `build` target cache.
Since these inputs are often re-used across different targets, they can be defined in a dedicated `namedInputs` property (think like a variable declaration) and re-used in the `targetDefaults`.
Here's an example of the defaults that a new Nx workspace comes with:
You can read more here: [/recipes/running-tasks/configure-inputs](/recipes/running-tasks/configure-inputs)
## Nx Console
Nx Console has evolved to be a key part of Nx's mission to improve the life of developers when working with Nx (and now also Lerna) monorepos. There have been tremendous improvements over the last couple of months. Here are some highlights!
The famous, so much loved [Nx Graph](/features/explore-graph) can now also be visualized within VSCode directly:
Every now and then, it's time to revamp our website. Because it doesn't feel as fresh as it did when you originally created it. So here we go! We created a new, condensed entry page with the most relevant information,
It is an ongoing process, and we have a lot of content to cover! We follow the [Diataxis](https://diataxis.fr/) framework for structuring our technical content where we want to clearly assign responsibilities to each page content, so it's easy for you to get out of it what you most need. It is mostly structured around whether
- you want to get a deeper understanding of core concepts ("Concepts" section)
- you want to learn something new ("Tutorial" section) or
- you want a solution to a specific problem ("Recipes" section).
Besides the two new [package-based](/getting-started/tutorials/typescript-packages-tutorial) and [integrated style tutorials](/getting-started/tutorials/react-monorepo-tutorial) we also have two brand new reworked tutorials
## Cleanup for pure JS/TS packages and ESBuild support!
We streamlined our JavaScript / TypeScript packages to have dedicated ones for our bundlers:
- `@nrwl/webpack`
- `@nrwl/rollup`
- `@nrwl/esbuild` (NEW!)
So you can now generate a new JavaScript / TypeScript based package using the `@nrwl/js:lib` generator, which now allows you to choose between various builders:
And for those wondering. Yeah, [Vite](https://vitejs.dev/) is coming.
## Cypress v10 and Component Testing
Cypress has been an integral part of an Nx workspace for a long time. A couple of months ago, they shipped one of their biggest updates: Cypress v10. We've been working closely with the team to coordinate the integration into Nx and ensure it is as smooth as possible.
You can run the following command to migrate your existing Cypress to the latest version.
```shell
npx nx g @nrwl/cypress:migrate-to-cypress-10
```
Cypress v10 also comes with [Component Testing](https://docs.cypress.io/guides/component-testing/writing-your-first-component-test) (for React and Angular), and we provide generators for that to help you get started. You can add component testing to an existing project with
```shell
npx nx g @nrwl/react:cypress-component-configuration --project=your-projectnpx nx g @nrwl/angular:cypress-component-configuration --project=your-project
```
Read more here: [/recipes/cypress/cypress-component-testing](/recipes/cypress/cypress-component-testing)
## Angular: Improved Angular CLI Migrations and Standalone Components
We landed generators to support Angular developers in leveraging the new standalone components API in their Nx-based projects. Here's a preview:
In addition, we improved the migration support for moving projects from the Angular CLI to an Nx workspace. Whether for a single Angular CLI project or to consolidate multiple Angular CLI projects into a single Nx workspace. Please read all about it here: [/recipes/angular/migration/angular](/recipes/angular/migration/angular)
## Easily add Nx to an existing repository
You can easily add Nx to an existing repository. This can be done manually by adding the `nx` NPM package or by running the following command:
```shell
npx nx@latest init
```
It is as easy as it looks. The command analyzes the current workspace and then asks you a couple of questions to set up your workspace (including cacheable operations and configuring a task pipeline).
description: Nx raises $8.6M seed round led by Nexus Venture Partners and A16z to scale open source Nx, Nx Cloud, and Nx Enterprise, powering 75% of JavaScript monorepo tooling.
---
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**.
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.
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.
[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.
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.
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.
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.
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 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)!
We'll be sharing more exciting announcements soon, so make sure to follow our journey on [@NxDevTools](https://twitter.com/nxdevtools)!
description: Nx 15.3 introduces standalone projects, Vite and Vitest tooling, enhanced task graph visualization, and simplified project adoption, now reaching 3M weekly downloads.
---
What a massive release! Here are all the news 👇
@@ -28,14 +29,14 @@ Prefer **a video version?**
## Funding — Nx raises $8.6M
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)
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)
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:
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
@@ -51,7 +52,7 @@ On to 4 million!
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`
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" %}
@@ -89,7 +90,7 @@ In 15.3 we are therefore making **standalone projects** a first-class feature. S
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:
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/
@@ -136,15 +137,15 @@ 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.
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!
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!!
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.
@@ -160,7 +161,7 @@ This new setup gives you an easy jumpstart as it does all the configuration for
- 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:
Open the application's `project.json` to inspect the setup:
```json
{
@@ -189,7 +190,7 @@ Open the application’s `project.json` to inspect the setup:
}
```
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.
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:
@@ -199,11 +200,11 @@ 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)
You can also find all the details about the new Vite package in 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!
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
@@ -228,7 +229,7 @@ Check out our docs for all the details on
- [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 👇
Oh..you're wondering why you would want to add Nx to an existing non-monorepo project? Then keep reading 👇
## Adding Nx to an Existing Standalone Project
@@ -243,7 +244,7 @@ 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.
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
@@ -251,7 +252,7 @@ To add Nx to an existing standalone project, all you need to run is
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.
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
{
@@ -270,13 +271,13 @@ This process will ask you a few questions about which operations are cacheable.
}
```
Read more on our docs: [/recipes/adopting-nx/adding-to-existing-project](/recipes/adopting-nx/adding-to-existing-project)
Read more in 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.
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`.
@@ -311,7 +312,7 @@ 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)
Read more about it in our docs: [/recipes/running-tasks/root-level-scripts](/recipes/running-tasks/root-level-scripts)
## Simplified Nx run-commands
@@ -344,7 +345,7 @@ Nx can automatically detect your scripts in `package.json`. But if you have an i
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:
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" %}
{
@@ -383,13 +384,13 @@ For simple commands this was a huge overhead, so we simplified it to just this:
}
```
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.
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)
You can read all about it in 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
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
description: Nx 15.4 adds Vite 4.0 support, new Watch command for file watching, webpack-less Cypress support, SSR for Module Federation, and parallel target execution improvements.
---
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:
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)
@@ -27,11 +28,11 @@ Nx 15.4 brings in the latest Vite major version following the Vite 4 release ear
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!
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:
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
@@ -45,7 +46,7 @@ You can check out more details about our Vite plugin including how to add Vite a
{% youtube src="https://youtu.be/0eVplUl1zBE" /%}
Nx 15.4 includes a new feature to support file-watching with Nx! Here’s how it works:
Nx 15.4 includes a new feature to support file-watching with Nx! Here's how it works:
Syntax:
@@ -64,9 +65,9 @@ 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.
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:
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.
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.
@@ -93,7 +94,7 @@ Now you can get the benefits of both Server Side Rendering and Module Federation
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.
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)!
Last but not least, we’ve added support for interactive prompts for Custom Presets!
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:
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:
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 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!
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.
## 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!
description: Learn how to implement Webpack Module Federation with Server-Side Rendering in Angular applications using Nx for improved performance and micro-frontend architecture.
---
[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.
@@ -29,7 +30,7 @@ A traditional SSR application is rendered on the server. It receives the request
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.
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.
@@ -37,13 +38,13 @@ This gives us full power of SSR but also still allowing us to break our build in
## 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).
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.
You'll be prompted for the type of workspace you want to create, and the preset to use.
Answer with the following:
@@ -51,7 +52,7 @@ Answer with the following:
✔ 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/)_._
> _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`.
@@ -91,11 +92,11 @@ 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:
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:
@@ -103,15 +104,15 @@ 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!
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!
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::
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::
description: Learn how to quickly set up a modern React application with Vite and TypeScript using Nx, featuring built-in testing, linting, and development tools.
---
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.
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
@@ -29,7 +30,7 @@ Let’s be honest. Dealing with tooling is not something enjoyable if you have t
{% 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
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
@@ -38,14 +39,14 @@ Traditionally, you might lean towards [Create-React-App (CRA)](https://create-re
- 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.
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 🤔”_
> **_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**.
So let's go and set up our **React + Vite + TypeScript project**.
## How do I create a new project setup?
@@ -65,13 +66,13 @@ And then choose the option you prefer in the terminal prompt:
First off, let’s run our new, shiny application. Just invoke
First off, let's run our new, shiny application. Just invoke
```
npm start
@@ -158,7 +159,7 @@ npx nx test
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
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)
@@ -199,7 +200,7 @@ This might look weird initially, but basically, we run the `e2e` target (see `e2
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)
> _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
@@ -209,7 +210,7 @@ And similarly, linting can be triggered by running the following command:
npx nx lint
```
There’s a `.eslintrc.json` file already at the workspace's root that contains some best practices rules.
There's a `.eslintrc.json` file already at the workspace's root that contains some best practices rules.
## Customize Vite and Vitest
@@ -250,7 +251,7 @@ Nx is known for its caching that helps optimize the speed in monorepos. Caching
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.
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)
@@ -269,7 +270,7 @@ Imagine a storefront application. You will probably have domain areas like
- 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:
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
@@ -301,13 +302,13 @@ cra-app
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:
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:
The above command creates a new " checkout " library in the `domains/orders/` folder. Here's what it looks like:
```
awesomereactapp
@@ -360,7 +361,7 @@ When generating the library, a TypeScript path mapping is automatically created
}
```
In this way, anything that’s being exported from the `checkout` library can be consumed like
In this way, anything that's being exported from the `checkout` library can be consumed like
```typescript
import { SomeComponent } from '@awesomereactapp/domains/orders/checkout';
@@ -394,9 +395,9 @@ It becomes even more interesting if you select the “Group by folder” checkbo
## 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.
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
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
{
@@ -441,13 +442,13 @@ In the `.eslintrc.base.json` you can then define the rules. Here for instance we
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).
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)”.
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
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
```shell
npx nx affected:graph
@@ -469,7 +470,7 @@ 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).
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.
@@ -479,7 +480,7 @@ It also comes with contextual menus to quickly access most of the commonly used
Here’s a walkthrough video showing some of the powerful capabilities of Nx Console:
Here's a walkthrough video showing some of the powerful capabilities of Nx Console:
{% youtube src="https://youtu.be/ZST_rmhzRXI" /%}
@@ -503,7 +504,7 @@ Read more about how [Nx migrations work](/features/automate-updating-dependencie
## 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:
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:
description: Nx Console 17.28.0 integrates Nx Cloud features directly into VSCode, bringing remote caching, distributed task execution, and VCS integration with streamlined setup.
---
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:
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. 😍
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.
@@ -24,7 +25,7 @@ Head over to [http://nx.dev/nx-cloud](/nx-cloud) to learn more.
## Show me the new features already!
Now that we’re caught up, let’s look at how Nx Console will make connecting to and working with Nx Cloud even easier.
Now that we're caught up, let's look at how Nx Console will make connecting to and working with Nx Cloud even easier.
To follow along, ensure you have installed the latest Nx Console version:
[Nx Console — Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
@@ -33,7 +34,7 @@ In the Nx sidebar, you will see a new Nx Cloud section.
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.
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.
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.
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 (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. 🚀
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).
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!
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!
description: A guide to managing configuration files effectively in modern development, exploring Nx's approach to infrastructure code maintenance through generators and migrations.
---
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?
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
@@ -22,9 +23,9 @@ Parcel advertises itself as a zero configuration bundler. This is mostly a react
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.
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.
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.
@@ -32,13 +33,13 @@ All of these efforts to skip the configuration step reach their limits at some p
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.
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.
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 Generators and Migration Generators
@@ -50,7 +51,7 @@ Nx has an elegant solution to this dilemma. There are three key parts.
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.
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.
@@ -58,13 +59,13 @@ Every Nx plugin provides migration generators that will automatically update the
## 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.
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.
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.
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.
description: Learn how to quickly set up React with Tailwind CSS using Nx's code generators, including migration from Create React App and automated configuration tools.
---
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).
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).
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:
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.
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
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 easily using the following command
@@ -58,7 +59,7 @@ You can pass `--vite=false` if you still want to keep the Webpack configuration
## 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:
Once you have a [Nx-based React](/getting-started/tutorials/react-monorepo-tutorial) setup, adding Tailwind is as easy as running:
```shell
$ npx nx g @nrwl/react:setup-tailwind
@@ -66,7 +67,7 @@ $ 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.
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)!!
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!!
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).
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.
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)
@@ -45,8 +46,8 @@ Please have a look at our updated guide: [/extending-nx/tutorials/organization-s
{% 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”.
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".
@@ -61,7 +62,7 @@ All the features Nx is known for also apply to backend development. That include
- **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!
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
@@ -77,7 +78,7 @@ New workspaces will always be created with the latest Angular version, but durin
$ 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.
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:
@@ -85,7 +86,7 @@ If you need to apply an Angular update that you previously skipped, you can coll
$ nx migrate latest --from=nx@<version>
```
In particular, we’re working on making that part more intuitive in upcoming versions.
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.
@@ -93,7 +94,7 @@ Also, have a look at our [updated docs](/recipes/tips-n-tricks/advanced-update)
{% 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.
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.
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!).
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:
@@ -111,12 +112,12 @@ Why is this useful? Glad you asked! Mostly for three reasons:
- 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:
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:
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';
@@ -150,7 +151,7 @@ Inspired by our new [Vite setup](/nx-api/vite), which allows for a more modular
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)
If you want to upgrade but still retain the previous behavior, we introduced an `isolatedConfig` mode that can be set to `false`. More details in our docs: [/recipes/webpack/webpack-config-setup](/recipes/webpack/webpack-config-setup)
## How to Update Nx
@@ -184,5 +185,5 @@ So keep an eye on our [Twitter](https://twitter.com/nxdevtools), [Youtube](https
- 🧠 [Nx Docs](/getting-started/intro)
- 👩💻 [Nx GitHub](https://github.com/nrwl/nx)
- 💬 [Nx Official Discord Server](https://go.nx.dev/community)
description: A practical guide to integrating NgRx Standalone APIs in Angular applications using Nx, with automated setup for state management.
---
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!
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!**
**Prefer a video version? We've got you covered!**
`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.
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.
Say false to Facades also.
@@ -96,7 +97,7 @@ Notice the addition of `provideEffects()` and `provideStore()` to the `providers
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.
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`
@@ -105,7 +106,7 @@ 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!
- 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:
@@ -114,11 +115,11 @@ Some files you may want to explore in your own time are:
## 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.
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).
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.
@@ -153,7 +154,7 @@ The command will also have generated our
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!
If you'd like to confirm the integration, you can run the following commands and see successful outputs!
description: Lerna 6.5 introduces idempotent publishing, multi-script execution, private package handling, and codebase improvements, with updates on Nx team maintenance.
---
In case you missed it, Lerna version 6.5 recently launched. We’ll catch you up on the latest Lerna news and newest features.
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
@@ -23,37 +24,37 @@ In case you missed it, Lerna version 6.5 recently launched. We’ll catch you up
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).
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:
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).
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.
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).
[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 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!
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)
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!
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.
"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:
@@ -63,13 +64,13 @@ The [`lerna publish` command](https://github.com/lerna/lerna/tree/main/libs/comm
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).
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:
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:
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.
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.
@@ -93,12 +94,12 @@ You can find more information on this change [here](https://github.com/lerna/ler
## 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:
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!
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).
@@ -123,4 +124,4 @@ You can find [a roadmap for all the features we plan to add in Lerna 7](https://
description: Build and deploy a Node.js API with Fastify, Nx, esbuild, Docker, and Fly.io.
---
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.
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/).
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**
@@ -21,7 +22,7 @@ We’ll be using [Fastify](https://www.fastify.io/) as the framework of choice.
· [Deploying the server](#deploying-the-server)
· [Summary](#summary)
**Prefer a video version? We’ve got you covered!**
**Prefer a video version? We've got you covered!**
@@ -57,7 +58,7 @@ 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.
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
@@ -101,7 +102,7 @@ There are trade-offs between speed versus confidence when it comes to unit versu
## 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/).
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.
@@ -118,7 +119,7 @@ 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.
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
@@ -131,7 +132,7 @@ NX Successfully ran target build for project api (16ms) Nx read the output from
```
We’ll touch more on the caching when we look at Docker support.
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.
@@ -188,9 +189,9 @@ $ docker run -p 3000:3000 -t api
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).
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.
Once you are ready, let's configure our project.
```
@@ -224,7 +225,7 @@ And you can open the deployed server using `fly open`.
description: Explore the technical journey of bringing Nx Console to JetBrains IDEs, featuring Language Server integration and Generate UI implementation for IntelliJ.
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
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,
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!
be sure to look out for the upcoming release because it's going to be another huge one!
### Table of Contents
@@ -38,7 +39,7 @@ be sure to look out for the upcoming release because it’s going to be another
· [Glueing it together](#glueing-it-together)
· [Looking ahead](#looking-ahead)
**Prefer a video version? We’ve got you covered!**
**Prefer a video version? We've got you covered!**
description: Nx 15.8 brings Rust-based hasher, IntelliJ IDE support, Deno integration, enhanced Node.js features, and Storybook CSF3 support for improved performance.
---
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.
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)
@@ -18,7 +19,7 @@ Just weeks after the [release of Nx 15.7](/blog/nx-15-7-node-support-angular-lts
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).
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 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.
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!**
@@ -61,13 +62,13 @@ When running these tests on Windows (not WSL), the Nx repo hashing timings turne
- 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.
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.
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**
@@ -87,7 +88,7 @@ As such, it should work on most CI and local developer machines. If we missed so
{% 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).
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.
@@ -109,9 +110,9 @@ Or generate a new library with:
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.
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.
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:
@@ -125,7 +126,7 @@ Developer tool CLIs are known for being, well, command-line interfaces. Nx comes
- [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.
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:
@@ -143,7 +144,7 @@ Nx Console has proven a highly valuable tool for exploring Nx generators. Especi
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`:
The property can be defined for the desired parameters in the generator's `schema.json`:
description: Explore Nx's integration with Rspack, the Rust-based Webpack alternative that offers 5-10x faster compilation for React apps in your monorepo.
---
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.
@@ -14,7 +15,7 @@ Almost a year ago [ByteDance](https://www.bytedance.com/) started developing a n
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 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.
@@ -46,7 +47,7 @@ All the usual Nx features, such as
..work out of the box.
But not just the “speed features”. All the code generators, automate code migrations, and [code editor extensions](/getting-started/editor-setup) work too.
But not just the "speed features". All the code generators, automate code migrations, and [code editor extensions](/getting-started/editor-setup) work too.
description: Nx Cloud 3.0 introduces a modern UI, faster cache management, enhanced DTE, VCS integrations, enterprise features, and a simplified pricing model.
---
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!
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!
**Table of Contents**
@@ -21,7 +22,7 @@ In the last couple of months we have quadrupled the team and have done some amaz
@@ -78,7 +79,7 @@ In addition to the GitHub, we expanded our Nx Cloud live status updates to work
We have extensive experience working with Fortune 500 companies, helping them scale their development using monorepos. This has given us valuable insight into the unique security requirements of these companies. Our [Enterprise plan](/enterprise) reflects that allowing organizations to have a **fully self-contained version of Nx Cloud** that can be **hosted on their own servers** and comes with dedicated support from the Nx and Nx Cloud core team.
We’ve recently made a couple of improvements to our enterprise offering.
We've recently made a couple of improvements to our enterprise offering.
- **Helm Charts** — We added a **Helm chart** to simplify the process of deploying Nx Cloud to on-premises infrastructure, allowing organizations to quickly set up and manage their own instance of Nx Cloud within their secure environment.
- **Stability improvements** — We significantly reworked our on-premises solution to be identical to our SaaS deployment. This revamp resulted in a more robust and reliable on-premises deployment of Nx Cloud, ensuring enterprise-grade performance and reliability.
@@ -90,7 +91,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](/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.
@@ -104,9 +105,9 @@ Learn more at [/pricing](/pricing).
## Coming Next
We’ve got some big plans for Nx Cloud. You really want to write your CI script by focusing on what you want to achieve rather than thinking about making it fast. We’re going to make this happen!
We've got some big plans for Nx Cloud. You really want to write your CI script by focusing on what you want to achieve rather than thinking about making it fast. We're going to make this happen!
The current Distributed Task Execution (DTE) already goes a long way, but you still have to provision the agents by yourself. Providing the correct number of agents is crucial for maximizing efficiency and reducing idle time. And it is not even a static number but might depend on the actual run itself. Nx has extensive knowledge about the structure of the workspace and according tasks. We want to leverage that information. Imagine a setup where you have a roughly 20 line CI config for a repo with hundreds of developers and Nx Cloud automatically determines for each run the ideal number of agents required, provisions them, distributes all tasks efficiently and then disposes all agents again. All fully automatically. And it will be fast. To the point where you wouldn’t even need your Jenkins, CircleCI etc at all.
The current Distributed Task Execution (DTE) already goes a long way, but you still have to provision the agents by yourself. Providing the correct number of agents is crucial for maximizing efficiency and reducing idle time. And it is not even a static number but might depend on the actual run itself. Nx has extensive knowledge about the structure of the workspace and according tasks. We want to leverage that information. Imagine a setup where you have a roughly 20 line CI config for a repo with hundreds of developers and Nx Cloud automatically determines for each run the ideal number of agents required, provisions them, distributes all tasks efficiently and then disposes all agents again. All fully automatically. And it will be fast. To the point where you wouldn't even need your Jenkins, CircleCI etc at all.
In addition, we are actively exploring ways to provide advanced analytics for your workspace, including insights into the frequency and duration of specific tasks. This valuable information can help identify large tasks that could benefit from being broken down into smaller ones, leveraging caching and other speed improvements to optimize performance. Stay tuned for more to come!
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!
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!
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
@@ -21,7 +22,7 @@ But before we jump into the new features of Nx 16, let’s recap some of the rec
### Table of Contents
· [Here’s how to Upgrade with Nx Migrate](#heres-how-to-upgrade-with-nx-migrate)
· [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)
@@ -29,7 +30,7 @@ But before we jump into the new features of Nx 16, let’s recap some of the rec
· [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
## 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.
@@ -41,7 +42,7 @@ 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..
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..
description: Introducing the Nx Champions program, recognizing and supporting community leaders in Nx expertise, content creation, and community bridging.
---
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.
@@ -19,7 +20,7 @@ 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.
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.
description: A guide to user location detection using Nx and Netlify Edge Functions, with serverless function setup, IP geolocation integration, and deployment for region-aware web apps.
---
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.
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:
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 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.
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:
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)
> 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:
@@ -88,7 +89,7 @@ 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!
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)
@@ -96,7 +97,7 @@ For example, ours can be found at: [https://644a9b17d0299b00b581b33f--find-user-
description: Introducing Nx Ecosystem CI, a Vite-inspired automated testing framework for Nx ecosystem compatibility, pre-release testing, migration checks, and test suite management.
---
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.
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.
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.
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.
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`)
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)
@@ -49,7 +50,7 @@ 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:
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`:
@@ -66,11 +67,11 @@ export async function test(options: RunOptions) {
}
```
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.
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.
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:
Here's an example of how scripts might be configured in a package.json file for a repository using Nx:
```
"scripts": {
@@ -84,7 +85,7 @@ Here’s an example of how scripts might be configured in a package.json file fo
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`.
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) {
@@ -103,14 +104,14 @@ With this setup, the Nx Ecosystem CI will run these scripts in your repository a
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:
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.
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`:
Here's what the strategy section might look like after adding a new suite named `my-new-suite`:
```
strategy:
@@ -123,11 +124,11 @@ strategy:
- 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.
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`:
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:
@@ -172,7 +173,7 @@ We are not alone in recognizing the value of an Ecosystem CI approach. Other OSS
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.
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.
description: Nx Console's Generate UI rebuilt with Lit for a faster, more maintainable experience across VSCode and JetBrains IDEs.
---
Over the last few weeks, we rebuilt one of Nx Console's most liked features from the ground up: The Generate UI. It looks better, loads faster, and preliminary research shows using it makes you happier, too ;)
You can use it today by installing the latest version of Nx Console for VSCode and JetBrains IDEs! 🎉🎉🎉
- [Nx Console on the VSCode Marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
- [Nx Console on the JetBrains Marketplace](https://plugins.jetbrains.com/plugin/21060-nx-console)
If you're curious to learn more about the rewrite and the motivations behind it, this is the blog post for you! We'll touch on these topics and more:
- Why did we choose to rewrite?
- What's Lit and why did we use it over Angular?
- How did the rewrite go and what Lit features were important for us?
- What does the performance look like before and after?
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 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.
### Rewriting in Lit
This evolution brought significant improvements to the usability of Nx Console and the value we could provide to developers, but not without presenting its own set of challenges. Inevitably, the codebase grew complex and convoluted over time — the context in which it ran changed, the scope of the product changed, yet the technology remained the same. Adding small features or fixing bugs became increasingly time consuming, and every PR compounded the problem.
The UI looked somewhat outdated and had been built with only VSCode in mind — which became painfully obvious when support for JetBrains IDEs was added. While the web-based nature of the Generate UI allowed us to reuse the code in the new environment, the design looked out of place.
In addition, we started questioning our usage of Angular. Angular is a great framework for building web apps, and in the original context of Angular Console, it made a lot of sense: A tool built by and for Angular engineers — of course it's written in Angular. But things changed, and Angular started to feel overkill for what we needed. Angular has a huge number of features right out of the box. But for our simple form, we didn't need routing, http requests or modules to organize our code. The amount of boilerplate and overhead Angular introduces is significant.
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](/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.
Before I dive deeper into specifics, let's have a look at the general architecture of Nx Console first.
## Nx Console Architectural Overview
Nx Console is composed of 3 core parts:
- The **nxls** is a language server based on the [Language Server Protocol (LSP)](https://microsoft.github.io/language-server-protocol/) and acts as the "brain" of Nx Console. It analyzes your Nx workspace and provides information on it, including code completion and more.
- The **Generate UI** is the form-based view for running Nx generators.
- The **platform-specific wrappers**. These are written in Typescript and Kotlin and connect the rest of Nx Console to IDE-specific APIs. Having the other parts separate greatly reduces the amount of duplicated code we have to write in order to support multiple IDEs
This architecture's modularity meant we could quickly switch out the Generate UI for a new version without significantly impacting the rest of the codebase — only the parts that actually render the UI and communicate with it had to be adjusted slightly. It also allowed us to ensure backward compatibility: the old generate UI is still available via a feature toggle in the settings.
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](/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)
## Migrating to Lit: Step by Step
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 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.
I also installed a couple of dependencies:
- The `@nx/esbuild` plugin because I like fast build times 🏎️
- TailwindCSS because I don't like writing CSS 🤫
-`@vscode/webview-ui-toolkit` because it does all of the VSCode work for me 🤖
This is really where Nx shines, because it allows you to take these tools and quickly patch them together and build a pipeline that does exactly what you need. And it also allows you to think about your workspace visually. This is what this is what my task graph for building the Lit app ultimately looks like:
You can see three build steps:
-`generate-ui-v2:_build` uses esbuild to bundle my Lit components written in Typescript and spits out a `main.js` file
-`generate-ui-v2:extract-dependencies` copies the third party assets we need into the dist folder. Right now it's just codicons `.css` and `.ttf` files.
-`generate-ui-v2:build` finally runs tailwind over the bundled code. This could also be done with `postCss` or a custom `esbuild` plugin but running tailwind directly is the easier, so why complicate things?
> 💡 There are different ways to generate this visualisation for your own workspaces:
>
> - In VSCode, use the Nx Project View or the `Nx: Focus task in Graph` action
> - In JetBrains IDEs, use the Nx Toolwindow or context menus
> - In the command line, run `nx build {{your project}} --graph`
In the bigger context of Nx Console, here's what happens when you build the VSCode extension:
You can see that we're still building both the new & old generate UI as well as the Nxls and the Nx Cloud webview before combining them all into one VSCode extension artifact.
### Building the Form
Lit is a very small library that provides useful abstractions over browser-native features like web components and messages. Here's what a simple Lit component, written with Typescript, looks like:
```ts {% fileName="main.ts" %}
@customElement('root-element')
export class Root extends LitElement {
render() {
return html`<p>Hello World</p>`;
}
}
```
```html {% fileName="index.html" %}
<!DOCTYPE html>
<html lang="en">
<body>
<script type="module" src="main.js"></script>
<root-element></root-element>
</body>
</html>
```
If you need to pass information up the DOM, you use normal events and you can set properties to send information to descendants. Check out the [Lit Docs](https://lit.dev/docs/components/rendering/) to learn more about how the render() method works, how to leverage reactivity, the shadow DOM and so much more.
> 💡 All code samples in this section have been adapted for brevity and clarity. So you won't find this exact code anywhere, but it demonstrates the concepts well.
### 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](/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:
You can see that `root-element` can really just deal with rendering the form contents, delegating communicating with the IDE and when to update the DOM to the controller.
### Rendering the form fields — using Mixins
The core part of the UI is the form. We built all kinds of inputs: text fields, checkboxes, (multi-) select boxes and array fields. While those each have unique implementations, displaying them is also going to take a lot of repeated code. Every fields needs a label and description. Every field needs to know about its validation state, how dispatch change events and what aria attributes to set. In order to keep this code clean and DRY, we used [Class Mixins](https://lit.dev/docs/composition/mixins/). Mixins aren't really a Lit-specific feature, but I don't see them used much in other frameworks. A mixin is essentially a factory that takes a class and returns another, modified class. Check out this example:
```ts {% fileName="field-mixin.ts" %}
const Field = (superClass) =>
class extends superClass {
// we can define (reactive) properties that every field is going to need
@property()
option: Option;
protected get fieldId(): string {
return `${this.option.name}-field`;
}
// we can define methods that should be available to all fields
dispatchValue(value: string) {
// ...
}
};
```
```ts {% fileName="field-wrapper-mixin.ts" %}
const FieldWrapper = (superClass) =>
class extends superClass {
// we can define a render() method so that fields are all rendered the same
You can see that each component and mixin deals with a specific subset of the overall logic, keeping our code cleanly separated and reusable. A checkbox, for example, is a special case because it's layout on the page is slightly different — no problem, we simply wrote a CheckboxWrapper with some modifications without having to worry about changing the checkbox logic itself.
> 💡 Properly typing mixins is complicated so I left that part out. Refer to [Mixins in Typescript](https://lit.dev/docs/composition/mixins/#mixins-in-typescript) to learn more or [check out our source code on GitHub](https://github.com/nrwl/nx-console).
### Injecting Services & Data — Lit Context
If you're coming from the Angular world, you probably appreciate the great dependency injection (DI) mechanism they have. You can centrally define some services and reuse them across your app, without thinking about passing on props from component to component — the DI system takes care of it. Lit provides something similar via the []`@lit-labs/context`](https://lit.dev/docs/data/context/) package. It's based on the [Context Community Protocol](https://github.com/webcomponents-cg/community-protocols/blob/main/proposals/context.md) and similar to React's context API.
Under the hood, it still works with normal browser events, but it abstracts it away from you so you can easily share data and services across your app.
The Generate UI is rendered in both VSCode and JetBrains IDEs. In order to look appropriate, components need to know which environment they're in and adjust styling accordingly. Instead of passing this information from component to component, we can make it available contextually! And with a proper mixin, reading the editor context only has to be implemented once, too.
// provide the context to all DOM children of the host element
new ContextProvider(host, {
context: editorContext,
initialValue: editor,
});
}
}
```
```ts {% fileName="some-component.ts" %}
@customElement('some-component')
export class SomeComponent extends EditorContext(LitElement) {
render() {
return html`<p>I am rendered in ${this.editor}</p>`;
}
}
```
### VSCode Webview UI Toolkit
As we mentioned above, a big part of why we rewrote the UI is that it looked quite out of place in JetBrains IDEs. It was still useful, of course, but it's important to make sure the form _feels_ right.
In VSCode, this is very easy to achieve, thanks to the [VSCode Webview UI Toolkit](https://github.com/microsoft/vscode-webview-ui-toolkit). It's a set of web components, provided by Microsoft, that are designed to look good and be used in VSCode webviews.
Using it, you get the native look, a11y, and theme-aware styling for free! Thanks to everyone who built it, it's a huge help!
### E2E Testing with Cypress
One big upside of using a webview is the huge Javascript ecosystem is available to you! To make sure that no regressions are introduced later on, we use [Cypress](https://www.cypress.io/). We can mock the editor communication and provide different schemas, make sure the form is rendered correctly and the right messages are sent back to the IDE.
While there's no particular Lit integration for Cypress, the tool itself is framework agnostic so it still works perfectly fine. Using the [`@nx/cypress`](/nx-api/cypress) executors did most of the work for us so setup was pretty quick too.
### Results: Comparing Performance
There's a number of different aspects to performance we can compare between the two implementations. The biggest one by far is not really quantifiable: The maintainability and looks of the new UI. In my opinion, it looks a lot fresher and more native in both environments. We got rid of a lot of legacy code and the new version is easier to reason about and work with.
But there are thing we _can_ measure, so let's talk numbers!
### Startup Time
It takes time to bootstrap a large framework like Angular, so skipping that, the UI should load quicker than before.
We measured the median time it took to render all options of the `@nx/angular:application` generator in both VSCode and IntelliJ. You can see that the results are pretty clear-cut, even though they are not hugely impactful.
As mentioned earlier, Angular comes with a lot more features out-of-the-box than Lit, so it would make sense that the built bundle will be bigger.
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 [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
While it might not be important to users of Nx Console, the time it takes to build the project makes a difference to us developers.
Since Lit is just javascript files that don't require a custom compiler or build tooling, we decided to use [`esbuild`](https://esbuild.github.io/) (via `@nx/esbuild`), which is written in Go and extremely fast. On the other hand, the old UI used the `@angular-builders/custom-webpack:browser` builder, which uses webpack under the hood.
We went from about 3.5 seconds to less than 2 seconds of build time, which is less of an improvement than we expected. Since we also have to run tailwind over our files, some of that additional `esbuild` speed seems to be relativized.
## Looking Ahead
Rebuilding the UI has paved the road to reduce a lot of the maintenance burden of Nx Console. It will allow us to move even quicker on building new features to provide the best developer experience possible for you.
Specifically, the updated architecture enabled us to build a (still secret and WIP) plugin feature for Nx Console. Just like Nx, there are always going to be things that are unique to your workspace. We want to make it easy for you to extend and modify Nx Console in ways that help you make the most of using it.
So keep your eyes peeled for announcements and let us know via GitHub or Twitter if you have any ideas! We'd love to chat.
## One more thing!
Nx Console is a tool by developers for developers and there's one thing we love — keyboard shortcuts. So of course we had to build some in. In addition to being keyboard-friendly and tabbable, you can do the following:
- `Cmd/Ctrl + Enter` to run the generator
- `Cmd/Ctrl + Shift + Enter` to start a dry run
- `Cmd/Ctrl + Shift + S` to focus the search bar and look for a specific option. Just `tab` to get back to the form
If the prettier UI and better performance haven't convinced you, this surely will! 😉
Over the last few weeks, we rebuilt one of Nx Console’s most liked features from the ground up: The Generate UI. It looks better, loads faster, and preliminary research shows using it makes you happier, too ;)
description: Nx 16.5 released with tag-based task targeting, NextJS 13 support, new recipes, Angular 16 compatibility, Verdaccio integration, custom CLI, external dependencies input, ESLint rule, and Rust integration for performance.
---
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!
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:
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.
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.
@@ -24,15 +25,15 @@ With this new feature, you can add the `--tag` option to the [`nx affected`](/nx
## 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.
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`
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 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!
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" /%}
@@ -42,7 +43,7 @@ We’ve added a couple videos specifically on Next development in an Nx workspac
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?
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!
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
@@ -59,7 +60,7 @@ Angular is continuing their pattern of releasing new and exciting features — a
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).
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" /%}
@@ -81,9 +82,9 @@ These tools should help in particular with local testing of publishing packages
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.
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:
However, many authors would rather want to have a more "branded" experience. Like being able to invoke the previous example as follows:
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.
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.
@@ -126,19 +127,19 @@ For example, if you have a `publish-package` target that is using a `command` of
}
```
This way you are free to change other dependencies that don’t affect this task without invalidating your cached run of the task.
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.
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.
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:
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
{
@@ -160,7 +161,7 @@ After migrating your Nx workspace, you should have access to this lint rule. To
}
```
Then in “webapp” project’s `.eslintrc.json` file you'll want to turn the rule on for your json files:
Then in "webapp" project's `.eslintrc.json` file you'll want to turn the rule on for your json files:
```json
{
@@ -188,7 +189,7 @@ Our biggest speed increase has come from moving our task hashing into the Nx Dae
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!
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!!
@@ -209,7 +210,7 @@ As part of the redesign, we also moved our webviews to the Lit framework — che
## Nx Changelog Launched
Last but CERTAINLY not least, we’ve launched [a new changelog](/changelog) to our docs site!
Last but CERTAINLY not least, we've launched [a new changelog](/changelog) to our docs site!
@@ -217,7 +218,7 @@ This changelog includes links to all the release notes for all major and minor v
## 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!
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!
description: Nx's evergreen tooling approach automates migrations, updates code like a database, and uses plugins for seamless JavaScript ecosystem upgrades with backward compatibility and reduced maintenance.
---
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:
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:
description: Nx 16.6 introduces Storybook interaction tests, offering automated UI testing, Jest and Playwright integration, and a streamlined workflow.
---
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.
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**
**Prefer a video walkthrough? We've got you covered**
@@ -16,11 +17,11 @@ In Nx 16.6 we are introducing our new generators for [Storybook interaction test
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.
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.
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
@@ -28,9 +29,9 @@ You can read our detailed guide on how to set up Storybook interaction tests on
## 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.
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.
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.
@@ -41,11 +42,11 @@ Storybook provides an interactive debugger that displays the step-by-step flow o
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.
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.
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?
@@ -53,7 +54,7 @@ Setting up interaction tests with Nx and Storybook provides an extra layer of co
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.
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.
description: Build a custom create-react-app CLI with Nx plugins, including workspace setup, Verdaccio testing, and project template customization for a branded React app scaffolding experience.
---
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:
@@ -15,11 +16,11 @@ Most technologies have a CLI to create a new workspace. In fact, it is so preval
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` .
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.
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)
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)
**Prefer a video? We got you covered!**
@@ -53,11 +54,11 @@ _Project graph of the workspace_
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.
- **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.
Let's focus on the `create-my-own-react-app` project which is our CLI.
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.
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.
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.
- 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
- 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 `projectRoot` will be ‘.’, the root of a workspace
- The `projectType` changes to `application`
- 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` .
@@ -397,16 +398,16 @@ The CLI now creates a workspace with the dependencies we want and the code for t
## Step 5: Add a Serve Target
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.
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.
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:
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:
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.
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`
## 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.
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.
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.
@@ -546,7 +547,7 @@ async function main() {
main();
```
You can assemble options for `createWorkspace`; however, you’d like and they will be passed to the `my-own-react` preset.
You can assemble options for `createWorkspace`; however, you'd like and they will be passed to the `my-own-react` preset.
3\. Change `src/generators/preset` to accept this option and apply it.
@@ -588,7 +589,7 @@ You can modify this e2e test to test your CLI. Then, run it using the command `n
The default test works like this:
1. Creates a test workspace at `tmp/`using the `create-my-own-react-app` CLI
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
@@ -628,14 +629,14 @@ Recap:
- 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:
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
- 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)
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-monorepo-tutorial](/getting-started/tutorials/react-monorepo-tutorial)
description: Learn how to integrate Qwik with Nx for a todo app, covering setup, routes, libraries, Qwik Context, and modular development best practices.
---
In the ever-evolving web development landscape, efficiency and modularity have become paramount. This is where [Nx]() and [Qwik](https://qwik.dev/) come into play.
@@ -12,7 +13,7 @@ Qwik is a modern web framework that focuses on application performance by reduci
Nx is a powerful tool that helps you build extensible and maintainable codebases that scale as your application and team grows. Nx utilises computation cache and workspace analysis to ensure maximum efficiency and developer experience. You can [learn more about Nx here](/getting-started/why-nx).
In this blog post, we’ll explore how to combine the strengths of Nx and Qwik to create a todo app. To do this, we’ll take advantage of an Nx Plugin that was created by the Qwikifiers team to maximise the integration between Qwik and Nx, called [`qwik-nx`](https://github.com/qwikifiers/qwik-nx).
In this blog post, we'll explore how to combine the strengths of Nx and Qwik to create a todo app. To do this, we'll take advantage of an Nx Plugin that was created by the Qwikifiers team to maximise the integration between Qwik and Nx, called [`qwik-nx`](https://github.com/qwikifiers/qwik-nx).
> You do not necessarily need to use an Nx Plugin for Qwik. Instead, you could use the [Qwik CLI](https://qwik.dev/docs/getting-started/#create-an-app-using-the-cli) to create your application and [add Nx later](/recipes/adopting-nx/adding-to-existing-project#install-nx-on-a-nonmonorepo-project).
> In this blog post we use the `qwik-nx` plugin to leverage better DX provided by the generators offered by the Plugin.
@@ -39,7 +40,7 @@ You can learn more about this integration in the video below:
## Creating the Workspace
Let’s start by setting up our development environment. We’ll create an Nx workspace and integrate Qwik into it. Begin by generating an empty integrated workspace:
Let's start by setting up our development environment. We'll create an Nx workspace and integrate Qwik into it. Begin by generating an empty integrated workspace:
```shell
npx create-nx-workspace@latest qwik-todo-app
@@ -63,7 +64,7 @@ npm install --save-dev qwik-nx
One of the benefits of using an Nx Plugin is that it comes with additional features such as automatic migrations, executors to act on your code and generators to scaffold code (_like CodeMods_).
Now, let’s use the application generator provided by `qwik-nx` to scaffold the todo application:
Now, let's use the application generator provided by `qwik-nx` to scaffold the todo application:
```shell
nx g qwik-nx:app todo
@@ -77,13 +78,13 @@ At this point, you can already run the `nx serve todo` and `nx build todo` comma
Qwik has another package called Qwik City that uses directory-based routing to handle navigation within your application. [Learn more about directory-based routing with Qwik City](https://qwik.dev/docs/qwikcity/).
The `qwik-nx` plugin can help generate new routes within our application. Let’s use it to generate a route where we can store our todo logic.
The `qwik-nx` plugin can help generate new routes within our application. Let's use it to generate a route where we can store our todo logic.
```shell
nx g qwik-nx:route --name=todo --project=todo
```
After running this command, you’ll see a new directory and file created in your workspace:
After running this command, you'll see a new directory and file created in your workspace:
As you can see, it’s very simple, just a standard Qwik Component.
As you can see, it's very simple, just a standard Qwik Component.
If you run `nx serve todo` and navigate to `http://localhost:4200/todo` you can see that the route works and the component renders the content correctly.
@@ -105,7 +106,7 @@ If you run `nx serve todo` and navigate to `http://localhost:4200/todo` you can
## Build a Basic UI
We want to build a todo application, so let’s add some UI elements to make this look more like an actual todo application.
We want to build a todo application, so let's add some UI elements to make this look more like an actual todo application.
Update `apps/todo/src/routes/todo/index.tsx` to match the following:
You’ll see the page update and look like the following:
You'll see the page update and look like the following:
Awesome!
However, you’ll notice that when you click `Add`, nothing happens! Let’s add some logic to store new todos.
However, you'll notice that when you click `Add`, nothing happens! Let's add some logic to store new todos.
## Generate a Library
Nx helps you organise your workspace in a modular fashion by creating workspace libraries that focus on specific functionality.
Instead of organising your features into subfolders of your application, with Nx, you’ll extract them into workspace libraries (libraries that are not intended to be published, but still used by other libraries and applications in your repository). This helps to create a much stronger boundary between modules and features in your application as libraries have a public API (the `index.ts` file), allowing you to control exactly what can be accessed by consumers.
Instead of organising your features into subfolders of your application, with Nx, you'll extract them into workspace libraries (libraries that are not intended to be published, but still used by other libraries and applications in your repository). This helps to create a much stronger boundary between modules and features in your application as libraries have a public API (the `index.ts` file), allowing you to control exactly what can be accessed by consumers.
> [Learn more about defining and ensuring project boundaries in the Nx docs.](/features/enforce-module-boundaries)
>
@@ -154,7 +155,7 @@ Instead of organising your features into subfolders of your application, with Nx
Using this feature of Nx, we can organise the state management of our todo application into its own library, separating the logic from the application itself.
Let’s generate a new library with the help of `qwik-nx`.
Let's generate a new library with the help of `qwik-nx`.
Qwik uses [Contexts](https://qwik.dev/docs/components/context/) to help store state across both the server-side and client-side and across routes within the application.
We’ll use a Context to store the todos in the application, but first, let’s create a file to store the TS Interfaces we’ll use in our application.
We'll use a Context to store the todos in the application, but first, let's create a file to store the TS Interfaces we'll use in our application.
Create `libs/data-access/src/lib/api.ts` and add the following:
@@ -185,7 +186,7 @@ export interface Todo {
}
```
Next, let’s create a new file `libs/data-access/src/lib/todo.context.tsx` and add the following content:
Next, let's create a new file `libs/data-access/src/lib/todo.context.tsx` and add the following content:
@@ -217,11 +218,11 @@ This will create our Context and set up a Store within our application to store
> [Learn more about how Qwik uses Signals.](https://qwik.dev/docs/components/state/)
Finally, let’s update the public entry point to the library to expose our Context and Interface.
Finally, let's update the public entry point to the library to expose our Context and Interface.
## Using the Context
Let’s update the root page to add our Context Provider. Open `apps/todo/src/root.tsx` and add `TodoContextProvider` after `QwikCityProvider` in the component tree. Your file should look like the following:
Let's update the root page to add our Context Provider. Open `apps/todo/src/root.tsx` and add `TodoContextProvider` after `QwikCityProvider` in the component tree. Your file should look like the following:
```tsx {% fileName="apps/todo/src/root.tsx" %}
import { component$, useStyles$ } from '@builder.io/qwik';
@@ -267,7 +268,7 @@ export * from './lib/todo.context';
export * from './lib/api';
```
Now that our Context is in place, let’s use it in our todo route to manage our todos.
Now that our Context is in place, let's use it in our todo route to manage our todos.
Update `apps/todo/src/routes/todo/index.tsx` to match the following:
Our store has no todos in it when the application starts up, so if you serve the application you will no longer see any todos listed. Let’s fix that!
Our store has no todos in it when the application starts up, so if you serve the application you will no longer see any todos listed. Let's fix that!
## Adding a `routeLoader$` to load data on Navigation
@@ -306,11 +307,11 @@ Qwik allows you to fetch data when a route is navigated to, allowing you to fetc
> [Learn more about routeLoader$.](https://qwik.dev/docs/route-loader/)
It does this by providing a function called `routeLoader$`. We’ll use this function to preload our store with some todos that will theoretically exist in a database.
It does this by providing a function called `routeLoader$`. We'll use this function to preload our store with some todos that will theoretically exist in a database.
For this blog post, we’ll create an in-memory db to store some initial todos.
For this blog post, we'll create an in-memory db to store some initial todos.
We’ll start by updating our `libs/data-access/src/lib/api.ts` to add our in-memory DB.
We'll start by updating our `libs/data-access/src/lib/api.ts` to add our in-memory DB.
However, you might have noticed that our file is starting to get very long. Not only that there’s a lot of logic in the route file itself. Let’s use Nx to separate the logic into the library we created earlier to keep logic collocated.
However, you might have noticed that our file is starting to get very long. Not only that there's a lot of logic in the route file itself. Let's use Nx to separate the logic into the library we created earlier to keep logic collocated.
## Improve the Architecture
@@ -527,7 +528,7 @@ export * from './lib/api';
export * from './lib/todo';
```
Finally, let’s update `apps/todo/src/routes/todo/index.tsx` to use our newly created functions:
Finally, let's update `apps/todo/src/routes/todo/index.tsx` to use our newly created functions:
If you run `nx serve todo` again, you’ll notice that our refactor will not have changed anything for the user, but it has made the codebase more manageable!
If you run `nx serve todo` again, you'll notice that our refactor will not have changed anything for the user, but it has made the codebase more manageable!
Now, if we need to update the logic for loading or adding todos, we only need to retest the library, and not the full application, improving our CI times!
@@ -588,7 +589,7 @@ Now, if we need to update the logic for loading or adding todos, we only need to
## Conclusion
The collaboration between Nx and Qwik has led us to create a todo app that showcases efficient development practices and modular design. By centralizing route logic in a library, we’ve not only demonstrated the capabilities of Nx and Qwik but also highlighted how this approach can significantly improve cache and CI times.
The collaboration between Nx and Qwik has led us to create a todo app that showcases efficient development practices and modular design. By centralizing route logic in a library, we've not only demonstrated the capabilities of Nx and Qwik but also highlighted how this approach can significantly improve cache and CI times.
This journey through Qwik and Nx demonstrates how thoughtful architecture and the right tools can significantly enhance your development experience. So go ahead, Qwikify your development and build amazing web applications with ease!
description: A comprehensive tutorial on building a multi-app Expo monorepo using Nx, featuring shared UI components, navigation setup, and deployment configurations, demonstrated through the creation of two mobile apps.
---
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`:
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
@@ -344,7 +345,7 @@ It will then ask you to choose which binary to submit from one of the following
- Path to an .apk or .aab or .ipa archive on your local filesystem.
- URL to the app archive.
Alternatively, you can submit your app on the [expo.dev](https://expo.dev/) site. Go to your build, under options, choose “Submit to an app store”:
Alternatively, you can submit your app on the [expo.dev](https://expo.dev/) site. Go to your build, under options, choose "Submit to an app store":
description: Nx 16.8 released with new project generator behavior, enhanced TypeScript library packaging, high-performance TypeScript compilation, Playwright support, Netlify integration, and interactive Nx Console features.
---
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!
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!
@@ -29,7 +30,7 @@ Nx is also coming up on 20k Github stars [please help us get there!](https://git
@@ -49,13 +50,13 @@ Over the years, we found this to be much too rigid, so we made these locations m
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`.
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`.
@@ -78,7 +79,7 @@ To get the legacy behavior, be sure to change the `projectNameAndRootFormat` to
{% youtube src="https://youtu.be/Vy4d0-SF5cY" /%}
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.
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.
@@ -93,7 +94,7 @@ The `package.json` format supports an [export field](https://nodejs.org/api/pack
}
```
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:
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:
```
// packages/my-awesome-lib/project.json
@@ -191,7 +192,7 @@ Speed is in our DNA! And TypeScript compilation can be slow which is mostly due
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`:
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
@@ -211,7 +212,7 @@ A new Nx plugin has appeared!!
Nx now supports Playwright as an e2e option alongside our long-standing support for Cypress!
First off, this means we’ve added Playwright as an option when generating new frontend applications:
First off, this means we've added Playwright as an option when generating new frontend applications:
@@ -221,7 +222,7 @@ If you want to add playwright to an existing project in your workspace you can a
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`):
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
@@ -229,19 +230,19 @@ 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
## 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.
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.
[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.
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).
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
@@ -257,7 +258,7 @@ As of our latest release, Nx Console has added the new feature of adding buttons
@@ -277,9 +278,9 @@ Nx has always provided similar functionality via our Storybook + Cypress integra
## 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.
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.
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!
@@ -295,43 +296,43 @@ When all is said and done, you should be able to now add additional applications
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:
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!
Go [check it out now](/plugin-registry) live in 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 🐐
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.
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).
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).
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/).
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:
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
@@ -341,7 +342,7 @@ Flat config is still experimental, so you can use this as a way of easily previe
## 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!
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" /%}
@@ -349,13 +350,13 @@ Be sure to checkout the [Nx Cloud landing site](/nx-cloud) for more details on a
## 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!
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!
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!
description: 'Discover how to integrate Playwright, a powerful end-to-end testing tool, into your Nx workspaces with our new @nx/playwright plugin.'
---
We are very excited to announce our support for Playwright with our new plugin `@nx/playwright`.
@@ -18,9 +19,9 @@ This blog will show you:
## What is Playwright?
Before we start, let’s answer this question: what is Playwright and why should we use it?
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?
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
@@ -52,12 +53,12 @@ export default defineConfig({
### 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:
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:
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();
@@ -77,7 +78,7 @@ _Test error_
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/)
description: Nx raises $16M Series A led by Nexus Venture Partners and a16z, a milestone in revolutionizing monorepo tooling and workflows.
---
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!
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!
description: 'Nx Conf 2023 recap - keynotes, tech talks, and community discussions on Nx ecosystem growth, tooling, and monorepo development.'
---
The 3rd edition of [Nx Conf](/conf), this year live from New York City. If you missed the talks, no worries, we’ve got you covered. This article does a brief recap of all the presentations and has links to the individual recordings and slides.
The 3rd edition of [Nx Conf](/conf), this year live from New York City. If you missed the talks, no worries, we've got you covered. This article does a brief recap of all the presentations and has links to the individual recordings and slides.
@@ -20,7 +21,7 @@ Juri Strumpflohner (me 😅) opens the keynote. He focuses on the Nx ecosystem,
Such integration capabilities really help push the developer productivity, whether that’s in single-project workspaces or monorepos.
Such integration capabilities really help push the developer productivity, whether that's in single-project workspaces or monorepos.
Juri also dives deeper into efforts from the team to provide high quality educational content around Nx and its capabilities. The [Nx docs](/getting-started/intro) have been restructured to follow the [Diataxis](https://diataxis.fr/) framework, dividing content into into learning-, task-, understanding- and information-oriented sections.
@@ -29,11 +30,11 @@ This makes it easier to find keep the content organized and focused and makes it
The Nx team not only produces written content, but also video content mainly on the [Nx YouTube Channel](https://www.youtube.com/@nxdevtools). Juri shows some of the growth stats, with the channel now having more than 14k subscribers and around 3.7k hours of watch time per month. The channel serves mostly short-form videos about new releases, highlighting new features as well as longer-form tutorial videos.
The Nx Community also got a special place in the keynote. Juri highlighted in particular the transition from the “Nrwl Community Slack” to the new “Nx Community” on Discord.
The Nx Community also got a special place in the keynote. Juri highlighted in particular the transition from the "Nrwl Community Slack" to the new "Nx Community" on Discord.
Discord is built for managing communities and will open up a series of features to come. Things like a built-in forum to ask questions, the ability to highlight Nx events (e.g. the Nx live stream) and having powerful automation and moderation tools. Since the launch a couple of weeks ago, already 1500+ members have signed up. If you didn’t sign up yet, go to [https://go.nx.dev/community](https://go.nx.dev/community).
Discord is built for managing communities and will open up a series of features to come. Things like a built-in forum to ask questions, the ability to highlight Nx events (e.g. the Nx live stream) and having powerful automation and moderation tools. Since the launch a couple of weeks ago, already 1500+ members have signed up. If you didn't sign up yet, go to [https://go.nx.dev/community](https://go.nx.dev/community).
Juri also highlighted the [Nx Champions](/community) program that got launched this year which helps with efforts to grow the Nx community. The program features members that stood out in the Nx community by helping support others, producing content or speaking at conferences about Nx and related tech.
Finally there were also two **announcements**:
@@ -41,15 +42,15 @@ Finally there were also two **announcements**:
- the Nx team decided to move off Medium for a better publishing experience but mainly also to avoid the paywall, something that the team has no control over. The new blog is currently being built and will be hosted at [blog](/blog). This also allows to better resurface information by being able to integrate blog articles into the Nx docs search and make them also accessible to the Nx AI Assistant which was the 2nd announcement.
- the **Nx AI Assistant** is an experiment the team is running to use AI to improve discoverability on the Nx docs. The ChatGPT powered assistant allows to ask natural language questions and responds based on the Nx docs training data, also including links to the sources. Try it out at [ai-chat](/ai-chat) and use the feedback thumbs-up/down buttons to help improve it over time 🙏.
Also, Nx is open source: [https://github.com/nrwl/nx](https://github.com/nrwl/nx). Contribute! And while you’re there, don’t forget to give us a star 😃.
Also, Nx is open source: [https://github.com/nrwl/nx](https://github.com/nrwl/nx). Contribute! And while you're there, don't forget to give us a star 😃.
**Victor Savkin** began the second segment of the keynote discussing the hidden expenses that often plague large teams.
He emphasized that as an organization grows, so does the supporting work. This isn’t limited to just communication and management. Every artifact, be it code, process, or otherwise, needs to be assimilated into the broader context. This supporting work becomes intricate and demanding. He pointed out that the remote work trend, while it started with a lot of momentum, struggles in larger corporations because it demands even more coordination and effort. In contrast, smaller entities often outshine their larger counterparts due to the reduced overhead of supporting work.
He emphasized that as an organization grows, so does the supporting work. This isn't limited to just communication and management. Every artifact, be it code, process, or otherwise, needs to be assimilated into the broader context. This supporting work becomes intricate and demanding. He pointed out that the remote work trend, while it started with a lot of momentum, struggles in larger corporations because it demands even more coordination and effort. In contrast, smaller entities often outshine their larger counterparts due to the reduced overhead of supporting work.
One of Victor’s main points was the potential of software developers. Given the right tools and environment, they can achieve remarkable feats. CI is one such tool.
One of Victor's main points was the potential of software developers. Given the right tools and environment, they can achieve remarkable feats. CI is one such tool.
@@ -59,7 +60,7 @@ However, scaling CI is a challenge. In larger workspace, up to 50 agents is pret
This might be manageable in a static repository setup, but monorepos introduce an added layer of complexity. Here, static “CI recipes” just won’t cut it. The result is either an overuse of computational resources, leading to waste of money, or a painfully slow CI.
This might be manageable in a static repository setup, but monorepos introduce an added layer of complexity. Here, static "CI recipes" just won't cut it. The result is either an overuse of computational resources, leading to waste of money, or a painfully slow CI.
Victor critiqued that most current CI setups are:
@@ -103,7 +104,7 @@ This elevated abstraction is possible because Nx Cloud & Nx are intimately famil
Beyond simplifying CI configurations, Nx Cloud Workflows helps optimize computational resource use. Agents are instantiated dynamically based on the project’s requirements.
Beyond simplifying CI configurations, Nx Cloud Workflows helps optimize computational resource use. Agents are instantiated dynamically based on the project's requirements.
@@ -132,17 +133,17 @@ Simon Critchley (Senior Software Architect at Nx) dives into the more technical
Apart from the distributed caching, Nx Cloud already offers [DTE (Distributed Task Execution)](/ci/features/distribute-task-execution), which is a mechanism to seamlessly distribute tasks across various machines to achieve a high degree of parallelism. Up until now it was on you to configure your existing CI in a way to provision machines (agents) to Nx Cloud DTE. This required some fine-tuning to understand the best level of parallelism given the underlying monorepo and tasks that need to be run. If you have too many machines, it’ll be wasteful, if you have to few your CI will be slower.
Apart from the distributed caching, Nx Cloud already offers [DTE (Distributed Task Execution)](/ci/features/distribute-task-execution), which is a mechanism to seamlessly distribute tasks across various machines to achieve a high degree of parallelism. Up until now it was on you to configure your existing CI in a way to provision machines (agents) to Nx Cloud DTE. This required some fine-tuning to understand the best level of parallelism given the underlying monorepo and tasks that need to be run. If you have too many machines, it'll be wasteful, if you have to few your CI will be slower.
Nx Cloud Workflow is an advancement of the DTE mechanism, where machines can be automatically provisioned and scaled based on the tasks that need to be run. Essentially it is a replacement for your existing CI but way smarter because it is able to leverage the knowledge it has about the Nx workspace, historical data and can thus do a series of optimizations. Traditional CI systems are running low-level commands on machines. Nx Cloud Workflows is task oriented instead: you tell it to run builds, tests, e2e, linting on the affected projects of the Nx workspace and it figures out how to split them up into fine-grained tasks and then distributes them among dynamically provisioned agents.
From a developer’s perspective, Nx Cloud Workflows are written in Yaml (or alternatively in JSON which is handy if you need to generate them). The format is very similar to existing CI providers to make sure the knowledge you have easily transfers. If you want an example, we’re dog-fooding Nx Cloud Workflows on the Nx repo (note the config will change as the product progresses): [https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml](https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml)
From a developer's perspective, Nx Cloud Workflows are written in Yaml (or alternatively in JSON which is handy if you need to generate them). The format is very similar to existing CI providers to make sure the knowledge you have easily transfers. If you want an example, we're dog-fooding Nx Cloud Workflows on the Nx repo (note the config will change as the product progresses): [https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml](https://github.com/nrwl/nx/blob/master/.nx/workflows/agents.yaml)
Simon then dives way deeper into the underlying architecture. In particular, how scheduling in Kubernetes works, which is used at the infrastructure level for Nx Cloud Workflows.
Workflow scheduling is handled by Kubernetes, specifically through a “Workflow Controller” that interacts with the K8s API Server and triggers Kubernetes Pods. Each Pod contains a Workflow executor and sidecar containers. All containers in the Nx Cloud workflow share a workspace volume for collaborative access. This allows for interesting optimizations in terms of sharing `node_modules` and restoring cache results.
Workflow scheduling is handled by Kubernetes, specifically through a "Workflow Controller" that interacts with the K8s API Server and triggers Kubernetes Pods. Each Pod contains a Workflow executor and sidecar containers. All containers in the Nx Cloud workflow share a workspace volume for collaborative access. This allows for interesting optimizations in terms of sharing `node_modules` and restoring cache results.
@@ -168,7 +169,7 @@ Michael talks about how to leverage Nx to migrate multiple repositories into a m
- how to do the move in parallel
- how to measure the progress
The project usually starts with an architectural audit. That involves a detailed analysis of the underlying codebase, also including an executive summary for non technical folks. Once the audit is done, the actual move is planned and prepared. A part of that is to define “Nx migration goals”, like
The project usually starts with an architectural audit. That involves a detailed analysis of the underlying codebase, also including an executive summary for non technical folks. Once the audit is done, the actual move is planned and prepared. A part of that is to define "Nx migration goals", like
- Single Version Policy
- Improved Maintenance
@@ -183,7 +184,7 @@ To prioritize which ones to address first, Michael uses the following metaphor:
The important part here is to understand why “apples get bad” in the first place. Is it the harvesting process?
The important part here is to understand why "apples get bad" in the first place. Is it the harvesting process?
Once the priorities are defined and roadmap laid out, the goal is to **move in parallel.**
As part of that move the following gets produced:
@@ -199,7 +200,7 @@ The training program is there to tackle the bottleneck of missing knowledge, rig
Finally the impact measurement; Nx Cloud already has graphs to measure how much time got saved in CI due to the improvements made. Michael mentions they go further, also measuring communication and productivity.
An interesting part is also how they perform the repository synching (from polyrepo to monorepo). They leverage an Nx plugin that
An interesting part is also how they perform the repository syncing (from polyrepo to monorepo). They leverage an Nx plugin that
- contains shared build logic
- has rules to run that produce actionable feedback about what is needed to sync/align the polyrepo repository s.t. it can be merged into the monorepo
Craigory did a deep dive into the new Nx inference API. This is particularly interesting if you’re developing [Nx plugins](/extending-nx/intro/getting-started) or if you have leverage/build some more advanced automation for your Nx workspace.
Craigory did a deep dive into the new Nx inference API. This is particularly interesting if you're developing [Nx plugins](/extending-nx/intro/getting-started) or if you have leverage/build some more advanced automation for your Nx workspace.
What is project inference:
@@ -239,7 +240,7 @@ Project graph API v2
-`createNodes` - finds graph nodes based on files on disk
-`createDependencies` - finds edges to be added to the graph
Still 2 parts, but there’s no overlap between these two and they have very specific purposes.
Still 2 parts, but there's no overlap between these two and they have very specific purposes.
`createNodes` is a tuple composed of:
@@ -285,7 +286,7 @@ Currently, Nx offers support for two predominant monorepo styles: package-based
- These are structured to prioritize consistency and maintainability.
- Updates within this framework are automated, and the setup adheres to a single-version policy.
Isaac then drew parallels between the Apollo program and the package-based mindset. The Apollo missions were evolutionary in nature, constantly pushing the envelope and embracing innovation with each successive mission. However, this trailblazing approach wasn’t without its perils, as evidenced by tragic accidents. This experimental approach was feasible because the core team, responsible for creating the setup, remained consistent throughout the project’s duration.
Isaac then drew parallels between the Apollo program and the package-based mindset. The Apollo missions were evolutionary in nature, constantly pushing the envelope and embracing innovation with each successive mission. However, this trailblazing approach wasn't without its perils, as evidenced by tragic accidents. This experimental approach was feasible because the core team, responsible for creating the setup, remained consistent throughout the project's duration.
In contrast, Isaac likened the International Space Station (ISS) to the integrated mindset. The ISS epitomizes the challenges of coordination, given its international collaboration involving numerous countries. Emphasizing longevity, the ISS necessitates that every new crew member be proficient in operating its intricate machinery.
@@ -298,7 +299,7 @@ Shifting gears, Isaac delved into a hands-on demonstration. He outlined the proc
- Devising a novel Nx generator, streamlining the process of setting up new libraries within the workspace.
- Finally, he showcased the seamless upgrade mechanism, ensuring the workspace is always aligned with the latest version.
@@ -322,7 +323,7 @@ Important to note that all the existing plugins are still valid and will still b
James goes forward demoing how `nx release` works in a simple NPM package: [jump directly into the video](https://www.youtube.com/watch?si=xoIW0Q-mQWTGgrek&t=411&v=p5qW5-2nKqI&feature=youtu.be).
Nx release can be added to any npm package. All that’s needed is the `nx` and `@nx/js` package and a `nx: {}` node in the `package.json`.
Nx release can be added to any npm package. All that's needed is the `nx` and `@nx/js` package and a `nx: {}` node in the `package.json`.
Nx release has a dry-run mode; `nx release version --dry-run`. This will output a diff of what version would be created and on which `package.json` files (if there are multiple).
The same mechanism also works for the `changelog` command, e.g. `nx release changelog --dry-run`. In addition to just dry-run, the `changelog` command also has an `--interactive` mode that allows to get the generated changelog in an interactive editor where you can adjust and add extra stuff.
@@ -335,7 +336,7 @@ A nice feature is also that the changelog will...
- automatically group first by type (e.g. features grouped together, fixes etc)
- within each type grouping it will be grouped by scope such as pkg-a etc which will be alphabetized
- if there’s a fix on the entire repo that’ll come first before the per-package changes
- if there's a fix on the entire repo that'll come first before the per-package changes
`nx release changelog --create-release=github` allows to also automatically push the changelog to a Github release.
@@ -344,7 +345,7 @@ When running `nx release publish`, Nx also takes into account the right order of
Future roadmap:
- ability to customize how the release works by defining it in `nx.json`
-“release groups” will allow to group packages and define whether versions should be in sync or versioned independently; filter by projects, or even just publish a subset of projects of a workspace
-"release groups" will allow to group packages and define whether versions should be in sync or versioned independently; filter by projects, or even just publish a subset of projects of a workspace
- publishing also automatically takes into account the provenance data on NPM
## Lightning Talk: What if your stories were — already — your e2e tests?
description: Nx 17 released with Vue.js support, Module Federation enhancements, generator path improvements, AI chatbot integration, and more.
---
We’re excited to announce the release of Nx version 17!
We're excited to announce the release of Nx version 17!
This article will cover the main things you need to know to get the most out of Nx 17!
Here’s a Table of Contents so you can skip straight to the updates you care about the most:
Here's a Table of Contents so you can skip straight to the updates you care about the most:
- [It's a Vue-tiful Day for Nx](#its-a-vuetiful-day-for-nx)
- [Enhancements to Module Federation Support](#enhancements-to-module-federation-support)
@@ -33,7 +34,7 @@ Here’s a Table of Contents so you can skip straight to the updates you care ab
---
## It’s a Vue-tiful Day for Nx!
## It's a Vue-tiful Day for Nx!
Ever since we added Vite as a first-class citizen to Nx workspaces (see `@nx/vite`), we started falling in love with the Vue community. The only logical next step: Nx now provides a brand new Vue plugin that is being maintained by the Nx team! (And we're already working on a [Nuxt](https://nuxt.com/) plugin 🤫)
@@ -47,13 +48,11 @@ This option will create a new Nx workspace with a fresh Vue application, all set
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:
And you'll have access to Nx generators so that you can generate Vue applications, libraries, components, and more in your workspace:
We’re very excited for this support to land, and we’re eager to get it into our user’s hands and see what Nx can do to help Vue developers so we can continue to refine our support and make Vue with Nx an excellent developer experience.
If you’re eager to learn more, make sure to check out our new [Vue standalone tutorial](/getting-started/tutorials/vue-standalone-tutorial).
We're very excited for this support to land, and we're eager to get it into our user's hands and see what Nx can do to help Vue developers so we can continue to refine our support and make Vue with Nx an excellent developer experience.
## Enhancements to Module Federation Support
@@ -61,7 +60,7 @@ Nx already had great support for Module Federation — Nx 17 improves on this su
### NEW: Typesafe Config
Projects created with Nx’s generators for module federation will now be created with a `module-federation.config.ts` file (as opposed to a `.js` file). A new `ModuleFederationConfig` interface is also exported from the `@nx/webpack` plugin.
Projects created with Nx's generators for module federation will now be created with a `module-federation.config.ts` file (as opposed to a `.js` file). A new `ModuleFederationConfig` interface is also exported from the `@nx/webpack` plugin.
### Better Typesafety Across Modules
@@ -119,13 +118,13 @@ This config will ensure that version `0.0.1` of the `is-odd` is used.
Similar to the [adjustments we made in 16.8](https://www.youtube.com/watch?v=bw8pRh0iC4A&t=14s) for most of our project-creating generators, v17 brings updates to how component generators work. These updates aim to give you more control over the name and file location of your components.
Towards this end, we’ve added a new `--nameAndDirectoryFormat` option that you can set to either `as-provided` or `derived`.
Towards this end, we've added a new `--nameAndDirectoryFormat` option that you can set to either `as-provided` or `derived`.
When set to `as-provided`, the generator will use the `name` option for the name of your component and the `directory` option to determine where on your file system to add the component. `as-provided` will be used by default if none is specified.
When set to `derived`, the generator will try to determine where to create your component based on the `project` option - which will mainly operate how component generators do now.
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:
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 apps/my-app/src/app/Home
@@ -133,7 +132,7 @@ In addition, component generators now follow any given casing for component file
And a `Home.tsx` file will be added in the `apps/my-app/src/app` directory.
Finally, generators will now factory in your current working directory, so you can also create this “Home” component via:
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
@@ -142,7 +141,7 @@ 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 [/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).
@@ -156,9 +155,9 @@ After running the `nx migrate` command to upgrade to Nx 17 and using Nx Cloud, y
Our Nx Cloud updates come alongside configuration changes in your `nx.json` file and project configuration.
Specifically, we’ve added an optional `nxCloudAccessToken` to the `nx.json` file - as long as a token is provided here, we'll make sure that you take advantage of the currently deployed version of Nx Cloud when running commands with Nx.
Specifically, we've added an optional `nxCloudAccessToken` to the `nx.json` file - as long as a token is provided here, we'll make sure that you take advantage of the currently deployed version of Nx Cloud when running commands with Nx.
We’ve also removed the need to specify `cacheableOperations` at the task-runner level. From now on, every `target` configured in your `project.json` can be defined as cacheable using the `cache` property.
We've also removed the need to specify `cacheableOperations` at the task-runner level. From now on, every `target` configured in your `project.json` can be defined as cacheable using the `cache` property.
```json {% fileName="nx.json" %}
{
@@ -173,7 +172,7 @@ We’ve also removed the need to specify `cacheableOperations` at the task-runne
If you use the `nx migrate` command, all updates will be handled for you using the `targetDefaults` in your `nx.json` file. [More in the docs.](/features/cache-task-results)
We’ve been working hard at reducing and simplifying all the configuration required for your Nx workspaces. Checkout our latest guide on how to [Reduce Repetitive Configuration](/recipes/running-tasks/reduce-repetitive-configuration) for more, and stay tuned as we’ve got new efforts underway to make this simplification even more appealing!
We've been working hard at reducing and simplifying all the configuration required for your Nx workspaces. Checkout our latest guide on how to [Reduce Repetitive Configuration](/recipes/running-tasks/reduce-repetitive-configuration) for more, and stay tuned as we've got new efforts underway to make this simplification even more appealing!
## Nx Repo Dog-Fooding Nx Workflows
@@ -183,19 +182,19 @@ If you missed it, Simon Critchley walks you through in his [Nx Conf](/blog/nx-co
Put simply, Nx Workflows represents Nx entering the CI provider arena, where Nx can now provide you with Cloud Computation to run your CI tasks. This creates the foundation for a whole new class of Nx Cloud features that we’re excited to work on in the coming cycles.
Put simply, Nx Workflows represents Nx entering the CI provider arena, where Nx can now provide you with Cloud Computation to run your CI tasks. This creates the foundation for a whole new class of Nx Cloud features that we're excited to work on in the coming cycles.
The Nx repo itself is now “dog-fooding” this latest feature (dog-fooding refers to using our tool in our own projects, or “eating our own dog food”), and you can see how it’s going now on our [public Nx Cloud workspace](https://staging.nx.app/orgs/62d013d4d26f260059f7765e/workspaces/62d013ea0852fe0a2df74438/overview).
The Nx repo itself is now "dog-fooding" this latest feature (dog-fooding refers to using our tool in our own projects, or "eating our own dog food"), and you can see how it's going now on our [public Nx Cloud workspace](https://staging.nx.app/orgs/62d013d4d26f260059f7765e/workspaces/62d013ea0852fe0a2df74438/overview).
Nx Workflows are still in the experimental phase. We’re running pilots with our enterprise clients and are excited to open this up for everyone soon!
Nx Workflows are still in the experimental phase. We're running pilots with our enterprise clients and are excited to open this up for everyone soon!
## Task Graphing Improvements
Task Caching in Nx is based on a set of “input” files calculated for a given task. You can specify specific files or patterns of files in your project.json for a particular task or in the `targetDefaults` of your `nx.json` to set the default file sets for your inputs.
Task Caching in Nx is based on a set of "input" files calculated for a given task. You can specify specific files or patterns of files in your project.json for a particular task or in the `targetDefaults` of your `nx.json` to set the default file sets for your inputs.
There have been some difficulties in determining precisely which files were included and which weren’t for a given task. This is where our latest update to the task graph comes in:
There have been some difficulties in determining precisely which files were included and which weren't for a given task. This is where our latest update to the task graph comes in:
@@ -205,7 +204,7 @@ You can open this graph using the command:
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:
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:
@@ -227,19 +226,19 @@ In Nx 17, we removed any remaining traces of `tslint` from our linter package, s
As we solidify this command, we intend to bring robust support for various versioning and publishing strategies, as well as built-in support for publishing packages or modules to a variety of languages, registries, and platforms.
For more [checkout our API docs](/nx-api/nx/documents/release), and be sure to catch James Henry’s announcement of this new command at [Nx Conf](/blog/nx-conf-2023-recap):
For more [checkout our API docs](/nx-api/nx/documents/release), and be sure to catch James Henry's announcement of this new command at [Nx Conf](/blog/nx-conf-2023-recap):
At Nx, we’re OBSESSED with building a better, more robust experience for our developers. Towards this end, we’re now in [v2 of our Project Inference API](/extending-nx/recipes/project-graph-plugins).
At Nx, we're OBSESSED with building a better, more robust experience for our developers. Towards this end, we're now in [v2 of our Project Inference API](/extending-nx/recipes/project-graph-plugins).
This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](/getting-started/tutorials/vue-standalone-tutorial).
This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](/nx-api/vue).
Interestingly, v2 includes support for dynamic targets as well. This opens up exciting new doors to reducing configuration, and we hope to expand on this to better support our first-party plugins in the near future.
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:
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:
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://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
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://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
description: Implementing state management in Nx React Native/Expo apps with TanStack Query and Redux, covering setup, dev tools, and unit testing.
---
There are currently countless numbers of state management libraries out there. This blog will show you how to use state management for React Native in Nx monorepo with [TanStack Query](https://tanstack.com/query/latest) (which happens to use [Nx on their repo](https://cloud.nx.app/orgs/6412ca9d1c251d000efa21ba/workspaces/6412c827e6da5d7b4a0b1fe3/overview)) and Redux.
@@ -88,7 +89,7 @@ const App = () => {
exportdefaultApp;
```
Note: the [React Query Devtools](https://tanstack.com/query/latest/docs/framework/react/devtools) currently do not support react native, and it only works on the web, so there is a condition: `{ Platform.OS === ‘web’ && <ReactQueryDevtools />}.`
Note: the [React Query Devtools](https://tanstack.com/query/latest/docs/framework/react/devtools) currently do not support react native, and it only works on the web, so there is a condition: `{ Platform.OS === 'web' && <ReactQueryDevtools />}.`
For the react native apps, in order to use this tool, you need to use [react-native-web](https://necolas.github.io/react-native-web/) to interpolate your native app to the web app first.
@@ -102,9 +103,9 @@ Or you can run `npx nx serve cats` to launch the app in a web browser and debug
What is a query?
> “A query is a declarative dependency on an asynchronous source of data that is tied to a unique key. A query can be used with any Promise-based method (including GET and POST methods) to fetch data from a server.” [(https://tanstack.com/query/v4/docs/react/guides/queries)](https://tanstack.com/query/v4/docs/react/guides/queries)
> "A query is a declarative dependency on an asynchronous source of data that is tied to a unique key. A query can be used with any Promise-based method (including GET and POST methods) to fetch data from a server." [(https://tanstack.com/query/v4/docs/react/guides/queries)](https://tanstack.com/query/v4/docs/react/guides/queries)
Now let’s add our first query. In this example, it will be added under `lib/queries` folder. To create a query to fetch a new fact about cats, run the command:
Now let's add our first query. In this example, it will be added under `lib/queries` folder. To create a query to fetch a new fact about cats, run the command:
```shell
# expo workspace
@@ -124,7 +125,7 @@ Now notice under libs folder, `use-cat-fact` folder got created under `libs/quer
If you use React Native CLI, just add a folder in your workspace root.
For this app, let’s use this API: [https://catfact.ninja/](https://catfact.ninja/). At `libs/queries/use-cat-fact/src/lib/use-cat-fact.ts`, add code to fetch the data from this API:
For this app, let's use this API: [https://catfact.ninja/](https://catfact.ninja/). At `libs/queries/use-cat-fact/src/lib/use-cat-fact.ts`, add code to fetch the data from this API:
```ts
import{useQuery}from'@tanstack/react-query';
@@ -187,7 +188,7 @@ fetchMock.enableMocks();
**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 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:
description: Explore the Nx Docs AI Assistant's architecture, user benefits, and how it enhances documentation accessibility through intelligent search and contextual responses.
---
## Introduction
@@ -34,7 +35,7 @@ In a nutshell, the Nx Docs AI Assistant works in the following way:
This is based on the Web Q&A Tutorial from OpenAI [(https://platform.openai.com/docs/tutorials/web-qa-embeddings)](https://platform.openai.com/docs/tutorials/web-qa-embeddings) and Supabase’s Vector Search example [(https://supabase.com/docs/guides/ai/examples/nextjs-vector-search)](https://supabase.com/docs/guides/ai/examples/nextjs-vector-search).
It’s important to note here that we are not “training the model on our docs”. The model is pretrained. We are just giving the model parts of our docs which are relevant to the user’s question, and the model creates a coherent answer to the question. It’s basically like pasting in ChatGPT a docs page and asking it “how do I do that?”. Except in this case, we’re first searching our documentation and giving GPT only the relevant parts (more about how we do that later in this article), which it can “read” and extract information from.
It’s important to note here that we are not “training the model in our docs”. The model is pretrained. We are just giving the model parts of our docs which are relevant to the user’s question, and the model creates a coherent answer to the question. It’s basically like pasting in ChatGPT a docs page and asking it “how do I do that?”. Except in this case, we’re first searching our documentation and giving GPT only the relevant parts (more about how we do that later in this article), which it can “read” and extract information from.
description: Learn how to unit test Expo apps using Jest and React Native Testing Library, with solutions for mocking AsyncStorage, Redux, and React Navigation.
---
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:
When you use Nx, it not only configures and sets up Jest, but also creates a default unit test for every expo component that is being generated. Here’s what that looks like:
When you use Nx, it not only configures and sets up Jest, but also creates a default unit test for every expo component that is being generated. Here's what that looks like:
@@ -95,7 +96,7 @@ I am using the library `@react-native-async-storage/async-storage`, and I got th
The issue is that `@react-native-async-storage/async-storage` library can only be used in `NativeModule`. Since unit testing with Jest only tests JS/TS file logic, I need to mock this library.
In the app’s test-setup.ts file, add the below lines:
In the app's test-setup.ts file, add the below lines:
If you use `@react-navigation` library for navigation, and inside your component, there are hooks from this library like `useNavigation` and `useRoute`, you are likely to get this error:
@@ -215,7 +216,7 @@ If you use `@react-navigation` library for navigation, and inside your component
Couldn't find a navigation object. Is your component inside NavigationContainer?
```
The fix this, I need to mock the `@react-nativgation/native` library. In the app’s test-setup.ts file, I need to add:
The fix this, I need to mock the `@react-nativgation/native` library. In the app's test-setup.ts file, I need to add:
I got this error when using a library with ECMAScript Module (ESM), such as [`udid`](https://github.com/uuidjs/uuid):
@@ -252,7 +253,7 @@ I got this error when using a library with ECMAScript Module (ESM), such as [`ud
Jest does not work with ESM out of the box. The simple solution is to map this library to the CommonJS version of this library.
In the app’s `jest.config.ts`, there should be an option called `moduleNameMapper`. The library I used is called `uuid`, so I need to add the map `uuid: require.resolve(‘uuid’)` under `moduleNameMapper`. So when the code encounters imports from `uuid` library, it will resolve the CommonJS version of it:
In the app's `jest.config.ts`, there should be an option called `moduleNameMapper`. The library I used is called `uuid`, so I need to add the map `uuid: require.resolve('uuid')` under `moduleNameMapper`. So when the code encounters imports from `uuid` library, it will resolve the CommonJS version of it:
```typescript
module.exports={
@@ -292,8 +293,8 @@ I got this error when I was importing from a library such as [react-native-vecto
• 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.
• 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.
• If I need a custom transformation specify a "transform" option in my config.
• If I simply want to mock my non-JS modules (e.g. binary assets) I can stub them out with the "moduleNameMapper" config option.
You'll find more details and examples of these config options in the docs:
https://jestjs.io/docs/configuration
@@ -305,7 +306,7 @@ To fix this, add this library name to `transformIgnorePatterns` in the app's jes
What is `transformIgnorePatterns`? The `transformIgnorePatterns` allows developers to specify which files shall be transformed by Babel. `transformIgnorePatterns` is an array of regexp pattern strings that should be matched against all source file paths before the transformation. If the file path matches any patterns, it will not be transformed by Babel.
By default, Jest will ignore all the files under node_modules and only transform the files under the project’s src.
By default, Jest will ignore all the files under node_modules and only transform the files under the project's src.
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:
@@ -324,7 +325,7 @@ If I have an error related to a library with an unexpected token, I need to chec
Here are some common errors that I will probably run into while doing unit testing. The solution to most problems is to find a way to mock a library that is not relevant to my component logic.
With Nx, you do not need to explicitly install any testing library, so you can dive right in and focus on writing the tests rather than spending time on setup.
With Nx, I do not need to explicitly install any testing library, so I can dive right in and focus on writing the tests rather than spending time on setup.
description: Nx 17.2 released with simplified project configuration, Rust-powered task hashing, enhanced Module Federation, expanded releases, Angular 17 support, and Nx Agents for faster CI.
---
It’s been a bit since we launched [Nx 17](/blog/nx-17-release)! In this article, we’ll go over some of the new developments and improvements that have landed in Nx 17.2:
It's been a bit since we launched [Nx 17](/blog/nx-17-release)! In this article, we'll go over some of the new developments and improvements that have landed in Nx 17.2:
- [Nx Closes In On 4 Million Weekly NPM Downloads!!](#nx-closes-in-on-4-million-weekly-npm-downloads)
- [New Simplified Project Configuration On the Way](#new-simplified-project-configuration-on-the-way)
@@ -27,40 +28,40 @@ And our downloads on NPM keep confirming this. We are about to cross 4 million d
If this made you curious, keep an eye on [our blog](/blog) or [X/Twitter](https://twitter.com/nxdevtools) as we’re going to release a 2023 year recap blog post next week.
If this made you curious, keep an eye on [our blog](/blog) or [X/Twitter](https://twitter.com/nxdevtools) as we're going to release a 2023 year recap blog post next week.
## New Simplified Project Configuration On the Way
Adoption is crucial, and simplicity is the driver for adoption. Last year we heavily optimized how you can use Nx in an existing project. Just drop the `nx` package (or run `nx init`) and that's it. Nx understands your workspace and efficiently runs your `package.json` scripts.
Using Nx at that level is definitely useful as you get intelligent parallelization, task pipelines and caching. But it is just the tip of the iceberg of what Nx is actually capable of. Nx plugins provide much more, especially in terms of DX and developer productivity by taking away some of the burden of configuring your monorepo tooling. But many devs new to Nx found it harder to get started with them initially and incrementally migrating to Nx plugins wasn’t as straightforward as we’d wanted it to be.
Using Nx at that level is definitely useful as you get intelligent parallelization, task pipelines and caching. But it is just the tip of the iceberg of what Nx is actually capable of. Nx plugins provide much more, especially in terms of DX and developer productivity by taking away some of the burden of configuring your monorepo tooling. But many devs new to Nx found it harder to get started with them initially and incrementally migrating to Nx plugins wasn't as straightforward as we'd wanted it to be.
This is something that’s gonna change drastically in 2024. And we’ve layed the first cornerstone for that. But it is behind a feature flag still as we’re streamlining the last bits. The goal?
This is something that's gonna change drastically in 2024. And we've layed the first cornerstone for that. But it is behind a feature flag still as we're streamlining the last bits. The goal?
- Going almost configuration-less (good defaults, you customize when you need to)
- Allowing easy drop-in of Nx plugins into existing workspaces (provides immediate productivity gains, but stays out of your way)
This opens up a series of possibilities which we’re already super excited about. You’ll hear more about this in the new year ;)
This opens up a series of possibilities which we're already super excited about. You'll hear more about this in the new year ;)
## Rust for Speed, Typescript for Extensibility
At Nx, we’ve heavily embraced Typescript from the beginning, and we’ve been very happy with that decision.
At Nx, we've heavily embraced Typescript from the beginning, and we've been very happy with that decision.
If you’ve been paying attention to previous release announcements though, you’ve probably noticed that we’ve been moving more and more of the computationally intensive and performance critical pieces of the core of Nx from Typescript to Rust.
If you've been paying attention to previous release announcements though, you've probably noticed that we've been moving more and more of the computationally intensive and performance critical pieces of the core of Nx from Typescript to Rust.
That trend continues in Nx 17.2 with Nx [using Rust for its task hashing by default](https://github.com/nrwl/nx/pull/19617). There’s no adjustments needed for this change, and Nx will continue to behave the same way, just faster!
That trend continues in Nx 17.2 with Nx [using Rust for its task hashing by default](https://github.com/nrwl/nx/pull/19617). There's no adjustments needed for this change, and Nx will continue to behave the same way, just faster!
Module Federation has been a particularly hot topic lately, and 17.2 is coming in with some great enhancements to Nx’s already best-in-class support for Module Federation!
Module Federation has been a particularly hot topic lately, and 17.2 is coming in with some great enhancements to Nx's already best-in-class support for Module Federation!
To start, we’ve greatly reduced the CPU and memory used for standing up your Module Federation “web” locally. These enhancements should be great news to larger workspaces using a Module Federation approach, where there were heavy CPU and memory costs to serving your entire federation locally.
To start, we've greatly reduced the CPU and memory used for standing up your Module Federation "web" locally. These enhancements should be great news to larger workspaces using a Module Federation approach, where there were heavy CPU and memory costs to serving your entire federation locally.
We accomplished these improvements by batching any applications that are not being watched for changes (listed with the `--devRemotes` option) to a single server, rather than a unique server for each application. We also parallelized the builds of these static applications when you start up your serve! You can now use the `--parallel={number}` option to specify how many builds you want going at any given time.
In addition to performance improvements, we’ve brought the concept of dynamic federation to our React module federation support. Dynamic federation allows a host application to dynamically load remotes via the manifest file.
In addition to performance improvements, we've brought the concept of dynamic federation to our React module federation support. Dynamic federation allows a host application to dynamically load remotes via the manifest file.
You can generate your react module federation workspace now to use dyanmic federation via the `--dynamic` flag:
@@ -80,7 +81,7 @@ Lastly, we have an [example repo](https://github.com/jaysoo/nx-react-vite-module
Nx 17 launched with the new `nx release` capability in the Nx CLI. Since then we've been streamlining the experience, accounting for various edge cases and release scenarios. (extensive docs are being worked on rn ;)
To give you full flexibility, in 17.2, we’ve added a programmatic API, which will allow you to easily write custom release scripts:
To give you full flexibility, in 17.2, we've added a programmatic API, which will allow you to easily write custom release scripts:
This script above demonstrates how you can use this API to create your own script for updating your workspace’s version, then creating a changelog, and then publishing your package!
This script above demonstrates how you can use this API to create your own script for updating your workspace's version, then creating a changelog, and then publishing your package!
We’ve also added first class support for independently released projects, meaning you can now target a specific project for release with the `--projects` command. For example, you can create a new version for just one project in your workspace with the command:
We've also added first class support for independently released projects, meaning you can now target a specific project for release with the `--projects` command. For example, you can create a new version for just one project in your workspace with the command:
We just gave our Nx homepage a small facelift, including a new tagline, subtagline and illustration to better reflect Nx’s mission statement.
We just gave our Nx homepage a small facelift, including a new tagline, subtagline and illustration to better reflect Nx's mission statement.
When you enter the monorepo space, having good local development experience and tooling to support you is one thing, scaling is the other. And scaling comes with multiple challenges, from scaling teams working on the monorepo to maintaining high throughput on CI.
The latter is a common headache and we’ve seen companies struggle. With Nx we’re moving into the direction of becoming your e2e solution for monorepos, where we don’t just cover your local dev experience, but also provide robust and scalable solutions on CI.
The latter is a common headache and we've seen companies struggle. With Nx we're moving into the direction of becoming your e2e solution for monorepos, where we don't just cover your local dev experience, but also provide robust and scalable solutions on CI.
We’re super excited to have launched “Nx Agents” to Early Access. If you haven’t seen Victor’s video yet about how he reduced e2e tests from 90 minutes to 10, then make sure to [check it out](/ci/features/distribute-task-execution).
We're super excited to have launched "Nx Agents" to Early Access. If you haven't seen Victor's video yet about how he reduced e2e tests from 90 minutes to 10, then make sure to [check it out](/ci/features/distribute-task-execution).
**“Nx Agents”** are the next iteration of DTE, providing a more flexible, cost effective and more performant approach to distribution on CI. This includes things like being able to dynamically allocate machines based on the size of the PR and flaky task detection and re-running. Also, it can be configured with a single line:
**"Nx Agents"** are the next iteration of DTE, providing a more flexible, cost effective and more performant approach to distribution on CI. This includes things like being able to dynamically allocate machines based on the size of the PR and flaky task detection and re-running. Also, it can be configured with a single line:
```yaml
- name:Start CI run
@@ -160,11 +161,11 @@ We’re super excited to have launched “Nx Agents” to Early Access. If you h
...
```
You can run Nx Agents on any CI provider. If you’re curious, [sign up for early access](https://go.nx.dev/nx-agents-ea)!
You can run Nx Agents on any CI provider. If you're curious, [sign up for early access](https://go.nx.dev/nx-agents-ea)!
## New Canary Releases
We’ve added a new npm release tag: canary!
We've added a new npm release tag: canary!
@@ -182,7 +183,7 @@ This should be useful for previewing new not-yet released features!
We’re going live in January with the Nx team to go over these updates as well! Be sure to click the link to get notified when we go live! And feel free to come with your questions in the chat!
We're going live in January with the Nx team to go over these updates as well! Be sure to click the link to get notified when we go live! And feel free to come with your questions in the chat!
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://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
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://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
description: "Nx's 2023 highlights - Rust for performance, Vite support, publishing improvements, new backend tools, expanded IDE support, Playwright integration, TypeScript enhancements, Vue plugin, and community growth."
---
It is that time again: getting flooded by Year of Review blog posts. We did it last year, and we should do it again! So here we go, and be warned, 2023 was massive!!
@@ -13,7 +14,7 @@ It is that time again: getting flooded by Year of Review blog posts. We did it l
- [Top 10 Nx Highlights of 2023](#top-10-nx-highlights-of-2023)
- [TypeScript for Extensibility — Rust for Speed](#typescript-for-extensibility-rust-for-speed)
- [First Class Vite Support](#first-class-vite-support)
- [Nx’t Level Publishing](#nxt-level-publishing)
- [Nx't Level Publishing](#nxt-level-publishing)
- [Improved Node Backend Development: Fastify and Docker](#improved-node-backend-development-fastify-and-docker)
- [Nx Console support for IntelliJ](#nx-console-support-for-intellij)
- [Playwright for e2e testing](#playwright-for-e2e-testing)
@@ -38,7 +39,7 @@ We've picked out 10 highlights for you.
### TypeScript for Extensibility — Rust for Speed
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.
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](/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.
@@ -50,9 +51,9 @@ Such enhancements are especially crucial for the efficient [project graph calcul
### First Class Vite Support
Vite is rapidly transforming the landscape of frontend development! Its refreshing simplicity and innovative approach have made a significant mark in the developer community. What truly stands out is not just Vite’s technological aspect but also how its team approaches and grows the community around the tool. Vite stands for speed and community, values that deeply resonate with us here at Nx.
Vite is rapidly transforming the landscape of frontend development! Its refreshing simplicity and innovative approach have made a significant mark in the developer community. What truly stands out is not just Vite's technological aspect but also how its team approaches and grows the community around the tool. Vite stands for speed and community, values that deeply resonate with us here at Nx.
Our collaboration with our friends in the Vite core team has been incredibly fruitful. Vite is not just compatible but a first-class option with many of Nx’s frontend plugins. When you create a new Nx powered React workspace, Vite (and [Vitest](https://vitest.dev/)) are your default options.
Our collaboration with our friends in the Vite core team has been incredibly fruitful. Vite is not just compatible but a first-class option with many of Nx's frontend plugins. When you create a new Nx powered React workspace, Vite (and [Vitest](https://vitest.dev/)) are your default options.
@@ -60,21 +61,21 @@ We also built some powerful code generators that not only facilitate a seamless
[AnalogJS](https://analogjs.org/) — the fullstack Angular meta-framework which also heavily builds on top of Vite — is using the `@nx/vite` plugin to power its Angular and Nx based workspaces.
We also spoke at both editions of [ViteConf](https://viteconf.org/23/). If you’re curious check out [Juri’s talk about High Speed Monorepos](https://www.youtube.com/watch?si=A5Nkg3rxe3DlODc4&v=TiU-hdn7_To&feature=youtu.be) and this year’s talk by [Katerina on Streamlining your Vite dev flow with Nx](https://www.youtube.com/watch?si=A5Nkg3rxe3DlODc4&v=TiU-hdn7_To&feature=youtu.be).
We also spoke at both editions of [ViteConf](https://viteconf.org/23/). If you're curious check out [Juri's talk about High Speed Monorepos](https://www.youtube.com/watch?si=A5Nkg3rxe3DlODc4&v=TiU-hdn7_To&feature=youtu.be) and this year's talk by [Katerina on Streamlining your Vite dev flow with Nx](https://www.youtube.com/watch?si=A5Nkg3rxe3DlODc4&v=TiU-hdn7_To&feature=youtu.be).
### Nx’t Level Publishing
### Nx't Level Publishing
Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we’ll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like [release-it](https://github.com/release-it/release-it), [changesets](https://github.com/changesets/changesets), or custom Node scripts, similar to our approach in the Nx repository.
Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we'll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like [release-it](https://github.com/release-it/release-it), [changesets](https://github.com/changesets/changesets), or custom Node scripts, similar to our approach in the Nx repository.
However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we’ve introduced [the “nx release” command](/features/manage-releases), a solution designed to seamlessly integrate these processes into the Nx workflow.
However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we've introduced [the "nx release" command](/features/manage-releases), a solution designed to seamlessly integrate these processes into the Nx workflow.
James Henry gave a deep dive talk of an early version of it at this year’s Nx Conf:
James Henry gave a deep dive talk of an early version of it at this year's Nx Conf:
Since its introduction, the “nx release” feature has significantly evolved, leveraging the power of the Nx project graph to effectively understand inter-package dependencies. This understanding is crucial as it allows for:
Since its introduction, the "nx release" feature has significantly evolved, leveraging the power of the Nx project graph to effectively understand inter-package dependencies. This understanding is crucial as it allows for:
- Versioning packages offering support for both independent and “locked” versioning strategies.
- Versioning packages offering support for both independent and "locked" versioning strategies.
- Releasing packages in the correct sequence, ensuring dependency integrity.
Beyond these core functionalities, the feature also includes a robust grouping mechanism, supports semantic versioning, and changelog generation. Additionally, it provides various release targets, such as GitHub and NPM. For those having special requirements, the [programmatic API](/features/manage-releases#using-the-programmatic-api-for-nx-release) offers maximum flexibility.
@@ -83,21 +84,21 @@ Beyond these core functionalities, the feature also includes a robust grouping m
Colocating frontend and backend code within the same monorepo has become a popular practice. It greatly facilitates cross-functional teams and helps ensure end-to-end type safety. Although you can use [other backend stacks](https://www.nx-dotnet.com/) with Nx, Node is a popular backend companion for JS based frontends. We had support for [Express](https://expressjs.com/) and [NestJS](https://nestjs.com/) backend for a while.
This year we added another popular option: [Fastify](https://fastify.dev/). Known for its high performance, excellent developer experience, and useful built-in features like logging, Fastify aligns well with Nx’s modular software design principles. Its extensible and modular nature complements the Nx philosophy perfectly.
This year we added another popular option: [Fastify](https://fastify.dev/). Known for its high performance, excellent developer experience, and useful built-in features like logging, Fastify aligns well with Nx's modular software design principles. Its extensible and modular nature complements the Nx philosophy perfectly.
In tandem with Fastify, we’ve also introduced [Docker support](https://youtu.be/LHLW0b4fr2w?feature=shared) for Node deployments.
In tandem with Fastify, we've also introduced [Docker support](https://youtu.be/LHLW0b4fr2w?feature=shared) for Node deployments.
### Nx Console support for IntelliJ
Nx Console has evolved from an experimental side project of the Nx team to a core part for enhancing your productivity when working in a monorepo. Being integrated right into your editor it can provide useful information and functionality right where you need it, whether that’s running commands, [providing contextual autocomplete support](https://twitter.com/juristr/status/1653032530474565638) or the ability to explore the project and task graph.
Nx Console has evolved from an experimental side project of the Nx team to a core part for enhancing your productivity when working in a monorepo. Being integrated right into your editor it can provide useful information and functionality right where you need it, whether that's running commands, [providing contextual autocomplete support](https://twitter.com/juristr/status/1653032530474565638) or the ability to explore the project and task graph.
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](/blog/expanding-nx-console-to-jetbrains-ides) 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)
@@ -189,11 +190,11 @@ Similarly we improved the ability to package your TS libraries in multiple forma
But we wouldn’t be talking about Nx if we didn’t also look into speeding up TypeScript compilation for large monorepos. We called it “[batch mode](/showcase/benchmarks/tsc-batch-mode)”. 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.
But we wouldn't be talking about Nx if we didn't also look into speeding up TypeScript compilation for large monorepos. We called it "[batch mode](/showcase/benchmarks/tsc-batch-mode)". 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.
@@ -205,7 +206,7 @@ Vue is currently the second most popular frontend framework (according to npm do
The first place your might notice Nx’s support for Vue is in the `create-nx-workspace` script:
The first place your might notice Nx's support for Vue is in the `create-nx-workspace` script:
@@ -215,17 +216,17 @@ The option above will create a new Nx workspace with a fresh new Vue application
% npm add -D @nx/vue
```
And you’ll then have access to Nx generators so you can create Vue applications, libraries, and more in your workspace!
And you'll then have access to Nx generators so you can create Vue applications, libraries, and more in your workspace!
Checkout out our [Vue standalone tutorial](/getting-started/tutorials/vue-standalone-tutorial) for more, as well as our [Vue API docs](/nx-api/vue), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
Checkout out our [Vue API docs](/nx-api/vue), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
### Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of [community plugin contributions](/plugin-registry). Furthermore, Nx’s adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.
Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of [community plugin contributions](/plugin-registry). Furthermore, Nx's adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.
In 2023 we kept improving Nx’s extensibility, unifying the Nx plugin development model and how you develop workspace-local automations. You can now scaffold a new plugin into your Nx workspace and run it right away which makes it an interesting approach to automate your monorepo.
In 2023 we kept improving Nx's extensibility, unifying the Nx plugin development model and how you develop workspace-local automations. You can now scaffold a new plugin into your Nx workspace and run it right away which makes it an interesting approach to automate your monorepo.
@@ -241,7 +242,7 @@ We wanted to make building on top of Nx even more pleasant, allowing you to intr
npx create-qwik-nx
```
And finally, we extracted our own [Verdaccio](https://verdaccio.org/) setup that we’ve been using to run our e2e tests in the [Nx repo](https://github.com/nrwl/nx) s.t. you can use it for your own plugin development as well. Check out [this video](https://www.youtube.com/watch?v=t1c925TzrzE) for a walkthrough on how this works.
And finally, we extracted our own [Verdaccio](https://verdaccio.org/) setup that we've been using to run our e2e tests in the [Nx repo](https://github.com/nrwl/nx) s.t. you can use it for your own plugin development as well. Check out [this video](https://www.youtube.com/watch?v=t1c925TzrzE) for a walkthrough on how this works.
### Module Federation
@@ -251,17 +252,17 @@ Simply put, Module Federation allows a Javascript application running in a brows
This is an exciting development as it allows a paradigm shift in how you can architect, build, and deploy Javascript applications! And this is especially exciting for monorepo fans, as Nx has best-in-class support for module federation that makes a Module Federation approach easy to adopt and simple to understand!
Currently, our `@nx/angular` and `@nx/react` plugins both have generators to [create a “host” application](/recipes/module-federation/create-a-host) that will load and consume federated modules from [“remote” applications](/recipes/module-federation/create-a-remote), which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:
Currently, our `@nx/angular` and `@nx/react` plugins both have generators to [create a "host" application](/recipes/module-federation/create-a-host) that will load and consume federated modules from ["remote" applications](/recipes/module-federation/create-a-remote), which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:
Where in the example above your host application is named “host-application” and a remote application that you want live updates on as you’re developing is named “remote-application”.
Where in the example above your host application is named "host-application" and a remote application that you want live updates on as you're developing is named "remote-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!
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) 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
@@ -276,13 +277,13 @@ Numerous open-source packages are adopting Nx in this lightweight manner. It ena
I picked out some of the more well-known OSS repos that started using Nx this year:
[**Tanstack**](https://tanstack.com/) — Tanstack has evolved to an entire ecosystem consisting of the famous [Tanstack (or React) Query](https://github.com/tanstack/query), [Tanstack Table](https://github.com/tanstack/table), now also [Tanstack Router](https://github.com/tanstack/router) and [Tanstack Form](https://github.com/tanstack/form). It started with Tanstack Query, which adopted Nx and Nx Cloud. [Zack talked about this collab with Dominik](https://www.youtube.com/watch?v=NvPXK6DVZGE), and we also had [Dominik](https://twitter.com/TkDodo) on our [Nx live stream](https://www.youtube.com/live/IbU6b6s0H1Q?si=0QZexPwulLXB9FIN). Now, all the above-mentioned Tanstack libs have adopted Nx, and there’s more coming.
[**Tanstack**](https://tanstack.com/) — Tanstack has evolved to an entire ecosystem consisting of the famous [Tanstack (or React) Query](https://github.com/tanstack/query), [Tanstack Table](https://github.com/tanstack/table), now also [Tanstack Router](https://github.com/tanstack/router) and [Tanstack Form](https://github.com/tanstack/form). It started with Tanstack Query, which adopted Nx and Nx Cloud. [Zack talked about this collab with Dominik](https://www.youtube.com/watch?v=NvPXK6DVZGE), and we also had [Dominik](https://twitter.com/TkDodo) on our [Nx live stream](https://www.youtube.com/live/IbU6b6s0H1Q?si=0QZexPwulLXB9FIN). Now, all the above-mentioned Tanstack libs have adopted Nx, and there's more coming.
[**Sentry JavaScript**](https://github.com/getsentry/sentry-javascript/) — Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their [official JavaScript SDK](https://github.com/getsentry/sentry-javascript/). This move integrates Nx’s capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on [the benefits they’ve seen following the adoption of Nx in their monorepo](https://sentry.engineering/blog/reduce-ci-time-with-nx-caching) (hint: reducing CI times by 35%).
[**Sentry JavaScript**](https://github.com/getsentry/sentry-javascript/) — Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their [official JavaScript SDK](https://github.com/getsentry/sentry-javascript/). This move integrates Nx's capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on [the benefits they've seen following the adoption of Nx in their monorepo](https://sentry.engineering/blog/reduce-ci-time-with-nx-caching) (hint: reducing CI times by 35%).
[**RxJS**](https://github.com/ReactiveX/rxjs) — The library for reactive programming in JavaScript. It is widely popular, with over 40 million downloads/week on NPM. RxJS only recently adopted Nx, not only leveraging speed improvements via caching, but also leveraging Nx’s latest `nx release` feature to publish packages to NPM.
[**RxJS**](https://github.com/ReactiveX/rxjs) — The library for reactive programming in JavaScript. It is widely popular, with over 40 million downloads/week on NPM. RxJS only recently adopted Nx, not only leveraging speed improvements via caching, but also leveraging Nx's latest `nx release` feature to publish packages to NPM.
[**AnalogJS**](https://analogjs.org/) — Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses [Nx’s DevKit](/extending-nx/intro/getting-started) to create tools that work great in both Nx and Angular CLI workspaces.
[**AnalogJS**](https://analogjs.org/) — Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses [Nx's DevKit](/extending-nx/intro/getting-started) to create tools that work great in both Nx and Angular CLI workspaces.
[**Qwikifier**](https://github.com/qwikifiers/qwik-nx) — The Qwikifiers community built a dedicated Nx plugin to combine the power of Qwik and Nx. Their repo is a great example of building Nx plugins and [using Nx to build your own CLI](/extending-nx/recipes/create-install-package).
@@ -290,11 +291,11 @@ I picked out some of the more well-known OSS repos that started using Nx this ye
[**Ghost**](https://github.com/TryGhost/Ghost) — Are you into blogging? You might want to look at [Ghost](https://ghost.org/). They were using Lerna in the past and migrated to a fully Nx-powered workspace.
And these are just some of them that joined in 2023. If I missed some cool ones (which I’m pretty sure), [ping me](https://twitter.com/juristr) and let me know!
And these are just some of them that joined in 2023. If I missed some cool ones (which I'm pretty sure), [ping me](https://twitter.com/juristr) and let me know!
## Nx Community
Nx has a huge community! We’re lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or [creating awesome plugins](/plugin-registry).
Nx has a huge community! We're lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or [creating awesome plugins](/plugin-registry).
**Nx Champions** — This year we finally launched which we had planned for a long time. Our [Nx Champions](/community) program.
@@ -308,16 +309,16 @@ Make sure [you join](https://go.nx.dev/community)!
## New Content & Improved Docs
Our [Youtube channel](https://www.youtube.com/@nxdevtools) has grown to over 15k subscribers and peaks of 65k views a month. We love to provide educational video content, so make sure to subscribe! It got a little silent towards the end of the year, but we’ve been working a lot behind the scenes. So stay tuned!
Our [Youtube channel](https://www.youtube.com/@nxdevtools) has grown to over 15k subscribers and peaks of 65k views a month. We love to provide educational video content, so make sure to subscribe! It got a little silent towards the end of the year, but we've been working a lot behind the scenes. So stay tuned!
We also poured a lot of [effort into the docs](/getting-started/intro). We restructured them following the [Diataxis](https://diataxis.fr/) to make pages less overwhelming and more structured based on their type of content. You’ll find
We also poured a lot of [effort into the docs](/getting-started/intro). We restructured them following the [Diataxis](https://diataxis.fr/) to make pages less overwhelming and more structured based on their type of content. You'll find
- [**Concept docs**](/concepts) — which explain some of the inner workings and mental model behind certain features. Like [how caching works](/concepts/how-caching-works).
- [**Recipes**](/recipes) — which are solution oriented. You already know how to cook, we provide the exact recipe for it.
- [**Tutorials**](/getting-started/tutorials) — for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
- [**Reference**](/reference) and [**API docs**](/nx-api) — pure, raw and to the point.
We created a brand new [“Why Nx”](/getting-started/why-nx) page explaining the overall architecture of Nx including a [brand new video](https://www.youtube.com/watch?v=-_4WMl-Fn0w) giving you a holistic overview of what Nx is capable of.
We created a brand new ["Why Nx"](/getting-started/why-nx) page explaining the overall architecture of Nx including a [brand new video](https://www.youtube.com/watch?v=-_4WMl-Fn0w) giving you a holistic overview of what Nx is capable of.
We also refreshed our [entry pages](/getting-started/intro), including dedicated examples of using Nx with popular stacks:
@@ -327,17 +328,17 @@ 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).
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 in 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-monorepo).
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**.
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.
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: [/ci](/ci/intro/ci-with-nx).
@@ -347,7 +348,7 @@ We did it again! The second in-person Nx Conf was a resounding success, this tim
There’s not much to say. Check out some of the amazing talks. I did a [Nx Conf 2023 recap blog post](/blog/nx-conf-2023-recap).
There's not much to say. Check out some of the amazing talks. I did a [Nx Conf 2023 recap blog post](/blog/nx-conf-2023-recap).
## Looking ahead — 2024
@@ -355,7 +356,7 @@ Although we shipped a lot in 2023, in many ways 2023 was about preparing for wha
### Solving CI
Legacy CI systems are a performance and productivity bottleneck if you use a powerful build system like Nx. Big tech companies know it and that’s why their CI systems look nothing like Circle or Jenkins. We’ve been narrowing this gap over the years, but only this year we finally built a turn-key CI solution that gives you great performance, scalability, dev ergonomics, and must better cost efficiency.
Legacy CI systems are a performance and productivity bottleneck if you use a powerful build system like Nx. Big tech companies know it and that's why their CI systems look nothing like Circle or Jenkins. We've been narrowing this gap over the years, but only this year we finally built a turn-key CI solution that gives you great performance, scalability, dev ergonomics, and must better cost efficiency.
It has three components:
@@ -369,13 +370,13 @@ Optimal parallelization and distribution, using the right numbers of agents for
Balancing simplicity and power is the trickiest part of the dev tools design. Simple onboarding for small projects or handling the biggest enterprise systems? Two years ago we solved this problem by giving you a choice between the package-based setup (a more powerful version of something like Turborepo) and the integrated setup (we manage your whole monorepo in the most optimal way). But now we believe we have a much better solution, where you have both, the simplicity of the former with the power of the latter. So you no longer have to choose.
We took inspiration from VSCode. Any project you open in VSCode will work right away: it is simple, and you don’t need to configure anything. If you install say a Playwright plugin, VSCode becomes aware of Playwright. It can run and debug your tests right in the editor. That’s what the Nx experience is going to be like. Any project, any tool will work right away. But if you — for instance — install the Playwright plugin, Nx will become aware of Playwright and will be able to cache test runs in the most optimal way and distribute your e2e tests across machines for best efficiency. All the benefits with none of the costs.
We took inspiration from VSCode. Any project you open in VSCode will work right away: it is simple, and you don't need to configure anything. If you install say a Playwright plugin, VSCode becomes aware of Playwright. It can run and debug your tests right in the editor. That's what the Nx experience is going to be like. Any project, any tool will work right away. But if you — for instance — install the Playwright plugin, Nx will become aware of Playwright and will be able to cache test runs in the most optimal way and distribute your e2e tests across machines for best efficiency. All the benefits with none of the costs.
The whole team is excited about it as the new experience feels much more elegant.
As always, we try very hard not to break folks, so all your current workspaces will keep working, and we will [provide automatic migrations](/features/automate-updating-dependencies) to bring you to this new way of using Nx.
Exciting stuff! So keep an eye on our channels, and subscribe if you haven’t already ;)
Exciting stuff! So keep an eye on our channels, and subscribe if you haven't already ;)
title: 'Monorepos: the Benefits, Challenges, and Importance of Tooling Support '
description: 'Learn how monorepos and better tooling can help you overcome challenges in software development like scalability, maintenance, communication, and cost.'
Learn how monorepos and better tooling can help you overcome challenges in software development like scalability, maintenance, communication, and cost.
{% call-to-action title="Download the recording" url="https://go.nx.dev/january-webinar" description="Sign up to gain access" /%}
description: Introducing Project Crystal in Nx 18, a transformative approach to Nx plugins that makes them more transparent and lightweight, featuring inferred targets, reduced configuration overhead, and improved monorepo adoption.
---
Enhance, but don’t interfere! That’s the ideal! And this is how extensions work in VSCode (or Webstorm). You can use VSCode without any extension and get some basic functionality, or you can add an extension on top to enhance your experience and, ideally, increase your productivity.
Enhance, but don't interfere! That's the ideal! And this is how extensions work in VSCode (or Webstorm). You can use VSCode without any extension and get some basic functionality, or you can add an extension on top to enhance your experience and, ideally, increase your productivity.
Table of Contents
@@ -23,14 +24,14 @@ Table of Contents
---
**Prefer a video? We’ve got you covered!**
**Prefer a video? We've got you covered!**
{% youtube src="https://www.youtube.com/embed/wADNsVItnsM?si=sQ3-Dlx6KBRBUMkE" title="What if Nx Plugins Were More Like VSCode Extensions" /%}
Also, make sure to check out [Launch Nx Conf](/launch-nx) on Thursday, Feb 8th, where we’ll have more in-depth talks about Project Crystal as well as other exciting features around Nx and Nx Cloud.
Also, make sure to check out [Launch Nx Conf](/launch-nx) on Thursday, Feb 8th, where we'll have more in-depth talks about Project Crystal as well as other exciting features around Nx and Nx Cloud.
---
Take, for instance, the Playwright plugin. You install it, and it’ll automatically detect the Playwright config file and enhance your workspace by providing quick run buttons alongside your tests or even a dedicated Test Explorer window.
Take, for instance, the Playwright plugin. You install it, and it'll automatically detect the Playwright config file and enhance your workspace by providing quick run buttons alongside your tests or even a dedicated Test Explorer window.
_The Playwright VSCode extension enhancing the developer experience_
@@ -43,13 +44,13 @@ 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](/blog/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx).
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.
## Project Crystal
Nx always had more to offer, though, which it mainly did through its plugins. They’re optional but usually something you’d get set up when creating a new workspace with `create-nx-workspace`. Nx Plugins are extremely powerful, helping you not only create and configure new monorepos, but also taking away the burden of integrating various tooling as well as providing features for enforcing consistency and helping with maintainability. These aspects are fundamental in enterprise settings, where Nx Plugins have proven to help teams successfully manage their monorepos.
Nx always had more to offer, though, which it mainly did through its plugins. They're optional but usually something you'd get set up when creating a new workspace with `create-nx-workspace`. Nx Plugins are extremely powerful, helping you not only create and configure new monorepos, but also taking away the burden of integrating various tooling as well as providing features for enforcing consistency and helping with maintainability. These aspects are fundamental in enterprise settings, where Nx Plugins have proven to help teams successfully manage their monorepos.
However, this is a balancing act. More abstraction and automation means more support but also potentially a learning curve and giving up some low-level control. It also requires a slightly more significant upfront investment when migrating to an Nx plugin-powered monorepo.
@@ -74,7 +75,7 @@ When you create a new Nx workspace using
npx create-nx-workspace myorg
```
... and you choose an “integrated monorepo” you’ll get the usual setup powered by Nx Plugins and all the features and benefits that come with them. Where you’ll see Project Crystal in action is when you open a `project.json` file, which will most likely look like the following:
... and you choose an "integrated monorepo" you'll get the usual setup powered by Nx Plugins and all the features and benefits that come with them. Where you'll see Project Crystal in action is when you open a `project.json` file, which will most likely look like the following:
```json {% fileName="project.json" }
{
@@ -89,7 +90,7 @@ npx create-nx-workspace myorg
### Inferred Targets
Starting with Nx 18 and Project Crystal, we don’t generate any targets anymore, but the corresponding Nx plugin instead [infers them](/concepts/inferred-tasks). If we open the `nx.json`, you'll see a new property, `plugins`:
Starting with Nx 18 and Project Crystal, we don't generate any targets anymore, but the corresponding Nx plugin instead [infers them](/concepts/inferred-tasks). If we open the `nx.json`, you'll see a new property, `plugins`:
description: 'Explore how the new @nx/nuxt plugin enhances Nuxt.js development with automated task recognition and improved monorepo capabilities.'
---
We're excited to introduce a new way to enhance your [Nuxt](https://nuxt.com/) development workflow! After the Vue plugin, we're introducing our new Nx plugin for Nuxt, `@nx/nuxt`. Designed for Nuxt developers and existing Nx users alike, this integration brings the best of both worlds into your development ecosystem, enabling you to leverage Nx's powerful capabilities seamlessly within your Nuxt projects.
@@ -180,7 +181,7 @@ Whether you're starting a new Nuxt project or looking to enhance an existing one
## Nx Live With Nuxt Maintainer Daniel Roe
Don’t miss Nx team members Zack and Katerina with Nuxt’s maintainer, Daniel Roe — live!
Don't miss Nx team members Zack and Katerina with Nuxt's maintainer, Daniel Roe — live!
description: 'Discover how Nx Agents speeds up CI pipelines from 90 to 10 minutes by intelligently distributing tasks and managing resources.'
---
## From 90-minute to 10-minute CI Pipelines
@@ -59,7 +60,7 @@ At any point in the future, if a task is added to the system or there is a chang
## A Build System That Runs Your CI
Part of the reason CI is so difficult to maintain is that it has no knowledge of your repository. Your CI provider can’t optimize your pipeline because it doesn’t even know the language you’re using, let alone relationships between your projects. A build system, on the other hand, must know all that information in order to properly function.
Part of the reason CI is so difficult to maintain is that it has no knowledge of your repository. Your CI provider can't optimize your pipeline because it doesn't even know the language you're using, let alone relationships between your projects. A build system, on the other hand, must know all that information in order to properly function.
The key that unlocks all the power of Nx Agents is this architectural shift:
@@ -102,19 +103,19 @@ Nx understands that some CI pipelines need more resources than others. To accoun
## Automatically Split E2E Tasks by File
Typically, e2e tests are the tasks that take the longest in CI. In order to take advantage of parallelization and task distribution, these large tasks would need to be split into smaller tasks, but doing this manually would involve duplicating a lot of configuration code and making sure to keep that configuration synchronized. Nx 18’s [Project Crystal](/blog/what-if-nx-plugins-were-more-like-vscode-extensions) allows you to [automatically create separate Cypress and Playwright tasks](/ci/features/split-e2e-tasks) for each spec file in the e2e project. These individual tasks can all be triggered by running the `e2e-ci` task. What was once a tedious manual process can now be done for you automatically.
Typically, e2e tests are the tasks that take the longest in CI. In order to take advantage of parallelization and task distribution, these large tasks would need to be split into smaller tasks, but doing this manually would involve duplicating a lot of configuration code and making sure to keep that configuration synchronized. Nx 18's [Project Crystal](/blog/what-if-nx-plugins-were-more-like-vscode-extensions) allows you to [automatically create separate Cypress and Playwright tasks](/ci/features/split-e2e-tasks) for each spec file in the e2e project. These individual tasks can all be triggered by running the `e2e-ci` task. What was once a tedious manual process can now be done for you automatically.
## Identify and Re-run Flaky Tasks
There are some tasks that will fail or succeed in CI without any changes to the task’s code. These are flaky tasks and in order to merge a change in unrelated code, developers need to manually re-run the entire pipeline until that flaky task succeeds. Because Nx is already tracking inputs and outputs of tasks, it knows when a task is flaky. Now, Nx Cloud will [automatically re-run a flaky task if it fails](/ci/features/flaky-tasks), without a developer needing to manually trigger it.
There are some tasks that will fail or succeed in CI without any changes to the task's code. These are flaky tasks and in order to merge a change in unrelated code, developers need to manually re-run the entire pipeline until that flaky task succeeds. Because Nx is already tracking inputs and outputs of tasks, it knows when a task is flaky. Now, Nx Cloud will [automatically re-run a flaky task if it fails](/ci/features/flaky-tasks), without a developer needing to manually trigger it.
## Run Some Tasks on Another CI Provider
If you have a task that can’t be run on Nx Agents for some reason, you can easily [flag it to run directly on the main CI job](/ci/reference/nx-cloud-cli#enablingdisabling-distribution). Add a `--no-agents` flag to the command and Nx will not run it on an agent.
If you have a task that can't be run on Nx Agents for some reason, you can easily [flag it to run directly on the main CI job](/ci/reference/nx-cloud-cli#enablingdisabling-distribution). Add a `--no-agents` flag to the command and Nx will not run it on an agent.
description: 'Learn how to use Nx Release to version and publish packages in your monorepo with conventional commits and automated changelog generation.'
@@ -10,7 +11,7 @@ When it comes to publishing NPM packages, there are a bunch of libraries and uti
Nx already has all that knowledge, and it can leverage the information it has about your project dependencies and relationships to optimize your task runs.
Here’s the structure of our current example workspace we’re going to refer to in this article:
Here's the structure of our current example workspace we're going to refer to in this article:
@@ -20,9 +21,7 @@ As you can see `@tuskdesign/forms` relies on `@tuskdesign/buttons` and as such h
---
**Prefer a video?**
{% youtube src="https://www.youtube.com/embed/KjZKFGu3_9I?si=L-8oRzy-hV-WF_pS" title="Versioning and Releasing Packages in a Monorepo" /%}
{% link-card title="Free Course: Versioning and Releasing NPM packages with Nx" type="external" url="https://www.epicweb.dev/tutorials/versioning-and-releasing-npm-packages-with-nx" icon="/documentation/shared/images/nx-release-course-logo.webp" /%}
---
@@ -53,7 +52,7 @@ This brings up a couple of questions including whether to install [Project Cryst
It gives you some additional benefits ([you can read more here](/blog/what-if-nx-plugins-were-more-like-vscode-extensions)), but you don’t have to as it is not required for Nx Release.
It gives you some additional benefits ([you can read more here](/blog/what-if-nx-plugins-were-more-like-vscode-extensions)), but you don't have to as it is not required for Nx Release.
## Installing the JavaScript/TypeScript versioning Package
@@ -67,7 +66,7 @@ _(We use the `-w` flag to install it at the monorepo root level)_
## Running Nx Release
Once you’re set-up, you can already go ahead and run the following command:
Once you're set-up, you can already go ahead and run the following command:
```shell
pnpm nx release --dry-run
@@ -77,7 +76,7 @@ This command will do the versioning, changelog generation, and publishing steps
You’ll get asked whether you want to release a major, pre-major, minor… release or choose an exact version.
You'll get asked whether you want to release a major, pre-major, minor… release or choose an exact version.
Once this runs through, you might hit the following error:
@@ -169,7 +168,7 @@ pnpm nx release --dry-run
Let’s go ahead and change something in our `@tuskdesign/buttons` package and then commit it as follows:
Let's go ahead and change something in our `@tuskdesign/buttons` package and then commit it as follows:
```shell
git commit -am 'feat(buttons): add new background shadow'
@@ -229,13 +228,13 @@ Note, you can still use `--dry-run` and it'd show you the URL where the GitHub r
## Programmatic Mode
As you’ve seen, you can use `nx release` right away with minimal configuration. However, we are very well aware that many real-world scenarios are more complex, you want/need more control over when the version is happening, when the changelog generation kicks in and so on. This is why we also introduced a **programmatic API.**
As you've seen, you can use `nx release` right away with minimal configuration. However, we are very well aware that many real-world scenarios are more complex, you want/need more control over when the version is happening, when the changelog generation kicks in and so on. This is why we also introduced a **programmatic API.**
This approach gives you full control to embed Nx Release into your current release flow. There’s a nice [example script in our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release) that can help you get started.
This approach gives you full control to embed Nx Release into your current release flow. There's a nice [example script in our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release) that can help you get started.
Create a file — I call it `release.ts` - at the root of my workspace. Nx Release obviously doesn't care how the file is called or where you place it. You can also go with plain JS.
Here’s the [example script from our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release):
Here's the [example script from our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release):
```ts
import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';
description: 'Explore the major announcements from Launch Nx Week, including Nx 18.0, Project Crystal, Nuxt plugin, Nx Agents, and Tusky AI integration.'
---
We just finished wrapping up [Launch Nx Week](/launch-nx), which ran from February 5–9, including a full conference on Thursday!
In this article, we’re going to recap all the things launched during Launch Nx Conf, as well as all the talks given during the conference! Here’s a set of links so you can fast-forward to the stuff you’re most interested in if you want!
In this article, we're going to recap all the things launched during Launch Nx Conf, as well as all the talks given during the conference! Here's a set of links so you can fast-forward to the stuff you're most interested in if you want!
**Prefer a video?**
@@ -29,7 +30,7 @@ In this article, we’re going to recap all the things launched during Launch Nx
## Nx 18.0 && Project Crystal
Exciting news!! We’ve broken our standard release cadence of publishing a new major version every 6 months to release Nx 18, just 3 months after releasing Nx 17 in December 2024.
Exciting news!! We've broken our standard release cadence of publishing a new major version every 6 months to release Nx 18, just 3 months after releasing Nx 17 in December 2024.
Juri announced launched Project Crystal with this video:
@@ -39,7 +40,7 @@ The short version is: Nx project crystal means Nx plugins make your codebases wo
For the long version, checkout this blog post by Juri where he describes [how Nx plugins are now more like VsCode Extentions](/blog/what-if-nx-plugins-were-more-like-vscode-extensions)!
And don’t miss our two conference talks on this subject:
And don't miss our two conference talks on this subject:
### Conference Talk: Project Crystal
@@ -55,7 +56,7 @@ And don’t miss our two conference talks on this subject:
## New Plugin: @nx/nuxt
On Tuesday we launched our newest plugin, and our first plugin to be :gem:crystalized:gem: from it’s very beginning: @nx/nuxt!
On Tuesday we launched our newest plugin, and our first plugin to be :gem:crystalized:gem: from it's very beginning: @nx/nuxt!
Zack explains Nuxt and how to use the new plugin in this video:
@@ -77,7 +78,7 @@ Zack, Katerina, and Daniel got together to live code a working tic-tac-toe app u
Nx Agents are here!! We launched Nx Agents on Wednesday, and it climbed into the top 20 on [Product Hunt](https://www.producthunt.com/products/nx-cloud#nx-agents)!
We’re very excited about Nx Agents because we think that in its current state, Continuous Integration/Deployment is broken, and we think that Nx paired with Nx Agents fixes Continuous Integration. Zack explains more in this video:
We're very excited about Nx Agents because we think that in its current state, Continuous Integration/Deployment is broken, and we think that Nx paired with Nx Agents fixes Continuous Integration. Zack explains more in this video:
@@ -111,15 +112,15 @@ In the teaser video, you can see some ways Tusky will be integrated into Nx Clou
The more exciting features of Tusky though includes the ability to perfectly optimize the number of agents used per PR — even spinning up and tearing down agents mid-pipeline! This is a huge optimization for task distribution, and will help optimize both walltime of your CI, as well as compute costs!
Tusky will also be able to provide organizational-level insights to your codebase, including automatically detecting development groups (like lines of business) inside your codebase based on commit history, and providing statistical insights on their commit patterns. We’re also excited about Tusky being able to make suggestions on things you can do to further optimize your codebase — like generating a PR to introduce [Codeowners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) to the repo!
Tusky will also be able to provide organizational-level insights to your codebase, including automatically detecting development groups (like lines of business) inside your codebase based on commit history, and providing statistical insights on their commit patterns. We're also excited about Tusky being able to make suggestions on things you can do to further optimize your codebase — like generating a PR to introduce [Codeowners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) to the repo!
## Nx Release Is Stable
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](/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.
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!
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!
Juri goes into [full details in this blog post](/blog/versioning-and-releasing-packages-in-a-monorepo), and James Henry — our Director of Engineering and the primary engineer responsible for both maintaining Lerna and creating Nx Release — expands further in his conference talk:
@@ -135,7 +136,7 @@ Juri, Zack, and Victor wrapped up the week with a livestream recapping the launc
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://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
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://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
title: 'Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos'
description: 'Learn how you can streamline your existing CI config to its absolute simplest form, reducing CI times from 30 minutes to ~5 minutes with Nx Agents. '
description: 'Discover how Nx enhances development speed through Rust integration, improved caching, Nx Agents, and test atomization features.'
---
In the ever-evolving landscape of software development, efficiency and speed are vital. As projects grow in complexity, developers and teams need tools that can keep up without sacrificing quality or performance.
Nx is a suite of powerful tools designed to optimize your development workflow, which sets the [building blocks for a fast CI](/ci/concepts/building-blocks-fast-ci). Nx is always innovating in many ways to make developers’ lives easier, but this post is exclusively focused on the things Nx has done in the past year to make development faster and faster.
Nx is a suite of powerful tools designed to optimize your development workflow, which sets the [building blocks for a fast CI](/ci/concepts/building-blocks-fast-ci). Nx is always innovating in many ways to make developers' lives easier, but this post is exclusively focused on the things Nx has done in the past year to make development faster and faster.
## Why speed matters
@@ -18,13 +19,13 @@ The ability to iterate quickly and efficiently is vital for any software project
- **Reduced time to market:** Accelerating the development process can significantly cut down the overall time to market, providing a competitive edge which reclaims revenue that would have otherwise been lost.
- **Decreased developer frustration:** [No more waiting for builds and tests to complete](/ci/concepts/reduce-waste). A streamlined workflow keeps morale high and productivity higher.
If you’re using Nx already, you’re already familiar with
If you're using Nx already, you're already familiar with
- [**Affected**](/ci/features/affected) - identifying and running tasks only on projects impacted by code changes,
- [**Nx Replay**](/ci/features/remote-cache) - our powerful cache and
- [**Nx Agents**](/ci/features/distribute-task-execution) - the concept of [Parallelization and Distribution](/ci/concepts/parallelization-distribution).
But let’s see all the extra things we did this past year to make everything faster.
But let's see all the extra things we did this past year to make everything faster.
## Speed at the core
@@ -44,9 +45,9 @@ The archive file is a binary file that contains the workspace file hashes with t
Nx Replay enables caching and reusing of task results. It’s our well known Nx remote cache! It allows developers to avoid re-running expensive tasks by retrieving the cached results from a remote cache. This significantly improves build and test performance, as well as developer productivity. Nx Replay is also critical to the functioning of Nx Agents, which rely on the remote cache to ensure that the results of a task will be shared with every agent that needs them. By using Nx Replay, developers can optimize their workflows and reduce the time spent waiting for tasks to complete.
Nx Replay enables caching and reusing of task results. It's our well known Nx remote cache! It allows developers to avoid re-running expensive tasks by retrieving the cached results from a remote cache. This significantly improves build and test performance, as well as developer productivity. Nx Replay is also critical to the functioning of Nx Agents, which rely on the remote cache to ensure that the results of a task will be shared with every agent that needs them. By using Nx Replay, developers can optimize their workflows and reduce the time spent waiting for tasks to complete.
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.
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
@@ -55,7 +56,7 @@ With Nx Replay, you can see significant speed improvements in your CI pipelines
[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/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
- 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
- Dynamic sizing based on PR size
@@ -82,7 +83,7 @@ Nx creates a hash of all the inputs for a task whenever it is run. If it encount
### Module Federation
With the help of Nx and the Module Federation setup that Nx offers, you can split up large Angular apps into smaller “vertical slices”. This can significantly speed up your builds and app startup time. Nx has revolutionized the use of Module Federation, especially in how static remotes are built and served. We make use of Nx’s task orchestration, allowing users to fine tune the number of builds happening in parallel to improve local startup time, manage machine resources better, allow for scaling.
With the help of Nx and the Module Federation setup that Nx offers, you can split up large Angular apps into smaller "vertical slices". This can significantly speed up your builds and app startup time. Nx has revolutionized the use of Module Federation, especially in how static remotes are built and served. We make use of Nx's task orchestration, allowing users to fine tune the number of builds happening in parallel to improve local startup time, manage machine resources better, allow for scaling.
description: 'Learn how Nx Cloud revolutionizes CI with a task-based execution model that solves both flaky tests and slow pipelines.'
---
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.
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.
**By switching from the old CI model, implemented as a graph of VMs, to the new one, implemented as a graph of tasks, we can solve both the flakiness and slowness.**
In this blog post I’ll explore why this is the case, and how you can do it by using Nx Cloud.
In this blog post I'll explore why this is the case, and how you can do it by using Nx Cloud.
---
## History of CI
It’s easy to forget that Continuous Integration has been around for only 20 years. For reference, UI frameworks have been around since the 1970s.
It's easy to forget that Continuous Integration has been around for only 20 years. For reference, UI frameworks have been around since the 1970s.
@@ -37,9 +37,9 @@ A traditional CI execution is a directed acyclic graph (DAG) of virtual machines
**Every distributed system needs efficient communication between nodes and the ability to tolerate failure.**
The traditional CI execution model offers **very basic** means of communication: the status code propagation and ad-hoc ways of uploading/downloading files. Because the communication is effortful, in practice, **it’s either not done at all or very minimally.**
The traditional CI execution model offers **very basic** means of communication: the status code propagation and ad-hoc ways of uploading/downloading files. Because the communication is effortful, in practice, **it's either not done at all or very minimally.**
To understand why the traditional CI execution model fails to handle failures, let’s review the types of failures we can have.
To understand why the traditional CI execution model fails to handle failures, let's review the types of failures we can have.
Failures can be:
@@ -54,11 +54,11 @@ Tasks can fail:
- for external reasons _(npm install fails cause npm is down)_
- for unknown reasons _(a flaky test)_
**The traditional CI execution model doesn’t tolerate any of these failures.**
**The traditional CI execution model doesn't tolerate any of these failures.**
## Problem in numbers
Let’s see how varying a few parameters affects the probability of the CI execution failing.
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 |
@@ -69,9 +69,9 @@ Let’s see how varying a few parameters affects the probability of the CI execu
| 10 | 10 | 0.5% | 1% | 40% | 65% |
| 50 | 10 | 0.5% | 1% | 92% | 99% |
**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.
**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.
One can try to fix it by increasing the robustness of the tests, but at some point, doing this is costly. If an e2e test has a 10% chance of a flaky failure, it’s relatively easy to bring this number to 1%. Going from 1% to 0.5% is harder. Going from 0.5% to 0.1% is exceptionally hard and may be practically impossible. Testing complex systems is simply a difficult task.
One can try to fix it by increasing the robustness of the tests, but at some point, doing this is costly. If an e2e test has a 10% chance of a flaky failure, it's relatively easy to bring this number to 1%. Going from 1% to 0.5% is harder. Going from 0.5% to 0.1% is exceptionally hard and may be practically impossible. Testing complex systems is simply a difficult task.
description: 'Trying to convince your colleagues to use a monorepo? Already using a monorepo and need to justify that decision? Check out this webinar to learn 7 essential reasons for using monorepos and bust a few myths and misconceptions along the way.'
Trying to convince your colleagues to use a monorepo? Already using a monorepo and need to justify that decision? Check out this webinar to learn 7 essential reasons for using monorepos and bust a few myths and misconceptions along the way.
{% call-to-action title="Download the recording" url="https://go.nx.dev/april-webinar" description="Sign up to gain access" /%}
description: 'Learn how to manage Gradle projects in Nx workspaces using the new @nx/gradle plugin for better library visualization and multi-tech stack support.'
---
Here’s my situation: I have a Gradle workspace with multiple Gradle libraries. How do I easily view the relationships between different libraries? I have a monorepo workspace with both Gradle and Javascript libraries, how do I manage these libraries of different tech stacks?
Here's my situation: I have a Gradle workspace with multiple Gradle libraries. How do I easily view the relationships between different libraries? I have a monorepo workspace with both Gradle and Javascript libraries, how do I manage these libraries of different tech stacks?
We are very excited to announce our support for Gradle with our new plugin: `@nx/gradle`.
@@ -24,9 +25,9 @@ This blog will show you:
## What is Nx?
Before we start, let’s answer this question: what is Nx and why should we use it?
Before we start, let's answer this question: what is Nx and why should we use it?
From [nx.dev](): “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.” It sounds good, what benefits does it bring?
From [nx.dev](): "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." It sounds good, what benefits does it bring?
Nx adds the following features to your workspace:
@@ -41,7 +42,7 @@ Nx adds the following features to your workspace:
## How to add Nx to a Gradle Workspace?
Now we understand the benefits of Nx, now let’s set it up. The setup is pretty easy, just need to run one command.
Now we understand the benefits of Nx, now let's set it up. The setup is pretty easy, just need to run one command.
description: 'Explore Nx 19.0, returning to our six-month release cycle with enhanced Project Crystal plugins that work seamlessly with minimal configuration.'
---
Hey folks!
@@ -80,9 +81,9 @@ You'll see the following in the project view:
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):
You can also find the same enhancements in Nx Cloud. Below is a view of all tasks in the CI pipeline:
{% 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" /%}
{% video-player src="/documentation/blog/media/2024-05-08/nx-cloud-atomizer-groupings.mp4" alt="Showing the Atomizer in Nx Cloud" autoPlay=true loop=true /%}
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 +161,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).
{% 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.
@@ -182,7 +183,7 @@ 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):
{% 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" /%}
{% video-player src="/documentation/blog/media/2024-05-08/nx-cloud-atomizer-groupings.mp4" alt="Showing the Atomizer in Nx Cloud" autoPlay=true loop=true /%}
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.
description: 'Join Zack DeRose as he discusses enterprise software development with veteran Hicham El Hammouchi, exploring challenges and emerging trends.'
---
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.
description: Explain with AI in Nx Cloud Pro helps debug CI failures with AI explanations and suggested fixes.
---
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)**.
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.
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.
description: 'Join Nx Champion Ahmed Elsakaan as he discusses his tools noodle and OrbitKit, exploring how they improve monorepo setup and module creation.'
---
In this episode we welcome Nx Champion and creator of [noodle](https://noodle.run) and [OrbitKit](https://orbitkit.dev/): Ahmed Elsakaan.
description: "Discover how Cvent's Platform Architects leverage Nx in their platform engineering strategy to empower teams across their organization."
---
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/).
description: Nx Cloud introduces a structured table view for CI logs, enhancing monorepo task tracking and visibility.
---
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**.
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.
Leosvel Pérez Espinosa