chore(deps): update dependencies to latest - #847
Merged
Conversation
TypeScript 7 breaks the build in these three examples: - svelte: svelte-preprocess calls ts.convertCompilerOptionsFromJson, which TS 7 no longer exposes. - vue: vue-tsc resolves typescript/lib/tsc, which TS 7 does not export. - nextjs15: Next 15 cannot read the "@/*" tsconfig path alias under TS 7. examples/nextjs runs Next 16 and builds fine on TS 7, so it keeps it.
🦋 Changeset detectedLatest commit: a814018 The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
✅ E2E Dev Smoke — passing
4 passed · 0 failed · 0 skipped · 28s |
Contributor
E2E Examples — all passedAll examples passed in the latest run. |
Contributor
E2E Playground results
Details
📥 Download full HTML report (open the run → Artifacts → |
3 tasks
0.28.0 breaks the Vite dev server. It injects the bare specifier "vite-plugin-node-polyfills/shims/process" into source files of packages/widget, packages/widget-checkout and packages/widget-provider-transak, none of which declare the plugin, so pnpm's isolated layout cannot resolve it: [vite] (client) Pre-transform error: Failed to resolve import "vite-plugin-node-polyfills/shims/process" from "../widget/src/pages/TransactionDetailsPage/TransactionDetailsPage.tsx". 63 such errors, and all four dev smoke tests fail. Production builds are unaffected, which is why the playground build and every example E2E job stayed green while dev mode was broken. The export maps, shim files and declared dependencies are identical between 0.26.0 and 0.28.0, and both emit the same specifier, so this is a behavioural regression in the plugin. Keeping Vite at 8.2.1 and moving only the plugin back to 0.26.0 gives zero pre-transform errors, which isolates the cause.
Aikido flagged sharp@0.34.5 (GHSA-f88m-g3jw-g9cj, HIGH): libvips flaws affecting anything that decodes untrusted GIF/TIFF/VIPS input. next@15.5.23 in examples/nextjs15 still resolves the 0.34.x line, while @dynamic-labs already pulled 0.35.x, so the tree carried three copies. The floor collapses all of them to a single sharp@0.35.3 — the version the advisory recommends — and matches how the other security floors in this file are expressed (axios, zod, abitype).
The old note said vite-plugin-env-compatible was the problem and that swapping in vite-plugin-node-polyfills would fix it. That is no longer true under Vite 8. The Dynamic SDK reads a bare `process` global (nextTick/versions/emit) and imports `buffer/index.js`, so it does need Node shims. But vite-plugin-node-polyfills, while advertising a Vite 8 peer range, aliases its own shims by bare specifier, and its exports map still carries legacy trailing-slash keys that resolve to files. Rolldown rejects those: Expecting folder to folder mapping. ".../vite-plugin-node-polyfills/package.json" should end with "/" Verified on both 0.26.0 and 0.28.0 (identical exports maps), in `vite build` and again in dev dependency pre-bundling. Upstream fixes are open but unreleased: davidmyersdev/vite-plugin-node-polyfills#161 and #154, with #158 and #140 reporting this exact error. Dropping the plugin entirely gets the example to build once `buffer` is a real dependency — the SDK's own polyfills.js assigns window.global/window.Buffer — but the free `process` global remains undefined at runtime. The @dynamic-labs v5 upgrade itself is sound: it type-checks and bundles. Only the browser polyfill setup is blocked.
Merged
3 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.
Which Linear task is linked to this PR?
Routine dependency maintenance — no Linear task.
Why was it implemented this way?
Ran
pnpm up -r -Lacross the workspace, then reverted the classes of change that a blanket--latestsweep gets wrong, added one security floor, and finished withpnpm regen.Reverted from the blanket sweep
>=floor ranges kept as floors.pnpm up -Lrewritesviem: ">=2.52.0"→"^2.55.19",etc. Those floors are deliberate — they pair with the
pnpm.overridesentries inpnpm-workspace.yamlthat enforce the single-copy invariants inCLAUDE.md, and narrowing themnarrows what dedupes against a consumer's own copy. Restoring them also reverted two majors that
would otherwise have ridden in unannounced, because the overrides already resolve them high:
bs58>=4.0.1→^6.0.0(2 sites)@react-native-async-storage/async-storage>=2.2.0→^3.1.1(rootoptionalDependencies)nextleft alone —^16inexamples/nextjsand^15inexamples/nextjs15.ioredisleft at^5.11.1. The rootoptionalDependenciesentry exists only to satisfyunstorage/nitropack, andunstorage@1.17.5declares the optional peer asioredis: ^5.10.1.Moving to
6.0.0buys a peer mismatch and a second copy.@changesets/cli/@changesets/changelog-githubleft at v2 / v0.7 — the v3 migration needschangesets/action@v2in lockstep and lands in a separate PR.vite-plugin-node-polyfillsheld at 0.26.0 (13 declarations). 0.28.0 broke the Vite devserver — see below. Caught by the
Dev smokeCI check on this PR.peerDependencieswere not touched by the sweep (verified —pnpm updoes not rewrite them), sono consumer-facing peer range was tightened.
Added: a
sharpsecurity floorAikido flagged
sharp@0.34.5(GHSA-f88m-g3jw-g9cj, HIGH) — libvips flaws affecting anythingthat decodes untrusted GIF/TIFF/VIPS input.
next@15.5.23inexamples/nextjs15still resolvesthe 0.34.x line while
@dynamic-labsalready pulled 0.35.x, so the tree carried three copies.Added
sharp: ">=0.35.0"topnpm.overrides, matching how the other security floors in that fileare expressed (
axios,zod,abitype). That collapses all three to a singlesharp@0.35.3— the version the advisory recommends.
pnpm auditadvisories drop 36 → 35 with thesharpentrygone, and
examples/nextjs15(the affected consumer) still builds and renders 3/3.Majors taken
motionpackages/widget,packages/widget-checkoutreact-intersection-observerpackages/widget@dynamic-labs/*(7 pkgs)examples/dynamictypescriptexamples/nextjsonlyMotion 13's only breaking change is dropping the optional
@emotion/is-prop-validintegration;the repo has no
styled(m.*)components, so there was nothing to migrate.react-intersection-observer11 is an internal observer-lifecycle rewrite with nouseInViewAPI change.
TypeScript 7 held back in three examples
TS 7 was intended for all four examples still on TS 6, but it breaks three of them:
svelte-preprocesscallsts.convertCompilerOptionsFromJson, removed in TS 7vue-tscresolvestypescript/lib/tsc, no longer exported in TS 7@/*tsconfig path alias under TS 7examples/nextjsruns Next 16 and builds cleanly on TS 7, so it takes the bump. The other threestay on
^6.0.3.vite-plugin-node-polyfills0.28.0 breaks dev modeThe first CI run on this PR failed exactly one check —
Dev smoke— with 63 of these:0.28.0 injects the bare specifier
vite-plugin-node-polyfills/shims/processinto source files ofpackages/widget,packages/widget-checkoutandpackages/widget-provider-transak— none ofwhich declare the plugin. Under pnpm's isolated layout it is not resolvable from those packages,
so the dev server serves a broken app and all four dev smoke tests fail.
Bisected: the export maps, shim files, and dependencies are byte-identical between 0.26.0 and
0.28.0, and the emitted specifier is the same, so this is a behavioural regression in the plugin.
Holding Vite at the new 8.2.1 and moving only the plugin back to 0.26.0 gives 0 pre-transform
errors, which isolates the plugin as the cause.
Production builds are unaffected — which is why
Build playgroundand all 17 E2E example jobsstayed green while dev mode was broken. That is precisely the gap
e2e-playground-dev.ymlexiststo cover.
pnpm regenpackageManagermovespnpm@11.17.0→pnpm@11.22.0— that iscorepack use pnpm@latestinside
pnpm regen, not a hand edit. CI resolves pnpm from that field viapnpm/action-setup,so it follows automatically.
pnpm regenregenerates the lockfile from the existing ranges — it does not move^15to^16.examples/nextjs15therefore stays on Next 15.Single-copy invariants (
CLAUDE.md)pnpm dedupecollapsed awagmi3.7.4 / 3.7.6 split that the bump introduced via peerresolution on
packages/widget-provider-ethereum:wagmi2.19.5remains as a pre-existing transitive via@privy-io/react-auth→x402, also present onmain.@lifi/sdk@lifi/typesviemVisual showcase (Screenshots or Videos)
All 17
status: activeexamples ine2e/examples.jsonbuild, serve, and pass the Playwrightwidget-smoke suite (widget container renders with the Exchange heading, Settings view opens,
From/To tokens are selectable).
Not covered by render:
dynamic,deposit-flow, andnuxtarestatus: brokenin theregistry at baseline and are skipped by the harness. So the
@dynamic-labs/*v5 major isverified by
check:typesand a cleanvite buildonly, not by a render.dynamicstays broken, but itsbrokenReasonis now correct. The old note blamedvite-plugin-env-compatibleand prescribed swapping invite-plugin-node-polyfills; that nolonger works under Vite 8. The plugin advertises a Vite 8 peer range but aliases its own shims by
bare specifier, and its exports map still carries legacy trailing-slash keys that resolve to
files, which rolldown rejects with
Expecting folder to folder mapping. Reproduced on both0.26.0 and 0.28.0 (their exports maps are identical), in
vite buildand again in dev dependencypre-bundling. Upstream fixes are open but unreleased —
#161 and
#154, with
#158 and
#140 reporting this
exact error. Dropping the plugin gets the example to build once
bufferis a real dependency (theSDK's own
polyfills.jsassignswindow.global/window.Buffer), but the freeprocessglobalis still undefined at runtime. The v5 upgrade itself is sound; only the browser polyfill setup is
blocked.
Verification
pnpm buildpnpm check(Biome)pnpm check:typespnpm check:circular-depspnpm dedupe --checkpnpm install --frozen-lockfilepnpm test:examplespnpm e2e:dev(dev-mode smoke)pnpm audit—sharpadvisory@lifi/widgettests@lifi/widget-providertests@lifi/widget-provider-trontestsPre-existing, not from this PR
@lifi/widget-checkout: 38 failing tests (7 files). Byte-identical on cleanorigin/main— same count, same
TypeError: Cannot read properties of undefined (reading 'setItem')fromthe zustand
persistmiddleware, atzustand@5.0.14there and5.0.15here. Verified in aseparate baseline worktree at
7a6dfb204.@lifi/widget-lighthas no test files, sovitest runexits 1 there. Documented inCLAUDE.md.changeset statusname-collision warnings (connectkit,vue,react-routerexamplepackages shadowing their own deps) — identical on
main, only the version strings differ.Checklist before requesting a review