Conversation
Add failing tests for NXC-4185 covering projectsAffectedByDependencyUpdates "auto" mode with npm, yarn, bun.lock, and bun.lockb. Each test uses format-appropriate JSON diff paths matching the real lock file structure. The .failing() tests document the current bug where auto mode silently returns [] for non-pnpm package managers.
The projectsAffectedByDependencyUpdates "auto" setting previously only worked for pnpm lock files, silently returning [] for npm, yarn, and bun. This meant lockfile-only changes (e.g. npm audit fix, transitive dep updates) produced zero affected projects for non-pnpm package managers. Now each lock file format is handled: - pnpm: parses "importers" to identify affected project paths (unchanged) - npm: parses "packages" keys to extract project paths from node_modules paths - yarn: returns all projects (flat format with no per-project structure) - bun: parses "workspaces" to identify affected project paths - binary files (bun.lockb): returns all projects as a safe fallback
The projectsAffectedByDependencyUpdates "auto" setting previously only worked for pnpm lock files, silently returning [] for npm, yarn, and bun. This meant lockfile-only changes (e.g. npm audit fix, transitive dep updates) produced zero affected projects for non-pnpm package managers. Now each lock file format is handled via a LOCK_FILE_RESOLVERS map: - pnpm: parses "importers" to identify affected project paths (unchanged) - npm: parses "packages" keys to extract project paths from node_modules paths - yarn: returns all projects (flat format with no per-project structure) - bun: parses "workspaces" to identify affected project paths - binary files (bun.lockb): returns all projects as a safe fallback
…e managers Pull in documentation from docs/js-plugin-config-options branch and update to reflect that "auto" mode now works for all package managers, not just pnpm. Includes per-package-manager behavior details in the affected docs and updated reference table in nx-json.
Use a SupportedLockFile type guard with satisfies instead of Record<string, ...> so the map index is type-safe. If the guard fails to match, return null (all projects affected) rather than calling an undefined function.
Remove analyze-source-files rewrite and nx-json plugins config section that document analyzeSourceFiles, analyzePackageJson, and analyzeLockfile. Those changes belong in the original docs/js-plugin-config-options branch, not in this fix for projectsAffectedByDependencyUpdates.
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nx-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
View your CI Pipeline Execution ↗ for commit 37715d5
☁️ Nx Cloud last updated this comment at |
llwt
commented
Apr 1, 2026
Replace the TODO comment with an actual logger.warn() call when an unsupported lock file reaches the auto mode resolver. Add a test for the unrecognized lock file case.
Refactor auto mode to extract changed package names from lock file diffs and return matching external node names from the project graph. The existing graph reversal in filterAffected then walks from those nodes to find affected workspace projects. - Resolvers now extract package names instead of project paths - Uses projectGraph.externalNodes to look up changed packages - Yarn lock files can now identify specific changed packages instead of falling back to "all projects affected" - Root-level npm dependency changes are now detected - Removes RootPathLookup class (no longer needed)
Replace the JSON-diff-based heuristic for detecting changed packages with a parser-based approach that reuses Nx's existing lock file parsers. The base and head revisions are parsed and their external-node maps diffed to identify packages whose versions actually changed, which avoids brittle per-format path matching and correctly handles yarn.lock (which JsonDiff could not meaningfully traverse).
…meter in lock-file-changes
![nx-cloud[bot]](https://avatars.githubusercontent.com/in/80458?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Use is-odd and left-pad to avoid transitive dependency overlap that caused the isolation test to fail. is-even@1.0.0 transitively depends on is-odd, so bumping is-odd rippled through both libs.
Run the affected-auto-lockfile suite against pnpm, yarn, npm, and bun so each supported lock-file parser is exercised end-to-end.
FrozenPandaz
added
the
priority: medium
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Co-authored-by: llwt <llwt@users.noreply.github.com>
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Two CI failures caught after merging master into NXC-4185:
- getLockFileNodesForName defaulted to PackageJson = {}, which fails
TypeScript's strict requirement that PackageJson has name/version.
Cast the default literal so the runtime semantics (empty fallback for
npm/pnpm/etc., real packageJson for yarn/bun) are preserved without a
non-null assertion at the yarn/bun call site.
- calculateFileChanges' bun.lockb test inherited the existsSync=false
mock from the previous "deleted file" test, causing it to return
DeletedFileChange instead of LockFileChange. Mock existsSync=true
inside the test so it does not depend on prior test state.
The previous commit (15eed2f) accidentally truncated lock-file.ts to only the first 130 lines. Restoring full file content with the original fix intact (PackageJson default cast and bun.lockb test mock).
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Yarn v4 requires the lockfile to be refreshed after creating a new workspace package; without it, subsequent yarn operations fail with "This package doesn't seem to be present in your lockfile". Adding an intermediate install between the two @nx/js:lib generations in the beforeAll setup unblocks the yarn-specific e2e and is a no-op for pnpm/npm/bun. Root cause analysis from Nx Cloud Self-Healing.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
…[Self-Healing CI Rerun]
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Contributor
There was a problem hiding this comment.
Nx Cloud has identified a flaky task in your failed CI:
🔂 Since the failure was identified as flaky, we triggered a CI rerun by adding an empty commit to this branch.
🔔 Heads up, your workspace has pending recommendations ↗ to auto-apply fixes for similar failures.
🎓 Learn more about Self-Healing CI on nx.dev
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Behavior
The
projectsAffectedByDependencyUpdates: "auto"setting only works for pnpm lock files. For npm (package-lock.json), yarn (yarn.lock), and bun (bun.lock/bun.lockb), auto mode silently returns an empty array -- meaning lockfile-only changes (e.g.npm audit fix, transitive dependency updates) produce zero affected projects.Expected Behavior
Auto mode detects affected projects from lock file changes for all supported package managers:
pnpm-lock.yaml): Inspects theimporterssection to determine exactly which workspace projects had dependency changes (unchanged).package-lock.json): Inspects thepackagesentries to determine which workspace projects had dependency changes.bun.lock): Inspects theworkspacessection to determine which workspace projects had dependency changes.yarn.lock): The lock file is a flat list with no per-project structure, so all projects are marked as affected when any dependency changes.bun.lockb) / WholeFileChange: Cannot be parsed for granular changes, so all projects are marked as affected.The implementation uses a
LOCK_FILE_RESOLVERSmap with aSupportedLockFiletype guard so that adding a new lock file format requires adding exactly one entry -- no separate lists to keep in sync.Related Issue(s)
Follow-up to #34937 which documented the pnpm-only limitation.
Fixes NXC-4185
Fixes #35173