Harper auto-resolution silently tests the published npm package when the consumer doesn't declare harper
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- node.js, typescript
- Domain
- testing-qa, tooling
Research direction
Start by locating getHarperScript and the package manifest, then reproduce the documented integration test command without HARPER_INTEGRATION_TEST_INSTALL_SCRIPT. Trace which resolution branch selects the installed harper package and compare it with the local dist fallback. Done means an undeclared harper dependency no longer silently selects the published package, with the relevant integration behavior covered or clearly reported.
Written by the indexing model from the issue text.
Description
What happened
Running npm run test:integration -- integrationTests/server/v1-gateway.test.ts locally in the harper core repo (without HARPER_INTEGRATION_TEST_INSTALL_SCRIPT, which only CI sets) silently ran the suite against [email protected] from the npm registry instead of the repo's freshly built dist/. Every test failed with 404s/401s because the published binary predates the feature under test — nothing indicated the wrong binary was in play, and the misdiagnosis cost hours.
Why
The README documents resolution step 3 as:
Auto-resolved from a
harperpackage installed as a project dependency
and harper is correctly declared as a peerDependency (^5.0.0) — but npm ≥7 auto-installs peerDependencies. A consumer that never declares harper (the core repo itself, or any component repo that forgot) still ends up with [email protected] hoisted into its node_modules, and getHarperScript step 3 resolves it:
$ npm ls harper # in HarperFast/harper — which declares no harper dep
[email protected]
└─┬ @harperfast/[email protected]
└── [email protected] # npm auto-installed to satisfy the peer range
The auto-install defeats the documented "project dependency" intent, and step 4 (cwd/ancestor dist/bin/harper.js — the fallback that would find the local build) is never reached.
Candidate fixes
peerDependenciesMeta: { harper: { optional: true } }(preferred): npm stops auto-installing the peer. Consumers that declare harper resolve exactly as documented; consumers that don't fall through to the cwd/ancestordistfallback or get the existing clear "Harper CLI script not found" error telling them their options. Behavior change only for repos that were (likely unknowingly) leaning on the auto-installed registry copy.- Prefer cwd/ancestor
dist/bin/harper.jsovernode_moduleswhen both exist (swap steps 3↔4 precedence): fixes the harper source tree, and is a no-op for component repos (whose owndist/is not a harper build). Slightly riskier for unusual directory layouts.
Note that resolving step 3 "from the project instead of the harness module" does not fix this — npm hoists the auto-installed peer into the consumer's root node_modules, so a cwd-based resolve finds the same wrong copy.
Regardless of direction, observability for the resolution decision is being proposed separately (log the resolved path + warn when node_modules/harper wins while a cwd dist/bin/harper.js exists).
🤖 Filed with Claude Code on behalf of @heskew
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from HarperFast/integration-testing
-
setupHarperWithFixture overwrites ctx.harper, dropping pre-set hostname (breaks multi-node add_node)Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 3/5 1-2 days Newbie friendliness 74/100
-
A listener on all interfaces silently receives a test node's connections on macOS; the conflict canary cannot see itPossibly taken @dawsontoth claimed this 6 days ago. Open
HarperFast/integration-testing#38 · 1 comment · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
All issues in HarperFast/integration-testing
Similar issues
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
lingdojo/kana-dojo#31666 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Bug: lockTtlSeconds / lockHeartbeatIntervalSeconds accept non-positive and non-finite valuesPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
CopilotKit/CopilotKit#7618 · 1 comment ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
wimpysworld/sidra#287 ·
Maintainers usually reply within 1 day
-
bug ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sleeyax/paseo-plugins#112 ·
Maintainers usually reply within 2 days