Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Docs] Mini App wallet provider migration guide needed: Base App in-app browser (post-April 2026)

オープン
#1,420 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
62/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript
領域
documentation

調査の方向性

mini-app wallet のドキュメントを見つけ、まず既存の provider と SDK に関するガイダンスを確認してください。提供された Base App と Warpcast の動作、タイムアウトのパターン、upstream issue、reference commit を使って migration section を追加してください。完了の条件は、ドキュメントで検出、injected-provider fallback、ハングする SDK 呼び出しの安全な処理が説明されていることです。

索引モデルが issue の本文から書いたものです。

説明

Problem

Base App's April 2026 update changed how mini-apps are launched: they now open in a standard in-app WebView instead of a Farcaster mini-app host. This is a breaking change for any mini-app that uses @farcaster/miniapp-sdk for wallet access.

The current docs don't cover:

  1. How to detect Base App in-app browser vs. true Farcaster embed (Warpcast)
  2. How to fall back to injected EIP-1193 provider (window.ethereum / coinbaseWalletExtension) in Base App
  3. The sdk.actions.ready() / sdk.wallet.getEthereumProvider() hang issue specific to Base WebView

This causes mini-apps to silently hang on transactions — no error, no timeout, just an indefinite loading state.

Suggested Addition

A "Wallet Provider Migration for Base App 2026" section in the mini-app docs covering:

Detection pattern
// Base App (post-April 2026) does NOT act as Farcaster mini-app host.
// sdk.isInMiniApp() returns false — use injected EIP-1193 instead.
async function getProvider(sdk) {
    const isEmbed = await Promise.race([
        sdk.isInMiniApp(),
        new Promise(resolve => setTimeout(() => resolve(false), 1000))
    ]);
    
    if (isEmbed) {
        return sdk.wallet.getEthereumProvider(); // Warpcast / true Farcaster host
    }
    
    // Base App or regular browser: use injected wallet
    return window.coinbaseWalletExtension 
        ?? window.ethereum 
        ?? null;
}
ready() timeout pattern
// In Base App, ready() never resolves — wrap with timeout:
await Promise.race([
    sdk.actions.ready(),
    new Promise((_, reject) => setTimeout(() => reject(), 5000))
]).catch(() => { /* continue, Base App doesn't need ready() ack */ });

Working Reference Implementation

This exact pattern was implemented and verified on Base mainnet in a real mini-app:

Impact

Any mini-app using @farcaster/miniapp-sdk for wallet transactions that:

  • Was built before April 2026
  • Relies on getEthereumProvider() from the SDK
  • Is listed in Base App discovery

...will silently break for all Base App users without this migration.

Related SDK Issue

Filed upstream: farcasterxyz/miniapps#608


Happy to contribute a PR with the docs addition if that would help.

主要言語
JavaScript
スター
337
フォーク
798
平均マージ
19時間 12分
マージ済み PR(30日)
60

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

base/docs のほかの issue

base/docs の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。