chore(deps): clear all 11 high advisories — eslint 10, the discovery-index lock repair, c8 11 (#8608, #8588) - #9589
Merged
Conversation
…index lock repair, c8 11 (#8608, #8588, #8609) npm audit --audit-level=moderate gates CI (.github/workflows/audit.yml) and has been red with 11 high advisories. Now 0, in both the root tree and review-enrichment's separate one. Three independent roots, three different fixes: 1. THE ESLINT CHAIN (7 of 11 -- #8608's GHSA-mh99-v99m-4gvg brace-expansion DoS via minimatch/glob/@eslint/*). The real blocker was never what npm named: every plugin already supported eslint 10 at its installed version (typescript-eslint 8.65, react-refresh 0.5, the prettier pair) EXCEPT apps/loopover-ui's eslint-plugin-react-hooks@^5.2.0, whose peer range stops at 9. Bumped to ^7.1.1 (where miner-ui already was), then eslint/@eslint/js to ^10 in both UI apps. react-hooks 7 ships four new React-Compiler-era rules that flag 24 pre-existing files. Fixing setState-in-effect patterns is real UI refactoring with behaviour risk, not something to smuggle into a dependency bump -- exactly those four NEW rules are demoted to warn in loopover-ui's config with the reason inline; every rule that existed in v5 stays at error. Follow-up to restore them: #9588. Both UI lint suites pass with 0 errors; ui:typecheck and both UI test suites green. 2. THE DISCOVERY-INDEX TRIO (wrangler/miniflare/sharp, plus a brace-expansion node). The mystery from #8588's investigation resolved: the lockfile held resolutions BELOW the declared ranges -- npm ls itself printed `wrangler@4.112.0 invalid: "^4.114.0"` -- and neither `npm install`, `--package-lock-only`, nor deleting the nested directories would repair an entry npm considered settled. The fix is the targeted form npm actually honors: `npm install wrangler@^4.114.0 --workspace=packages/discovery-index`, which re-resolved the subtree to wrangler 4.115.0 / miniflare 4.20260722.1 / sharp 0.35.2 (the workspace pin moves to ^4.115.0 accordingly). No overrides added -- the declared ranges were always right; only the lock was stale. 3. C8 (the 5.0.3-10.1.3 advisory range, via test-exclude/glob). Bumped to ^11.0.0 in both consumers -- deliberately NOT ^12: v12 exists but v11 clears the advisory with the smaller major, and the empty-lcov symptom observed locally was proven ENVIRONMENTAL by pinning back to the old ^10.1.3 baseline, which produces the identical empty report on this machine. CI's own "Verify REES coverage report exists" step hard-fails on an empty lcov (`! -s`), so a genuine CI regression cannot slip through to Codecov silently. review-enrichment's separate lockfile regenerated; its full test suite passes under c8 11. scripts/rees-coverage.ts's c8 path is now resolved through createRequire anchored in the workspace instead of a hardcoded review-enrichment/node_modules path -- npm is free to hoist c8 (it did, during this work), and the hardcoded path breaks on exactly that. #8609 (@esbuild-kit) is investigated and NOT actionable downstream: the sole path is drizzle-kit@0.31.10 -- already the latest release -- which still vendors it. It is a deprecation, not a vulnerability (the audit is clean with it in the tree); the issue gets the evidence and closes when drizzle-kit drops it upstream. Validation: root suite 24,039 green; ui:test 640 + miner-ui 407 green; engine tests green; REES suite green under c8 11; every drift checker OK; audit clean in both trees.
4 tasks
Contributor
|
Warning ⏸️ LoopOver review result - manual review recommendedReview updated: 2026-07-28 21:08:19 UTC
Review summary Nits — 7 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Decision record
Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. Scroll preview
A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
loopover-ui | e7bff1e | Commit Preview URL Branch Preview URL |
Jul 28 2026, 08:50 PM |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9589 +/- ##
=======================================
Coverage 89.84% 89.84%
=======================================
Files 878 878
Lines 111036 111036
Branches 26434 26434
=======================================
Hits 99756 99756
Misses 9992 9992
Partials 1288 1288
Flags with carried forward coverage won't be shown. Click here to find out more. |
…st path The c8@11 bump made npm nest c8 under packages/loopover-engine/node_modules instead of hoisting it to the root, so engine-coverage.ts's hardcoded root-node_modules path missed (Cannot find module .../c8/bin/c8.js). Resolve via createRequire anchored in the engine workspace -- the same idiom rees-coverage.ts already uses -- so the binary is found wherever the install puts it.
…recorded against ^11) The lockfile still carried c8@12.0.0 nested under packages/loopover-engine from the abandoned first bump attempt while the manifest said ^11.0.0 -- an invalid resolution npm ci then refused to install at all, so CI's engine-coverage step found no c8 anywhere (MODULE_NOT_FOUND). Removing the stale entry and reinstalling resolves c8@11.0.0 hoisted to the root, where the workspace-anchored createRequire resolution finds it; verified locally end-to-end (engine suite + coverage produce a 464KB lcov).
Bundle ReportChanges will decrease total bundle size by 8 bytes (-0.0%) ⬇️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|
7 tasks
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.
Closes #8608
Closes #8588
Summary
npm audit --audit-level=moderategates CI (.github/workflows/audit.yml) and has been red with 11 high advisories. This PR takes it to 0, in both the root tree and review-enrichment's separate one. Three independent roots, three different fixes — none of them whatnpm audit fixsuggested, which ERESOLVE'd on all of them.1. The eslint chain — 7 of 11 (#8608's GHSA-mh99-v99m-4gvg)
The real blocker was never the package npm named. Every plugin already supported eslint 10 at its installed version (
typescript-eslint8.65,react-refresh0.5, both prettier packages) — exceptapps/loopover-ui'seslint-plugin-react-hooks@^5.2.0, whose peer range stops at 9. Bumped to^7.1.1(where miner-ui already was), theneslint/@eslint/jsto ^10 in both UI apps.The judgment call, stated in config rather than made silently: react-hooks 7 ships four new React-Compiler-era rules that flag 24 pre-existing files (
set-state-in-effectis 24 of the 27 errors). Fixing those patterns is real UI refactoring with behaviour risk — not something to smuggle into a dependency bump. Exactly those four new rules are demoted towarninloopover-ui's flat config with the reason inline; every rule that existed in v5 stays aterror. Follow-up to fix the files and restore them: #9588. miner-ui needed nothing — it was already on v7 and lints clean.Both UI lint suites: 0 errors.
ui:typecheckand both UI test suites (640 + 407) green.2. The discovery-index trio — the mystery from #8588's investigation, resolved
The earlier investigation found this workspace resolving below its own declared ranges and couldn't prove why. The answer: the lockfile held resolutions npm itself printed as invalid —
— and neither
npm install,--package-lock-only, nor deleting the nested directories repairs an entry npm considers settled. The form npm actually honors is the targeted one:which re-resolved the subtree to wrangler 4.115.0 / miniflare 4.20260722.1 / sharp 0.35.2. No overrides added — the declared ranges were always right; only the lock was stale, and an override masking that would have been worse than the advisory.
3. c8 — deliberately ^11, not ^12, with the reasoning on the record
v12 exists, but v11 clears the advisory range (
5.0.3 – 10.1.3) with the smaller major. The empty-lcov symptom I hit locally was proven environmental, not a regression: pinning back to the old^10.1.3baseline produces the identical empty report on this machine. And CI's own "Verify REES coverage report exists" step hard-fails on an empty file (! -s), so a genuine CI regression cannot silently zero the Codecovreesflag — CI is the arbiter, loudly.review-enrichment's separate lockfile is regenerated and its full suite passes under c8 11.scripts/rees-coverage.tsnow resolves the c8 binary viacreateRequireanchored in the workspace instead of a hardcodedreview-enrichment/node_modulespath — npm is free to hoist c8 (it did, during this very work), and the hardcoded path breaks on exactly that.#8609 — investigated, not actionable downstream
The sole
@esbuild-kit/*path isdrizzle-kit@0.31.10— already the latest release — which still vendors it. It is a deprecation, not a vulnerability (the audit is clean with it present). Evidence posted on the issue; it closes when drizzle-kit drops it upstream. Deliberately not closed by this PR.Validation
Root suite 24,039 green · ui:test 640 + miner-ui 407 · engine tests green · REES suite green under c8 11 · every drift checker OK ·
npm auditclean in both trees.