fix(prolink): export createProlinkUrl from Node builds - #369
Open
memosr wants to merge 1 commit into
Open
Conversation
Collaborator
🟡 Heimdall Review Status
|
createProlinkUrl was re-exported from the browser prolink build but not from index.node.ts, so importing it from @base-org/account/prolink in Node threw a SyntaxError. The root index.node.ts also did not re-export the prolink utilities, unlike src/index.ts. createProlinkUrl.ts has no imports and no compression dependency, so this cannot pull the brotli-wasm path into the Node bundle. Adds a regression test to the existing createProlinkUrl.test.ts. Addresses base#368
memosr
force-pushed
the
fix/prolink-node-export
branch
from
August 16, 2026 21:46
bcf5174 to
c9bccdc
Compare
Author
|
Rebased onto current master and signed the commit. CONTRIBUTING requires signed commits and mine wasn't when I opened this — my oversight, now fixed. Still present on master: neither Title follows Conventional Commits ( |
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
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
createProlinkUrlis unreachable from Node. It is re-exported from the browser prolink build but not from the Node one, and the root Node entrypoint does not re-export the prolink utilities at all. This makes the import shown in the docs fail on Node.Addresses item 1 of #368.
Root cause
exports["./prolink"].noderesolves todist/interface/public-utilities/prolink/index.node.js, and that file never re-exportedcreateProlinkUrl:src/interface/public-utilities/prolink/index.ts:207-208hasexport { createProlinkUrl } from './createProlinkUrl.js';src/interface/public-utilities/prolink/index.node.tsdoes notThe same asymmetry exists one level up:
src/index.ts:50-58exportscreateProlinkUrl,encodeProlink,decodeProlinksrc/index.node.tsexports none of themConfirmed against the published artifact, not just the source.
@base-org/account@2.5.7/dist/interface/public-utilities/prolink/index.node.jscontains onlyencodeProlinkanddecodeProlink.Changes
src/interface/public-utilities/prolink/index.node.tsre-exportscreateProlinkUrl, matchingindex.ts.src/index.node.tsre-exports the prolink utilities from./interface/public-utilities/prolink/index.node.js, so the root Node entrypoint matches the browser root.createProlinkUrl.test.ts, which already imported from./index.node.js. No new test file.createProlinkUrl.tshas zero imports. It builds a URL withURL/URLSearchParams, both global in Node, and the package already requiresengines.node: ">=20". It has no compression dependency, so the re-export cannot pull the brotli-wasm path into the Node bundle. Importing fromindex.node.jsin the root keeps Node onutils/compression.node.js.Test plan
typechecklintnoExplicitAnywarning insubscribe.ts:98, untouched)testbuildThe new test is a real guard: removing the re-export makes it fail, restoring it makes it pass.
Verified in the built output:
Smoke-tested the built
distin Node:Notes
Two things from #368 deliberately left out of this PR:
personal_sign/ Storybook). The referencedstorybook/stories/components/smart-wallet/SubAccount.tsxdoes not exist in this repo, and there is nostorybook/directory. Every sub-accountpersonal_signexample in the repo already hex-encodes correctly (examples/testapp/src/pages/add-sub-account/components/PersonalSign.tsx:22-25,import-sub-account/components/PersonalSign.tsx:21-24,e2e-test/tests/sub-account-features.ts:170-173,auto-sub-account/index.page.tsx:218-223). The hex requirement itself is intentional and locked by tests increateSubAccountSigner.test.ts:334-341and:361-382, so changing it would be breaking. Left for separate discussion on the issue.