fix(detect): decouple node script discovery from PM detection + mirror resolver PM chain#32
Conversation
|
Superseded — rebuilding by hand-port off feat/task-chaining instead of copy/cherry-pick. |
This comment was marked as outdated.
This comment was marked as outdated.
A package.json with scripts but no lockfile and no packageManager/ devEngines field (a typical pnpm-workspace member dir) detected zero node package managers, so script extraction was skipped entirely and the dir reported as "No project detected". Script discovery is now gated on manifest presence, not on a detected node PM — which PM dispatches the scripts is the resolver's runtime job. A manifest-less subdirectory additionally lists the nearest ancestor manifest's scripts when it provably sits inside a JS monorepo (pnpm-workspace.yaml / lerna.json / package.json workspaces), so a workspace member is never met with "No project detected". - detect.rs: gate the parallel extract_tasks on has_local_manifest || workspace_member || with_deno instead of a detected node/deno PM - node.rs: add within_workspace_upwards (workspace-root-aware guard) - files.rs: extract reusable VCS-bounded find_in_ancestors; find_first_upwards now delegates to it Tests: +3 (no-PM-signal headline case, workspace-member subdir, non-workspace negative guard).
Detection only consulted the legacy packageManager field, so a devEngines-only manifest, or a lockfile-less workspace member, surfaced no package manager — info/install then fell back to the wrong tool. Detection now mirrors the resolver's manifest chain: packageManager → devEngines.packageManager → enclosing-workspace lockfile/manifest. The upward walk is workspace-root-aware and VCS-bounded, reusing the same guard as upward script discovery so an unrelated outer-project lockfile is never adopted. - detect.rs: devEngines fallback via detect_pm_from_manifest; new detect_node_pm_upwards for manifest-less / PM-less workspace members - tests: +2 (devEngines-only PM, workspace-member upward PM) Unparseable legacy packageManager still returns no PM (Corepack: no substitution) and still emits the UnparseablePackageManager warning.
e2c39de to
0b41b2f
Compare
`[0.11.0]` was missing two user-facing changes that already merged or land in this branch: - Changed: root Go task name now from the `go.mod` `module` path (commit landed via #27), not the directory name. - Fixed: a new `### Fixed` section for the node-script-discovery decoupling and resolver-PM-chain mirroring in this PR — the "No project detected" pnpm-workspace-member regression.
📝 WalkthroughWalkthroughThe PR enhances Node.js package manager detection and task extraction with workspace-aware ancestry walking. It introduces reusable upward-search infrastructure, adds workspace membership detection, enables PM fallback chains within monorepos, decouples script extraction from PM detection, and validates the new behavior with comprehensive tests. ChangesNode.js workspace-aware package manager and task detection
Possibly related PRs
🚥 Pre-merge checks | ✅ 7 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (7 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
✨ Simplify code
Comment |
Problem
A pnpm-workspace member directory (
package.jsonwithscripts, no local lockfile, nopackageManager/devEngines) reported "No project detected", andrunner run buildfell through to a bogusbun build. Detection gated script extraction on a detected Node PM; the resolver was already smart enough — that asymmetry was the bug.Fix
package.jsonis the Node signal. Gating is now manifest-presence based, applied to the parallelextract_tasks. A manifest-less subdirectory lists ancestor scripts only when it provably sits inside a JS monorepo (workspace-root-aware, VCS-bounded), so an unrelated outer project'spackage.jsonis never silently adopted.packageManager→devEngines.packageManager→ enclosing-workspace lockfile/manifest, sorunner info/runner installfrom a member target the right tool. Corepack semantics preserved: a present-but-unparseable legacypackageManagerstill emits a warning and is not silently superseded bydevEngines(detect_pm_from_manifestshort-circuits toNoneon an unparseable spec — verified, regression testnode::detect_pm_from_manifest_blocks_dev_engines_when_package_manager_unparseable).Shared VCS-bounded ancestor walk extracted into a reusable generic
files::find_in_ancestors.Commits
fix(detect): decouple node script discovery from PM detectionfix(detect): mirror resolver PM chain (devEngines + workspace-upward)changelog: record go.mod task name + node-detection fixesBase:
master. Rebased onto currentmaster(post-#27 merge) —feat/task-chaining, which this was originally stacked on, is now merged. 3 linear commits, no merge commits.Verification
Run against the actual
master-merged tree (2 fix commits rebased onto currentmaster):cargo test: 554 pass, 0 fail, 1 ignored (+5 new detection tests; the 1 ignored is the long-standing env-gated test, unrelated).cargo clippy --all-targets --all-features -- -D clippy::all: clean.cargo fmt --check: clean.dprint check: clean.masterwas conflict-free; zero functional overlap with intervening commits.Notes
CHANGELOG.md[0.11.0]updated: new### Fixedsection for this PR's behavior, plus a### Changedentry for thego.mod-module-path task-name change that landed via Task chaining:run -s/-pchain mode +install <tasks>#27. Not bumping version as 0.11.0 is not published yet.detect.rs,node.rs,files.rs) surfaced no code defects; the only flagged item — the Corepack/unparseable-packageManagerinteraction — was traced to source and confirmed correct.