fix(miner): tighten the @loopover/engine dependency to ^2.0.0#5729
Merged
Conversation
lib/deny-hooks.js imports DEFAULT_DENY_RULES from @loopover/engine -- an export that only exists starting in engine 2.0.0. The miner-v1.0.0 release's own packed-tarball smoke test (a real standalone `npm install`, outside the monorepo workspace) caught this: with the dependency declared as "*", a fresh install resolved the currently-published engine 1.0.0 and crashed with SyntaxError: The requested module '@loopover/engine' does not provide an export named 'DEFAULT_DENY_RULES'. The "*" pin traced back to an earlier fix reverting a release-please speculative cross-bump (engine 2.0.0 wasn't published yet at the time, so a tight ^2.0.0 pin would have failed npm ci with ETARGET). Now that engine 2.0.0 is actually published, ^2.0.0 is both installable and correctly expresses miner's real requirement.
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5729 +/- ##
=======================================
Coverage 95.06% 95.06%
=======================================
Files 581 581
Lines 46179 46179
Branches 14811 14811
=======================================
Hits 43901 43901
Misses 1517 1517
Partials 761 761
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
loopover-orb
Bot
added
the
gittensor:bug
JSONbored
added a commit
that referenced
this pull request
Jul 14, 2026
release-please's regeneration of this branch (cutting v2.0.0 for the CLI binary rename) silently reverted the @loopover/engine dependency from the ^2.0.0 constraint landed in #5729 back to "*", removing semver protection -- flagged by the repo's security scanner on this PR. "*" would silently accept any future engine version, including a compromised publish or a major version that removes DEFAULT_DENY_RULES again (the export miner's own lib/deny-hooks.js genuinely requires as of engine 2.0.0). Also fixes test/unit/miner-cli.test.ts's two hardcoded version assertions ("1.0.0"), stale against this cut's real 2.0.0 (a genuine breaking change: the CLI binary rename).
JSONbored
added a commit
that referenced
this pull request
Jul 14, 2026
* chore(release): cut miner v2.0.0 * chore(release): sync package-lock.json * fix(miner): restore the ^2.0.0 engine dependency constraint release-please's regeneration of this branch (cutting v2.0.0 for the CLI binary rename) silently reverted the @loopover/engine dependency from the ^2.0.0 constraint landed in #5729 back to "*", removing semver protection -- flagged by the repo's security scanner on this PR. "*" would silently accept any future engine version, including a compromised publish or a major version that removes DEFAULT_DENY_RULES again (the export miner's own lib/deny-hooks.js genuinely requires as of engine 2.0.0). Also fixes test/unit/miner-cli.test.ts's two hardcoded version assertions ("1.0.0"), stale against this cut's real 2.0.0 (a genuine breaking change: the CLI binary rename). --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: JSONbored <49853598+JSONbored@users.noreply.github.com>
4 tasks
JSONbored
added a commit
that referenced
this pull request
Jul 14, 2026
…anges (#5740) release-please's node-workspace plugin defaults to always-link-local: true, which force-rewrites every workspace-internal dependency's semver range on every regeneration of a release branch -- even when the current range already satisfies the sibling's version. This has repeatedly clobbered deliberate, manually-set constraints on @loopover/miner's and @loopover/mcp's @loopover/engine dependency back to a bare "*" (most recently caught by the repo's security scanner on #5730, PR #5729 before that), and separately generated a string of "empty" release PRs (mcp-v0.8.1, mcp-v1.0.1, miner-v2.0.1) that exist purely to speculatively cross-bump a dependency range ahead of the sibling's actual publish, with no real content of their own. Setting always-link-local: false (a documented top-level manifest option, confirmed against release-please's own JSON schema) makes the plugin only touch a workspace dependency when the CURRENT range no longer covers the sibling's version -- i.e. only for a genuine breaking change, which is exactly when a deliberate, manually-verified bump is warranted anyway (the judgment call this session has been making by hand every time this came up). Also fixes apps/gittensory-ui/src/lib/mcp-package.ts's MCP_PACKAGE_KNOWN_LATEST_VERSION, stale against mcp's real just-published 0.9.0 (unrelated to the config change, but blocking this branch's own gate via ui:version-audit).
JSONbored
added a commit
that referenced
this pull request
Jul 14, 2026
…3.0.0 cut - packages/loopover-miner/expected-engine.version: same recurring drift as the v2.0.0/v2.0.1 cuts, bumped to 3.0.0. - packages/loopover-miner/docs/env-reference.md: the Phase 5 directory-rename commit (#5743) missed regenerating this one doc's title. - test/unit/routes-focus-manifest.test.ts: hardcoded the pre-rename apps/gittensory-ui/ path in two wantedPaths assertions; the real .loopover.yml already correctly says apps/loopover-ui/. - packages/loopover-miner/package.json: tightened @loopover/engine from ^2.0.0 to ^3.0.0. On this branch specifically, engine's own package.json is already 3.0.0 but miner's declared range isn't (that update rides on miner's own release), so npm resolves a stale published 2.0.0 as a non-hoisted nested copy for miner -- which the doctor engine-version-skew check (and 3 real test files depending on it) correctly flags as broken. Same judgment call as #5729: miner's own source doesn't touch anything engine 3.0.0 removed (the Phase 4/5 breaking changes are CLI binary/tool names and directory paths, not engine's exported JS API), so tightening the range here is safe. Also updates the 2 tests that assert the literal fallback range string. - apps/loopover-ui/src/routeTree.gen.ts: TanStack Router's own regeneration, unrelated to the above -- included as-is since it's a generated file now back in sync with the real (still-unrenamed) route source file.
JSONbored
added a commit
that referenced
this pull request
Jul 14, 2026
* chore(release): cut engine v3.0.0 * chore(release): sync package-lock.json * fix: sync generated artifacts and cross-package refs for the engine v3.0.0 cut - packages/loopover-miner/expected-engine.version: same recurring drift as the v2.0.0/v2.0.1 cuts, bumped to 3.0.0. - packages/loopover-miner/docs/env-reference.md: the Phase 5 directory-rename commit (#5743) missed regenerating this one doc's title. - test/unit/routes-focus-manifest.test.ts: hardcoded the pre-rename apps/gittensory-ui/ path in two wantedPaths assertions; the real .loopover.yml already correctly says apps/loopover-ui/. - packages/loopover-miner/package.json: tightened @loopover/engine from ^2.0.0 to ^3.0.0. On this branch specifically, engine's own package.json is already 3.0.0 but miner's declared range isn't (that update rides on miner's own release), so npm resolves a stale published 2.0.0 as a non-hoisted nested copy for miner -- which the doctor engine-version-skew check (and 3 real test files depending on it) correctly flags as broken. Same judgment call as #5729: miner's own source doesn't touch anything engine 3.0.0 removed (the Phase 4/5 breaking changes are CLI binary/tool names and directory paths, not engine's exported JS API), so tightening the range here is safe. Also updates the 2 tests that assert the literal fallback range string. - apps/loopover-ui/src/routeTree.gen.ts: TanStack Router's own regeneration, unrelated to the above -- included as-is since it's a generated file now back in sync with the real (still-unrenamed) route source file. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: JSONbored <49853598+JSONbored@users.noreply.github.com>
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
1 participant
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.
Summary
Miner's already-merged v1.0.0 release (#5712) declared
\"@loopover/engine\": \"*\"— too loose.lib/deny-hooks.jsimportsDEFAULT_DENY_RULESfrom@loopover/engine, an export that only exists starting in engine 2.0.0. The miner-v1.0.0 publish pipeline's own packed-tarball smoke test (a real standalonenpm install, outside the monorepo workspace) caught it: with*, a fresh install resolved the then-current published engine 1.0.0 and crashed withSyntaxError: The requested module '@loopover/engine' does not provide an export named 'DEFAULT_DENY_RULES'.The loose pin traced back to an earlier fix reverting a release-please speculative cross-bump — engine 2.0.0 wasn't published yet at the time, so a tight
^2.0.0pin would have failednpm ciwithETARGET. Engine 2.0.0 is published now, so^2.0.0is both installable and correctly expresses miner's real requirement.Test plan
npm run test:miner-pack) locally — now passes cleanly against the corrected pinnpm run test:cigreen end-to-endnpm audit --audit-level=moderatecleantest/unit/miner-status.test.ts's hardcoded"*"fallback-value assertions to"^2.0.0", matching the corrected declaration