<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect 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
3c9d3cf4cb/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 #
