Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughMigrates NEAR wallet integration from Changes
Sequence DiagramsequenceDiagram
participant User as User/App
participant Connector as NearConnector<br/>(Wallet)
participant Client as WalletClient<br/>/ State
participant NEAR as NEAR<br/>Network
User->>Client: initialize connector
Client->>Connector: new NearConnector(...)
Connector-->>Connector: load manifest
Connector->>Client: emit wallet:signIn
Client->>Client: update isSignedIn, accountId
User->>Connector: connect & select wallet
Connector->>NEAR: request connection
NEAR-->>Connector: confirm connection
Connector->>Client: emit wallet:signIn / provide getConnectedWallet()
User->>Client: sign & send transaction
alt connector supports signAndSendTransaction
Client->>Connector: signAndSendTransaction(tx)
else
Client->>Connector: signAndSendTransactions(txs)
end
Connector->>NEAR: send signed tx(s)
NEAR-->>Connector: transaction result
User->>Client: sign out
Connector->>Client: emit wallet:signOut
Client->>Client: clear wallet/account state
Connector->>Connector: disconnect
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@src/common/blockchains/near-protocol/client.ts`:
- Around line 206-230: The catch block currently retries with
wallet.signAndSendTransactions for any error from wallet.signAndSendTransaction,
which can hide real transaction failures; change the logic so you only fall back
when the error clearly indicates the method is unsupported (e.g., check
error.name/message for patterns like "is not a function"/"not defined"/"not
supported" or error instanceof TypeError) before calling
wallet.signAndSendTransactions, otherwise rethrow the original error; ensure you
still reference wallet.signAndSendTransaction, wallet.signAndSendTransactions
and outcome, and wrap the fallback call in its own try/catch so any fallback
failure is surfaced rather than silently swallowed.
- Around line 232-239: The code incorrectly casts outcome to
FinalExecutionOutcome causing type mismatch between signAndSendTransaction,
signAndSendTransactions, and callMultiple; change the fallback to detect whether
outcome is an array and return the correct shape instead of forcing a cast: use
Array.isArray(outcome) to return outcome as FinalExecutionOutcome[] for
signAndSendTransactions paths or outcome as FinalExecutionOutcome for
single-transaction paths, update the providers.getTransactionLastResult handling
to only cast the single-result branch, and ensure callMultiple returns the
array-returning signAndSendTransactions result (or unwrap it consistently) so
the API return types for signAndSendTransaction, signAndSendTransactions, and
callMultiple remain consistent.
🧹 Nitpick comments (2)
src/common/contracts/core/campaigns/client.ts (1)
80-83: Avoid console.log side-effects in contract client.This adds runtime noise to a shared client layer; prefer logging in the consuming layer or via a centralized logger with environment guards.
🛠️ Suggested change
- } else { - console.log("create campaign"); + } else { return contractApi.call<CreateCampaignParams["args"], Campaign>("create_campaign", {As per learnings, keep the contract client layer free of side-effect/error-handling logic.
src/common/blockchains/near-protocol/client.ts (1)
18-23: Consider removing unusedcallbackUrlfromCallProps.The
callbackUrlproperty is defined but not used in thecallmethod. ThecallMultiplemethod's_callbackUrlparameter is also explicitly marked as unused with an underscore prefix. Consider removing these if callback URLs are no longer supported by the NearConnector API.♻️ Suggested fix
type CallProps<A extends object = Record<string, unknown>> = { args?: A; gas?: string; deposit?: string; - callbackUrl?: string; };
| try { | ||
| if (!("signAndSendTransaction" in wallet)) { | ||
| throw new Error("Wallet does not support signAndSendTransaction"); | ||
| } | ||
|
|
||
| outcome = await wallet.signAndSendTransaction({ | ||
| signerId, | ||
| receiverId: transaction.receiverId, | ||
| actions: transaction.actions, | ||
| }); | ||
| } catch (error) { | ||
| // Fallback for wallets that only support signAndSendTransactions | ||
| if ("signAndSendTransactions" in wallet) { | ||
| outcome = await wallet.signAndSendTransactions({ | ||
| transactions: [ | ||
| { | ||
| receiverId: transaction.receiverId, | ||
| actions: transaction.actions, | ||
| }, | ||
| ], | ||
| }); | ||
| } else { | ||
| throw error; | ||
| } | ||
| } |
There was a problem hiding this comment.
Overly broad catch may swallow legitimate transaction errors.
The fallback logic catches all errors from signAndSendTransaction, including actual transaction failures, and attempts signAndSendTransactions instead. This could mask real errors (e.g., insufficient funds, contract panics) by retrying with a different method.
Consider checking the error type or message to only fall back when the method isn't supported:
🔧 Suggested fix
try {
if (!("signAndSendTransaction" in wallet)) {
throw new Error("Wallet does not support signAndSendTransaction");
}
outcome = await wallet.signAndSendTransaction({
signerId,
receiverId: transaction.receiverId,
actions: transaction.actions,
});
} catch (error) {
- // Fallback for wallets that only support signAndSendTransactions
- if ("signAndSendTransactions" in wallet) {
+ // Fallback for wallets that only support signAndSendTransactions (method not available)
+ const isMethodNotSupported =
+ error instanceof Error &&
+ (error.message.includes("does not support signAndSendTransaction") ||
+ error.message.includes("not a function") ||
+ error.message.includes("not implemented"));
+
+ if (isMethodNotSupported && "signAndSendTransactions" in wallet) {
outcome = await wallet.signAndSendTransactions({
transactions: [
{
receiverId: transaction.receiverId,
actions: transaction.actions,
},
],
});
} else {
throw error;
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| try { | |
| if (!("signAndSendTransaction" in wallet)) { | |
| throw new Error("Wallet does not support signAndSendTransaction"); | |
| } | |
| outcome = await wallet.signAndSendTransaction({ | |
| signerId, | |
| receiverId: transaction.receiverId, | |
| actions: transaction.actions, | |
| }); | |
| } catch (error) { | |
| // Fallback for wallets that only support signAndSendTransactions | |
| if ("signAndSendTransactions" in wallet) { | |
| outcome = await wallet.signAndSendTransactions({ | |
| transactions: [ | |
| { | |
| receiverId: transaction.receiverId, | |
| actions: transaction.actions, | |
| }, | |
| ], | |
| }); | |
| } else { | |
| throw error; | |
| } | |
| } | |
| try { | |
| if (!("signAndSendTransaction" in wallet)) { | |
| throw new Error("Wallet does not support signAndSendTransaction"); | |
| } | |
| outcome = await wallet.signAndSendTransaction({ | |
| signerId, | |
| receiverId: transaction.receiverId, | |
| actions: transaction.actions, | |
| }); | |
| } catch (error) { | |
| // Fallback for wallets that only support signAndSendTransactions (method not available) | |
| const isMethodNotSupported = | |
| error instanceof Error && | |
| (error.message.includes("does not support signAndSendTransaction") || | |
| error.message.includes("not a function") || | |
| error.message.includes("not implemented")); | |
| if (isMethodNotSupported && "signAndSendTransactions" in wallet) { | |
| outcome = await wallet.signAndSendTransactions({ | |
| transactions: [ | |
| { | |
| receiverId: transaction.receiverId, | |
| actions: transaction.actions, | |
| }, | |
| ], | |
| }); | |
| } else { | |
| throw error; | |
| } | |
| } |
🤖 Prompt for AI Agents
In `@src/common/blockchains/near-protocol/client.ts` around lines 206 - 230, The
catch block currently retries with wallet.signAndSendTransactions for any error
from wallet.signAndSendTransaction, which can hide real transaction failures;
change the logic so you only fall back when the error clearly indicates the
method is unsupported (e.g., check error.name/message for patterns like "is not
a function"/"not defined"/"not supported" or error instanceof TypeError) before
calling wallet.signAndSendTransactions, otherwise rethrow the original error;
ensure you still reference wallet.signAndSendTransaction,
wallet.signAndSendTransactions and outcome, and wrap the fallback call in its
own try/catch so any fallback failure is surfaced rather than silently
swallowed.
| const result = providers.getTransactionLastResult(outcome as FinalExecutionOutcome); | ||
|
|
||
| // Some wallets don't return a last result; return the outcome instead. | ||
| if (result === undefined) { | ||
| throw new Error("Unable to determine transaction result."); | ||
| return outcome as unknown as R; | ||
| } | ||
|
|
||
| return result as R; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, check if `@hot-labs/near-connect` exists and find type definitions
fd -t f -e "d.ts" "near-connect" node_modules 2>/dev/null | head -5Repository: PotLock/potlock-nextjs-app
Length of output: 52
🏁 Script executed:
#!/bin/bash
# Examine the file in question to understand context
cat -n src/common/blockchains/near-protocol/client.ts | sed -n '220,250p'Repository: PotLock/potlock-nextjs-app
Length of output: 1075
🏁 Script executed:
#!/bin/bash
# Search for signAndSendTransaction methods and their usage
rg "signAndSendTransaction" src/common/blockchains/near-protocol/client.ts -B 5 -A 5Repository: PotLock/potlock-nextjs-app
Length of output: 1109
🏁 Script executed:
#!/bin/bash
# Check if there are type definitions or interfaces that define these methods
rg "signAndSendTransaction" --type ts --type d.ts -A 3 2>/dev/null | head -50Repository: PotLock/potlock-nextjs-app
Length of output: 52
🏁 Script executed:
#!/bin/bash
# Check file imports and type definitions at the top
cat -n src/common/blockchains/near-protocol/client.ts | head -50Repository: PotLock/potlock-nextjs-app
Length of output: 1890
🏁 Script executed:
#!/bin/bash
# Search for wallet type/interface definition in the file
rg "wallet.*:" src/common/blockchains/near-protocol/client.ts -B 2 -A 2 | head -40Repository: PotLock/potlock-nextjs-app
Length of output: 506
🏁 Script executed:
#!/bin/bash
# Search for FinalExecutionOutcome definition
rg "FinalExecutionOutcome" src/common/blockchains/near-protocol/client.tsRepository: PotLock/potlock-nextjs-app
Length of output: 233
🏁 Script executed:
#!/bin/bash
# Check what signAndSendTransactions returns in callMultiple function
cat -n src/common/blockchains/near-protocol/client.ts | sed -n '242,260p'Repository: PotLock/potlock-nextjs-app
Length of output: 789
🏁 Script executed:
#!/bin/bash
# Find NearWalletBase type definition
find node_modules/@hot-labs/near-connect -name "*.d.ts" -o -name "*.ts" 2>/dev/null | xargs grep -l "NearWalletBase" 2>/dev/null | head -5Repository: PotLock/potlock-nextjs-app
Length of output: 298
🏁 Script executed:
#!/bin/bash
# Search for signAndSendTransaction method signature in near-connect
find node_modules/@hot-labs/near-connect -type f \( -name "*.d.ts" -o -name "*.ts" \) 2>/dev/null -exec grep -l "signAndSendTransaction" {} \;Repository: PotLock/potlock-nextjs-app
Length of output: 318
🏁 Script executed:
#!/bin/bash
# Try to locate and read the type definitions
fd "\.d\.ts$" node_modules/@hot-labs/near-connect 2>/dev/null | head -3Repository: PotLock/potlock-nextjs-app
Length of output: 257
🏁 Script executed:
#!/bin/bash
# Read the types file to find NearWalletBase
cat node_modules/@hot-labs/near-connect/build/types.d.tsRepository: PotLock/potlock-nextjs-app
Length of output: 4616
🏁 Script executed:
#!/bin/bash
# Also check InjectedWallet
cat node_modules/@hot-labs/near-connect/build/InjectedWallet.d.tsRepository: PotLock/potlock-nextjs-app
Length of output: 1108
Fix type incompatibility between signAndSendTransaction and signAndSendTransactions return types.
signAndSendTransaction returns FinalExecutionOutcome, but signAndSendTransactions (fallback on line 225) returns Array<FinalExecutionOutcome>. The type cast on line 232 incorrectly asserts the outcome as FinalExecutionOutcome when the fallback path provides an array. Additionally, callMultiple (line 258) returns signAndSendTransactions directly, which is an array, creating inconsistent return types across the API.
🤖 Prompt for AI Agents
In `@src/common/blockchains/near-protocol/client.ts` around lines 232 - 239, The
code incorrectly casts outcome to FinalExecutionOutcome causing type mismatch
between signAndSendTransaction, signAndSendTransactions, and callMultiple;
change the fallback to detect whether outcome is an array and return the correct
shape instead of forcing a cast: use Array.isArray(outcome) to return outcome as
FinalExecutionOutcome[] for signAndSendTransactions paths or outcome as
FinalExecutionOutcome for single-transaction paths, update the
providers.getTransactionLastResult handling to only cast the single-result
branch, and ensure callMultiple returns the array-returning
signAndSendTransactions result (or unwrap it consistently) so the API return
types for signAndSendTransaction, signAndSendTransactions, and callMultiple
remain consistent.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@package.json`:
- Line 30: The dependency "@hot-labs/near-connect" referenced in package.json is
actively maintained and tied to HERE Wallet—verify it meets our
stability/compatibility requirements by running integration tests against the
current ^0.8.2 release and reviewing its changelog for breaking changes; if
compatibility is confirmed, either keep the caret range (^0.8.2) or update the
version to the latest published release, and add a short note in our dependency
documentation (e.g., DEPENDENCIES.md) mentioning its pre-1.0 status and that it
was validated for our app; if it fails compatibility, pin to a known-good
version or replace it with an alternative.
- Line 78: The package.json pins "near-api-js": "6.5.1" which is incompatible
with existing imports (e.g., near-api-js/lib/utils/format,
near-api-js/lib/providers/provider, and Account) because v6 split into
`@near-js/`* packages; either revert this dependency to a v2.x that matches
current codebase or migrate all imports to the new modular packages per the
official MIGRATION.md (replace legacy imports and usages of Account and internal
paths with the appropriate `@near-js/`* modules; note `@near-js/transactions` is
already present). Also align version pinning style with project convention (use
caret ranges like ^2.x for near-api-js or document why exact pins are required)
and treat react-day-picker (8.10.1) similarly.
🧹 Nitpick comments (2)
package.json (2)
68-68: Consider moving build tools to devDependencies.
browserslistandlightningcssare typically build-time tools rather than runtime dependencies. Unless they are required at runtime (e.g., for server-side CSS processing), consider moving them todevDependenciesto reduce production bundle size.Also applies to: 75-75
111-113: Document the reason for the@noble/curvesresolution override.The
@noble/curvesresolution forces version ^1.8.0 to resolve version conflicts across transitive dependencies. Different versions of@near-js/crypto(used by viem/wagmi dependencies) require conflicting versions: older versions expect 1.2.0, while newer versions expect 1.8.1+. This resolution ensures compatibility by enforcing a minimum version across the entire dependency tree. Consider adding a comment inpackage.jsonorREADME.mdexplaining this constraint and referencing the@near-js/cryptoversion alignment, to help future maintainers understand when it can be removed or updated.
| "@ebay/nice-modal-react": "^1.2.13", | ||
| "@formkit/tempo": "^0.1.2", | ||
| "@hookform/resolvers": "^3.9.1", | ||
| "@hot-labs/near-connect": "^0.8.2", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check npm registry info for `@hot-labs/near-connect`
curl -s https://registry.npmjs.org/@hot-labs/near-connect | jq '{name: .name, description: .description, "dist-tags": .["dist-tags"], time: .time | keys[-5:], maintainers: .maintainers}'Repository: PotLock/potlock-nextjs-app
Length of output: 463
@hot-labs/near-connect is actively maintained and associated with HERE Wallet.
The package is properly published on npm with recent version releases (0.8.0–0.8.2) and maintained by the HERE Wallet ecosystem. However, note that it's still in pre-1.0 development phase—verify compatibility with your application's stability requirements.
🤖 Prompt for AI Agents
In `@package.json` at line 30, The dependency "@hot-labs/near-connect" referenced
in package.json is actively maintained and tied to HERE Wallet—verify it meets
our stability/compatibility requirements by running integration tests against
the current ^0.8.2 release and reviewing its changelog for breaking changes; if
compatibility is confirmed, either keep the caret range (^0.8.2) or update the
version to the latest published release, and add a short note in our dependency
documentation (e.g., DEPENDENCIES.md) mentioning its pre-1.0 status and that it
was validated for our app; if it fails compatibility, pin to a known-good
version or replace it with an alternative.
| "lucide-react": "^0.378.0", | ||
| "markdown-truncate": "^1.1.1", | ||
| "near-api-js": "^2.1.4", | ||
| "near-api-js": "6.5.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
near-api-js 6.5.1 breaking changes from version 2 release notes
💡 Result:
Do you mean: (A) "What breaking changes are introduced in near-api-js v6.5.1 compared to the v2.x release (i.e., a migration summary)?" or (B) "Show the breaking changes listed in the near-api-js v2 release notes and how v6.5.1 relates to them?"
🏁 Script executed:
# Check the dependency versions in package.json to verify consistency
cd . && cat -n package.json | sed -n '1,100p' | head -100Repository: PotLock/potlock-nextjs-app
Length of output: 4346
🌐 Web query:
near-api-js changelog v6 breaking changes migration guide
💡 Result:
Short answer — see the official near-api-js CHANGELOG and Migration guide on the GitHub repo for v6 breaking changes and step-by-step migration instructions: GitHub CHANGELOG.md and MIGRATION.md. [1][2]
Helpful links:
- near-api-js repository (CHANGELOG + MIGRATION.md). [1]
- NEAR docs / near-api-js overview (context on package changes). [2]
If you want, I can open MIGRATION.md and extract the v6 breaking changes and exact code migration examples for you. Which would you prefer?
Sources:
[1] near/near-api-js (GitHub) — repository files including CHANGELOG.md and MIGRATION.md.
[2] NEAR docs — NEAR JavaScript API overview.
🏁 Script executed:
# Search for near-api-js usage in the codebase
rg "near-api-js" --type ts --type tsx --type js --type json -A 3 -B 1Repository: PotLock/potlock-nextjs-app
Length of output: 97
🌐 Web query:
near-api-js v6.0.0 breaking changes what changed from v2
💡 Result:
Short summary — biggest breaking changes from near-api-js v2 → v6:
- Library restructured and renamed into modular
@near-js/* packages (no single monolithic near-api-js). You now import only needed packages (accounts, providers, signers, transactions, tokens, etc.). [1][2] - New high-level client/typed APIs and primitives (Account/TypedContract, actionCreators, Token helpers) and a Signer abstraction (KeyPairSigner) replacing many old keystore/signing flows — code that used old classes/constructors must be updated to new types & method names. [1][2][3]
- Tree-shakeable, modern ESM-first packages and examples; different import paths and usage patterns (CDN paths and package names changed). Expect to update imports throughout your codebase. [1][3]
- Provider and RPC changes: new providers packages and helper factories (e.g., fallback RPC provider patterns); RPC URL/key handling and provider APIs differ. Update RPC/provider construction and RPC calls. [1][3]
- Transactions and utilities reorganized (actionCreators, tokens with NEAR.toUnits/ toDecimal, transaction composition) — transaction construction/signing APIs changed. [1][3]
- Overall developer UX / performance improvements (smaller bundles, clearer separation of concerns) but requires explicit migration steps (update package names, imports, constructors, and some method signatures). [1][2]
If you want, I can:
- produce a targeted migration checklist for your code (showing old v2 snippets → new v6/@near-js equivalents), or
- search for any specific API you use and give the exact replacement.
Sources: NEAR docs on the new @near-js packages and examples; near-api-js GitHub README; @near-js/client npm docs. [1][2][3]
References
[1] NEAR docs — NEAR API / @near-js packages.
[2] near/near-api-js GitHub (README).
[3] @near-js/client (npm) documentation.
🏁 Script executed:
# Search for near-api-js imports and usage in the codebase
rg "near-api-js|from.*near-api-js" -A 2 -B 1Repository: PotLock/potlock-nextjs-app
Length of output: 7336
🏁 Script executed:
# Also check more dependencies to understand the pinning pattern
cat -n package.json | grep -E '"[^"]+": "[0-9]' | head -20Repository: PotLock/potlock-nextjs-app
Length of output: 217
🏁 Script executed:
# Check if `@near-js` packages are already in package.json
grep -E '"@near-js/' package.jsonRepository: PotLock/potlock-nextjs-app
Length of output: 108
🏁 Script executed:
# Check how many files are using old near-api-js imports
rg "from ['\"]near-api-js" --countRepository: PotLock/potlock-nextjs-app
Length of output: 851
Critical: near-api-js v6.5.1 has major breaking changes that make the codebase incompatible.
near-api-js v6 fundamentally restructured the library from a monolithic package to modular @near-js/* packages. The codebase currently imports from the old v2 structure (e.g., near-api-js/lib/utils/format, near-api-js/lib/providers/provider, Account from near-api-js) in at least 17 files, which no longer exists in v6. Only partial migration has occurred (@near-js/transactions is installed, but old imports still dominate).
Either migrate all imports to the new @near-js/* packages following the official MIGRATION.md guide, or revert to near-api-js v2.x that the codebase was designed for.
Regarding version pinning: near-api-js uses exact pinning (6.5.1) while most dependencies use caret ranges (^x.y.z). This also applies to react-day-picker (8.10.1). If intentional, document why; otherwise align with project convention.
🤖 Prompt for AI Agents
In `@package.json` at line 78, The package.json pins "near-api-js": "6.5.1" which
is incompatible with existing imports (e.g., near-api-js/lib/utils/format,
near-api-js/lib/providers/provider, and Account) because v6 split into
`@near-js/`* packages; either revert this dependency to a v2.x that matches
current codebase or migrate all imports to the new modular packages per the
official MIGRATION.md (replace legacy imports and usages of Account and internal
paths with the appropriate `@near-js/`* modules; note `@near-js/transactions` is
already present). Also align version pinning style with project convention (use
caret ranges like ^2.x for near-api-js or document why exact pins are required)
and treat react-day-picker (8.10.1) similarly.
1 participant
Summary by CodeRabbit
Updates
Bug Fixes / Chores
✏️ Tip: You can customize this high-level summary in your review settings.