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 #
