Consolidate and validate Dependabot updates - #208
Conversation
|
Dependency limit exceeded — report not shown. This pull request scan exceeded the 10,000-dependency limit applied to this scan, so the results are incomplete and may be inaccurate. To avoid reporting false positives, Socket has not posted a report. Upgrade your plan to raise the dependency limit and get complete reports, or view the partial scan in the dashboard. Socket is always free for open source. If this is a non-commercial open source project, contact us to request a free Team account. |
|
CI follow-up: the first run exposed Angular CLI 22's stricter Node floor. A floating Node 24 selector still resolved to the runner's cached 24.13.0, so the Angular matrix entry is now pinned to the locally verified Node 24.18.0. The final GitHub Actions run has all build and audit matrix jobs passing; Aikido and Socket's project report also pass. Cubic's external review is still queued. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 57be582c1f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "@formo/analytics": "^1.35.0", | ||
| "clsx": "^2.1.1", | ||
| "next": "^15.5.22", | ||
| "next": "^16.3.0", |
There was a problem hiding this comment.
After this upgrade, with-crossmint's existing lint script still runs next lint; the same mismatch exists in the newly upgraded with-privy, with-thirdweb, and with-turnkey examples. The Next.js 16 migration guide states that next lint was removed in favor of invoking ESLint or Biome directly, so pnpm lint now exits with an unknown-command error in each of these examples.
Useful? React with 👍 / 👎.
| if (publicClient) { | ||
| await publicClient.waitForTransactionReceipt({ hash: result.value.txHash }); | ||
| } |
There was a problem hiding this comment.
When an Aave supply transaction is mined but reverts, waitForTransactionReceipt returns a receipt whose status is reverted; it does not make this branch fail automatically. Because the returned status is discarded, the code proceeds to emit aave_supply and refresh state as though the operation succeeded; the withdrawal path repeats the same issue. Preserve the previous receipt-status check and surface an error instead of recording reverted transactions as successful.
Useful? React with 👍 / 👎.
| "react-scripts": "5.0.1", | ||
| "viem": "^2.55.8", | ||
| "web-vitals": "^2.1.4" | ||
| "web-vitals": "^6.0.1" |
There was a problem hiding this comment.
When a consumer enables the included metrics example by calling reportWebVitals(console.log), src/reportWebVitals.js still destructures and invokes the removed getCLS, getFID, getFCP, getLCP, and getTTFB exports. With web-vitals 6 these values are undefined, causing an immediate runtime TypeError; update that helper to the current onCLS/onINP/onFCP/onLCP/onTTFB API or retain a compatible package version.
Useful? React with 👍 / 👎.
| "plugins": [ | ||
| "expo-router" | ||
| "expo-router", | ||
| "expo-status-bar", |
There was a problem hiding this comment.
When Expo loads this app configuration for expo start, expo run:*, or prebuild, it attempts to resolve every entry in plugins as a config plugin. expo-status-bar is a runtime UI module and does not provide a config plugin (unlike the adjacent expo-splash-screen package), so configuration evaluation fails before the app can start; keep the existing StatusBar component import, but remove this entry from plugins.
Useful? React with 👍 / 👎.
| "ansi-regex": "^6.2.2", | ||
| "husky": "~8.0.3", | ||
| "lint-staged": "~13.2.3" | ||
| "lint-staged": "~17.3.0" |
There was a problem hiding this comment.
The package still declares support for Node >=20.9.0, but the resolved lint-staged 17.3.0 package declares an engine requirement of Node >=22.22.1. On a supported Node 20 installation, dependency installation therefore produces an engine incompatibility and the Husky pre-commit hook cannot reliably run lint-staged; either retain a Node-20-compatible lint-staged release or raise this workspace's Node engine requirement.
Useful? React with 👍 / 👎.
| rawBalance: usdcSupply.balance.amount.value, | ||
| apy: usdcSupply.apy.formatted, | ||
| rawBalance: String(usdcSupply.balance.amount.value), | ||
| apy: String(usdcSupply.reserve.summary.supplyApy.value), |
There was a problem hiding this comment.
For every nonzero supply rate, supplyApy.value is the raw fractional APY (for example, 0.035 for 3.5%), whereas the previous code used Aave's percentage-formatted value. AaveSupplyCard appends a literal %, so this now displays 0.035% APY instead of 3.5% APY; multiply the raw value by 100 or use the SDK's percentage formatter before passing it to the card.
Useful? React with 👍 / 👎.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
8 issues found and verified against the latest diff
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="with-crossmint/package.json">
<violation number="1" location="with-crossmint/package.json:16">
P3: This migration moves the example to Next.js 16, but the workspace README still documents it as 'a Next.js 15 (App Router) + React 19... project'. Update the README's target-stack description to Next 16 so the documented compatibility notes match the bumped dependency.</violation>
</file>
<file name="with-next-app-router/packages/nextjs/package.json">
<violation number="1" location="with-next-app-router/packages/nextjs/package.json:36">
P2: Declared viem 2.55.10 is not what this workspace installs. The `viem: ^2.49.2` override in with-next-app-router/pnpm-workspace.yaml rewrites the specifier to ^2.49.2 and the lockfile is resolved at 2.53.1, so the intended bump is silently ineffective here while the same version resolves correctly in other workspaces. Regenerate the lockfile (or drop the override/pin consistently) so the locked version matches the declared 2.55.10, since this PR's stated goal is security/supply-chain remediation.</violation>
</file>
<file name="with-metamask/pnpm-workspace.yaml">
<violation number="1" location="with-metamask/pnpm-workspace.yaml:27">
P2: The new override silently downgrades the direct dependency below its declared range: package.json specifies `wagmi: ^3.7.6` but `wagmi@>=3.0.0 <4.0.0: 3.6.1` forces 3.6.1, which doesn't satisfy ^3.7.6, so the installed version never matches the manifest and the broad range permanently caps all future wagmi 3.x updates (Dependabot bumps to 3.7/3.8+ get silently reverted). Pin `wagmi` to `3.6.1` directly in package.json (or add a comment) so the declared specifier reflects reality and future updates aren't silently masked.</violation>
</file>
<file name="with-react/package.json">
<violation number="1" location="with-react/package.json:15">
P2: Bumping web-vitals to ^6.0.1 breaks the existing metric-reporting path in src/reportWebVitals.js. web-vitals v4 removed the legacy `getXXX()` functions (including `getFID`), so the dynamic import in reportWebVitals.js now destructures `getFID` as `undefined` and `getFID(onPerfEntry)` throws a `TypeError: getFID is not a function` whenever a callback is passed (the documented `reportWebVitals(console.log)` usage). The app only avoids the crash today because src/index.js calls `reportWebVitals()` with no argument, so the broken code path is latent but triggered by any real use. I'd recommend either keeping web-vitals on a v2/v3 line that still exports `getFID`, or updating src/reportWebVitals.js to use the new `onINP`/`onCLS`-style API (getFID replaced by `onINP`).</violation>
</file>
<file name="with-react/pnpm-workspace.yaml">
<violation number="1" location="with-react/pnpm-workspace.yaml:27">
P3: The new `shell-quote@<=1.8.4: 1.10.0` override is a strict superset of the adjacent `'shell-quote@>=1.1.0 <=1.8.4': 1.10.0` entry and both pin to the same version, so one of them is redundant and pnpm will match everything with the broader rule. Drop the narrower entry (here and in with-react-native, which has the same duplicate pair) to keep the override block clean.</violation>
</file>
<file name="with-thirdweb/package.json">
<violation number="1" location="with-thirdweb/package.json:19">
P2: The Next.js 16 bump raises the required Node runtime to >=20.9 (per next@16.3.0 engines), but with-thirdweb/README.md still tells users Node.js 18+ is sufficient. Anyone following the README on Node 18.x will hit an engine error and fail to install/start. Update the README's Node requirement to 20.9+ to match the new minimum.</violation>
<violation number="2" location="with-thirdweb/package.json:29">
P2: Version mismatch between `eslint-config-next@16.3.0` and the still-pinned `eslint: ^8.57.1`. `eslint-config-next@16.3.0` declares a peer dependency of `eslint: '>=9.0.0'` (shown in the resolved lockfile entry), so the config is designed for ESLint 9 and its flat config, while this workspace still uses ESLint 8 with a legacy `.eslintrc.json`. The mismatched peer install will leave `pnpm lint` (once it calls ESLint directly) unable to load the Next.js config/plugins correctly. The PR description calls out an ESLint 9 migration as required for this batch, but this workspace wasn't migrated. Consider bumping ESLint to ^9 and migrating the `eslint-config-next`-based config to flat config.</violation>
</file>
<file name="with-react-native/.eslintrc.js">
<violation number="1" location="with-react-native/.eslintrc.js:9">
P2: The `lint` script is `eslint .`, which also lints the project's CommonJS config files (`metro.config.js`, `jest.config.js`, `babel.config.js`) and `jest.setup.js`. This new config only turns on the `jest` environment for the test override, and provides no Node.js environment at all. Per the Expo docs, `eslint-config-expo` only supplies Node globals out of the box in flat config; in legacy config you must opt into the node environment. Without it, `eslint .` will report `no-undef` for `module`, `require`, `process`, and `__dirname` in those files (and `jest.setup.js` additionally uses `require`/`global`/`module` while its override only sets `env: { jest: true }`, not `node`). Consider adding a node environment for the config files and node for `jest.setup.js` so the lint step stays green.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| "@thirdweb-dev/sdk": "^4.0.99", | ||
| "@thirdweb-dev/wallets": "^2.5.39", | ||
| "next": "^15.5.22", | ||
| "next": "^16.3.0", |
There was a problem hiding this comment.
P2: The Next.js 16 bump raises the required Node runtime to >=20.9 (per next@16.3.0 engines), but with-thirdweb/README.md still tells users Node.js 18+ is sufficient. Anyone following the README on Node 18.x will hit an engine error and fail to install/start. Update the README's Node requirement to 20.9+ to match the new minimum.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At with-thirdweb/package.json, line 19:
<comment>The Next.js 16 bump raises the required Node runtime to >=20.9 (per next@16.3.0 engines), but with-thirdweb/README.md still tells users Node.js 18+ is sufficient. Anyone following the README on Node 18.x will hit an engine error and fail to install/start. Update the README's Node requirement to 20.9+ to match the new minimum.</comment>
<file context>
@@ -16,18 +16,18 @@
"@thirdweb-dev/sdk": "^4.0.99",
"@thirdweb-dev/wallets": "^2.5.39",
- "next": "^15.5.22",
+ "next": "^16.3.0",
"react": "^18.3.1",
"react-dom": "^18.3.1"
</file context>
| "use-debounce": "~8.0.4", | ||
| "usehooks-ts": "2.13.0", | ||
| "viem": "2.49.2", | ||
| "viem": "2.55.10", |
There was a problem hiding this comment.
P2: Declared viem 2.55.10 is not what this workspace installs. The viem: ^2.49.2 override in with-next-app-router/pnpm-workspace.yaml rewrites the specifier to ^2.49.2 and the lockfile is resolved at 2.53.1, so the intended bump is silently ineffective here while the same version resolves correctly in other workspaces. Regenerate the lockfile (or drop the override/pin consistently) so the locked version matches the declared 2.55.10, since this PR's stated goal is security/supply-chain remediation.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At with-next-app-router/packages/nextjs/package.json, line 36:
<comment>Declared viem 2.55.10 is not what this workspace installs. The `viem: ^2.49.2` override in with-next-app-router/pnpm-workspace.yaml rewrites the specifier to ^2.49.2 and the lockfile is resolved at 2.53.1, so the intended bump is silently ineffective here while the same version resolves correctly in other workspaces. Regenerate the lockfile (or drop the override/pin consistently) so the locked version matches the declared 2.55.10, since this PR's stated goal is security/supply-chain remediation.</comment>
<file context>
@@ -14,26 +14,26 @@
"use-debounce": "~8.0.4",
"usehooks-ts": "2.13.0",
- "viem": "2.49.2",
+ "viem": "2.55.10",
"wagmi": "2.19.5",
"zustand": "~4.1.5"
</file context>
| # resolve. Keep the Wagmi 3 family on its last buildable compatible set. | ||
| '@wagmi/core@>=3.0.0 <4.0.0': 3.4.2 | ||
| '@wagmi/connectors@>=8.0.0 <9.0.0': 8.0.1 | ||
| 'wagmi@>=3.0.0 <4.0.0': 3.6.1 |
There was a problem hiding this comment.
P2: The new override silently downgrades the direct dependency below its declared range: package.json specifies wagmi: ^3.7.6 but wagmi@>=3.0.0 <4.0.0: 3.6.1 forces 3.6.1, which doesn't satisfy ^3.7.6, so the installed version never matches the manifest and the broad range permanently caps all future wagmi 3.x updates (Dependabot bumps to 3.7/3.8+ get silently reverted). Pin wagmi to 3.6.1 directly in package.json (or add a comment) so the declared specifier reflects reality and future updates aren't silently masked.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At with-metamask/pnpm-workspace.yaml, line 27:
<comment>The new override silently downgrades the direct dependency below its declared range: package.json specifies `wagmi: ^3.7.6` but `wagmi@>=3.0.0 <4.0.0: 3.6.1` forces 3.6.1, which doesn't satisfy ^3.7.6, so the installed version never matches the manifest and the broad range permanently caps all future wagmi 3.x updates (Dependabot bumps to 3.7/3.8+ get silently reverted). Pin `wagmi` to `3.6.1` directly in package.json (or add a comment) so the declared specifier reflects reality and future updates aren't silently masked.</comment>
<file context>
@@ -16,6 +16,15 @@ minimumReleaseAgeExclude:
+ # resolve. Keep the Wagmi 3 family on its last buildable compatible set.
+ '@wagmi/core@>=3.0.0 <4.0.0': 3.4.2
+ '@wagmi/connectors@>=8.0.0 <9.0.0': 8.0.1
+ 'wagmi@>=3.0.0 <4.0.0': 3.6.1
# 1.54.0 imports @x402/{core,evm,svm} subpaths that aren't installable
# here, breaking the webpack build. Hold at the last version that built.
</file context>
| - postcss@8.5.18 | ||
| overrides: | ||
| nanoid@<3.3.17: 3.3.17 | ||
| shell-quote@<=1.8.4: 1.10.0 |
There was a problem hiding this comment.
P3: The new shell-quote@<=1.8.4: 1.10.0 override is a strict superset of the adjacent 'shell-quote@>=1.1.0 <=1.8.4': 1.10.0 entry and both pin to the same version, so one of them is redundant and pnpm will match everything with the broader rule. Drop the narrower entry (here and in with-react-native, which has the same duplicate pair) to keep the override block clean.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At with-react/pnpm-workspace.yaml, line 27:
<comment>The new `shell-quote@<=1.8.4: 1.10.0` override is a strict superset of the adjacent `'shell-quote@>=1.1.0 <=1.8.4': 1.10.0` entry and both pin to the same version, so one of them is redundant and pnpm will match everything with the broader rule. Drop the narrower entry (here and in with-react-native, which has the same duplicate pair) to keep the override block clean.</comment>
<file context>
@@ -17,22 +17,28 @@ minimumReleaseAgeExclude:
- postcss@8.5.18
overrides:
+ nanoid@<3.3.17: 3.3.17
+ shell-quote@<=1.8.4: 1.10.0
+ 'fast-uri@>=3.0.0 <3.1.5': 3.1.5
+ 'fast-uri@>=4.0.0 <4.1.2': 4.1.2
</file context>
|
Runtime smoke follow-up (commit
Runtime-only fixes found during this pass:
The affected workspaces pass frozen installs, production builds, and production audits with no known vulnerabilities. No interactive browser backend was available in this session, so wallet-button interaction was not exercised; the verification covered live servers, rendered HTTP output, framework bundles, and real SDK/provider initialization. |
There was a problem hiding this comment.
All reported issues were addressed across 8 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
There was a problem hiding this comment.
1 issue found across 43 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="with-next-app-router/package.json">
<violation number="1" location="with-next-app-router/package.json:37">
P3: The Node engine bump to ">=20.17.0" leaves the example README's documented prerequisite ("Node.js >= 18.18.0") stale, so users running a Node version between 18.18 and 20.17 would be told the example satisfies requirements that package.json no longer allows. Update the README Prerequisites line to match the new engine (e.g. "Node.js >= 20.17.0").</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| "packageManager": "pnpm@11.1.2", | ||
| "engines": { | ||
| "node": ">=20.9.0" | ||
| "node": ">=20.17.0" |
There was a problem hiding this comment.
P3: The Node engine bump to ">=20.17.0" leaves the example README's documented prerequisite ("Node.js >= 18.18.0") stale, so users running a Node version between 18.18 and 20.17 would be told the example satisfies requirements that package.json no longer allows. Update the README Prerequisites line to match the new engine (e.g. "Node.js >= 20.17.0").
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At with-next-app-router/package.json, line 37:
<comment>The Node engine bump to ">=20.17.0" leaves the example README's documented prerequisite ("Node.js >= 18.18.0") stale, so users running a Node version between 18.18 and 20.17 would be told the example satisfies requirements that package.json no longer allows. Update the README Prerequisites line to match the new engine (e.g. "Node.js >= 20.17.0").</comment>
<file context>
@@ -30,11 +30,11 @@
"packageManager": "pnpm@11.1.2",
"engines": {
- "node": ">=20.9.0"
+ "node": ">=20.17.0"
},
"dependencies": {
</file context>
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Summary
Compatibility decisions
Several bot-proposed majors were unsafe as submitted and are intentionally held on supported combinations:
accountspackage importSecurity review
Production audits have no high/critical findings in 15 of 19 workspaces. Remaining high findings are upstream packages for which the advisory's patched version is not published:
bigint-buffer@1.1.5through Dynamic/Crossmint (advisory claims1.1.6; npm has no such release)image-size@2.0.2through Expo/Metro and Crossmint (advisory claims2.0.3; npm has no such release)svgo@1.3.2; forcing SVGO 2 breaksreact-scripts, so removal requires a separate CRA migrationAll other actionable high-severity transitive findings were pinned to patched releases.
Local verification
git diff --checkpasses and staged changes were scanned for secretsThe residual upstream advisories remain visible during review.
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.