Overview - Nx

Nx

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Failed
34111
Flaky task→
6dcd2155 fix(core): use readJsonFile to avoid require cache in getLocalNxVersion The previous commit switched to `require()` for reading nx/package.json which causes Node's require cache to return stale data when the file is modified on disk. Use `readJsonFile` instead to always read fresh from disk while keeping the `createRequire`+`resolve` approach for path resolution. Fixes e2e-nx misc.test.ts failures for version mismatch warnings.
5 days ago by Coly010
Failed
34111
4e1feeb1 fix(core): use readJsonFile to avoid require cache in getLocalNxVersion The previous commit switched to `require()` for reading nx/package.json which causes Node's require cache to return stale data when the file is modified on disk. Use `readJsonFile` instead to always read fresh from disk while keeping the `createRequire`+`resolve` approach for path resolution. Fixes e2e-nx misc.test.ts failures for version mismatch warnings.
5 days ago by Coly010
Failed
34111
07e5e687 fix(core): use createRequire to avoid self-referencing in nx resolution The exports field in nx package.json enables Node.js self-referencing, causing require.resolve with paths option to always resolve to the current package. This made isLocalInstall always true, breaking global-to-local nx delegation. Use Module.createRequire from an external context to resolve nx, which avoids triggering self-referencing while still following the exports map.
6 days ago by Coly010
Failed
34111
f0674b50 fix(core): use createRequire to avoid self-referencing in nx resolution The exports field in nx package.json enables Node.js self-referencing, causing require.resolve with paths option to always resolve to the current package. This made isLocalInstall always true, breaking global-to-local nx delegation. Use Module.createRequire from an external context to resolve nx, which avoids triggering self-referencing while still following the exports map.
6 days ago by Coly010
Failed
34111
4fbf50d6 fix(testing): use getStrippedEnvironmentVariables in jest e2e NODE_ENV test The "should be resilient against NODE_ENV values" test was using ...process.env which leaked unfiltered NX_* variables into the child process, causing Nx Cloud initialization failures. Use getStrippedEnvironmentVariables() instead, which is already imported and properly filters out problematic variables while preserving PATH.
7 days ago by Coly010
Failed
34111
b4541d0b fix(core): add missing JSON file exports to nx package.json The exports field was missing entries for migrations.json, generators.json, and executors.json. This caused ERR_PACKAGE_PATH_NOT_EXPORTED when resolving bare specifiers like 'nx/migrations.json' (used by nx repair/lerna repair).
7 days ago by Coly010
Succeeded
master
df9eb0bf fix(release): add null-safe fallback for version in createGitTagValues (#34598) ## Current Behavior When nx release runs with docker-configured projects (either via explicit config or @nx/docker plugin inference), git tags are created with the literal string {version} instead of the actual version number (e.g., v{version} instead of v1.0.6, or app-3@{version} instead of app-3@1.0.0). This happens because: 1. If ANY project in a release group has docker config, preferDockerVersion is auto-set to true for the ENTIRE group 2. createGitTagValues() then blindly selects projectVersionData.dockerVersion, which is null for non-docker projects (or projects with no changes) 3. The interpolate() function receives null for {version} and returns the literal placeholder unchanged Commit messages are unaffected because createCommitMessageValues() only uses newVersion and already guards against null. The changelog code (changelog.ts:1117-1121) also already has the correct null-safe pattern. ## Expected Behavior When preferDockerVersion is true but dockerVersion is null, git tags should fall back to using newVersion instead of producing literal {version} placeholders. When both versions are null, no tag should be created. For mixed release groups (some projects have docker config, some don't), the auto-enable logic should use 'both' mode instead of true, which already has proper null-safe checks for each version type. ## Changes - shared.ts: Added null-safe fallback (??) in createGitTagValues() for both independent and fixed group code paths, plus a guard to skip tag creation when both versions are null - config.ts: Refined auto-enable logic to check whether ALL or only SOME projects have docker config — mixed groups now get 'both' mode instead of true - shared.spec.ts: Added 5 test cases covering null version fallback scenarios for fixed groups, independent groups, both-null, reverse fallback, and mixed groups ## Related Issue(s) Fixes #34382 Fixes #33890 Fixes #34391
7 days ago by Coly010
Succeeded
master
df9eb0bf fix(release): add null-safe fallback for version in createGitTagValues (#34598) ## Current Behavior When nx release runs with docker-configured projects (either via explicit config or @nx/docker plugin inference), git tags are created with the literal string {version} instead of the actual version number (e.g., v{version} instead of v1.0.6, or app-3@{version} instead of app-3@1.0.0). This happens because: 1. If ANY project in a release group has docker config, preferDockerVersion is auto-set to true for the ENTIRE group 2. createGitTagValues() then blindly selects projectVersionData.dockerVersion, which is null for non-docker projects (or projects with no changes) 3. The interpolate() function receives null for {version} and returns the literal placeholder unchanged Commit messages are unaffected because createCommitMessageValues() only uses newVersion and already guards against null. The changelog code (changelog.ts:1117-1121) also already has the correct null-safe pattern. ## Expected Behavior When preferDockerVersion is true but dockerVersion is null, git tags should fall back to using newVersion instead of producing literal {version} placeholders. When both versions are null, no tag should be created. For mixed release groups (some projects have docker config, some don't), the auto-enable logic should use 'both' mode instead of true, which already has proper null-safe checks for each version type. ## Changes - shared.ts: Added null-safe fallback (??) in createGitTagValues() for both independent and fixed group code paths, plus a guard to skip tag creation when both versions are null - config.ts: Refined auto-enable logic to check whether ALL or only SOME projects have docker config — mixed groups now get 'both' mode instead of true - shared.spec.ts: Added 5 test cases covering null version fallback scenarios for fixed groups, independent groups, both-null, reverse fallback, and mixed groups ## Related Issue(s) Fixes #34382 Fixes #33890 Fixes #34391
7 days ago by Coly010
Failed
34144
Fix applied→
db9c5630 fix(core): update analytics prompt
7 days ago by Coly010
Succeeded
34598
791b585e test(release): add tests for null version fallback in createGitTagValues Add five test cases covering: - preferDockerVersion=true with null dockerVersion (fixed group) - preferDockerVersion=true with null dockerVersion (independent group) - Both versions null with preferDockerVersion=true - preferDockerVersion=false with null newVersion - Mixed independent group with some docker and some non-docker projects
7 days ago by Coly010
Failed
34111
Fix rejected→
5b0a6d8d fix(core): update e2e test paths to use dist directory Fixes missed path updates in e2e tests for the nx package dist restructuring.
7 days ago by Coly010
Failed
34598
791b585e test(release): add tests for null version fallback in createGitTagValues Add five test cases covering: - preferDockerVersion=true with null dockerVersion (fixed group) - preferDockerVersion=true with null dockerVersion (independent group) - Both versions null with preferDockerVersion=true - preferDockerVersion=false with null newVersion - Mixed independent group with some docker and some non-docker projects
7 days ago by Coly010
Failed
34111
09eba563 fix(core): update e2e test paths to use dist directory Fixes missed path updates in e2e tests for the nx package dist restructuring.
8 days ago by Coly010
Failed
34111
Flaky task→
d521543b chore(core): handle import for show targets
8 days ago by Coly010
Failed
34568
d954f3c6 fix(module-federation): widen @module-federation/enhanced peer dep range and update to v2 The `@module-federation/enhanced` peer dependency in `@nx/rspack` was pinned to `^0.21.2` which under semver 0.x rules only allows `>=0.21.2 <0.22.0`. Since the package has released 0.22.x, 0.23.x, and 2.0.x, users installing the latest version get unmet peer dependency warnings. - Widen dep ranges from `^0.21.2` to `>=0.21.2 <3.0.0` in @nx/rspack and @nx/module-federation to accept all current versions - Make MF peer deps optional in @nx/rspack since not all rspack users use Module Federation - Update generator version constants to `^2.0.0` so new projects scaffold with the latest stable version - Add 22.5.3 migration entries to update existing projects to ^2.0.0 Fixes #34420
8 days ago by Coly010
Failed
34568
26768904 fix(module-federation): widen @module-federation/enhanced peer dep range and update to v2 The `@module-federation/enhanced` peer dependency in `@nx/rspack` was pinned to `^0.21.2` which under semver 0.x rules only allows `>=0.21.2 <0.22.0`. Since the package has released 0.22.x, 0.23.x, and 2.0.x, users installing the latest version get unmet peer dependency warnings. - Widen dep ranges from `^0.21.2` to `>=0.21.2 <3.0.0` in @nx/rspack and @nx/module-federation to accept all current versions - Make MF peer deps optional in @nx/rspack since not all rspack users use Module Federation - Update generator version constants to `^2.0.0` so new projects scaffold with the latest stable version - Add 22.5.3 migration entries to update existing projects to ^2.0.0 Fixes #34420
8 days ago by Coly010
Canceled
34111
6c0a514a chore(core): handle import for show targets
8 days ago by Coly010
Failed
34111
41d208ea chore(core): handle import for show targets
8 days ago by Coly010
Succeeded
master
1a15ea18 fix(js): use per-invocation cache in TS plugin to fix NX_ISOLATE_PLUGINS=false (#34566) When plugin isolation is off, concurrent createNodesV2 invocations share the same module instance. The module-level mutable `cache` variable caused invocation A's `finally` block to null it out while invocation B was still reading from it, resulting in "Cannot read properties of null (reading 'configContexts')". Replace the shared mutable `cache` with a Symbol-keyed Map so each invocation gets its own isolated cache. The tsconfig disk cache is shared across invocations with an idempotent initialization guard. CLOSES NXC-3971
8 days ago by Coly010
Succeeded
34566
4341d212 fix(js): use per-invocation cache in TS plugin to fix NX_ISOLATE_PLUGINS=false When plugin isolation is off, concurrent createNodesV2 invocations share the same module instance. The module-level mutable `cache` variable caused invocation A's `finally` block to null it out while invocation B was still reading from it, resulting in "Cannot read properties of null (reading 'configContexts')". Replace the shared mutable `cache` with a Symbol-keyed Map so each invocation gets its own isolated cache. The tsconfig disk cache is shared across invocations with an idempotent initialization guard.
8 days ago by Coly010