Si vous venez de @solana/web3.js (v1), @solana/wallet-adapter-*, ou des
anciens packages framework-kit (@solana/client, @solana/react-hooks,
@solana/web3-compat), ces approches sont désormais obsolètes. Les nouvelles
applications se construisent directement sur @solana/kit et les plugins kit.
Cette page fait correspondre les concepts que vous connaissez déjà à leurs
équivalents Kit.
Correspondance des concepts
| web3.js v1 / wallet-adapter | Kit |
|---|---|
new Connection(url) | createSolanaRpc(url), ou .use(solanaRpc({ rpcUrl })) sur un client |
PublicKey | Address — convertir une chaîne avec address("...") |
Keypair | generateKeyPairSigner() ou les plugins @solana/kit-plugin-signer |
SystemProgram.transfer(...) | getTransferSolInstruction(...) de @solana-program/system |
LAMPORTS_PER_SOL math | lamports(...) de @solana/kit |
Transaction / VersionedTransaction | Messages de transaction construits et empaquetés par le planificateur de transactions |
sendAndConfirmTransaction(...) | client.sendTransaction([...]) (le planificateur signe, envoie et confirme) |
@solana/wallet-adapter-* | @solana/kit-plugin-wallet + découverte via Wallet Standard |
Vous venez de web3.js ?
Si vous maintenez une large base de code @solana/web3.js v1 et qu'une
réécriture complète vers Kit n'est pas encore envisageable, web3.js v3 constitue
le pont. Il est actuellement distribué sous @solana/web3.js@rc (la ligne
3.0.0-rc) et reconstruit l'API classique basée sur les classes — Connection,
Keypair, Transaction — au-dessus des internes de @solana/kit. Comme il
repose sur Kit, l'interopérabilité est étroite : PublicKey est un alias
déprécié de Address, et un Keypair v3 satisfait structurellement
KeyPairSigner de Kit, vous pouvez donc le passer directement aux API Kit, aux
plugins et aux clients générés par Codama.
Transactions v1 et web3.js v1
web3.js v1 lit le format de transaction
v1 à partir de
la version 1.99.0 : getTransaction, getBlock, et
VersionedTransaction.deserialize acceptent le format v1 dès lors que vous passez
maxSupportedTransactionVersion: 1. La lecture est la seule direction prise en charge —
la construction, la signature et l'envoi de transactions v1 génèrent une erreur dans cette version de la bibliothèque. Toute version antérieure
à 1.99.0 est limitée à maxSupportedTransactionVersion: 0 et échoue sur les transactions v1
sans exception. Si vous envoyez des transactions, Kit 8.x et web3.js v3 sont
les cibles de migration.
v3 est encore en version candidate — épinglez des versions exactes et attendez-vous à quelques changements d'API entre les RC. Il s'agit d'un chemin d'interopérabilité avec l'ancien code, et non d'une option par défaut pour les nouveaux projets ; les nouvelles applications doivent être construites directement sur Kit. Pour la migration elle-même, consultez le guide de migration web3.js v1 → v3 officiel.
Portefeuilles
Kit n'utilise pas wallet-adapter. @solana/kit-plugin-wallet découvre les
portefeuilles compatibles Wallet Standard et les expose via client.wallet et
les hooks React. Les portefeuilles modernes
(Phantom, Solflare, Backpack, et autres) s'annoncent via Wallet Standard, donc
aucun package adaptateur par portefeuille n'est requis.
Vous pouvez également utiliser des outils prêts à l'emploi comme @solana/connector, qui utilise directement les primitives de Kit pour se connecter aux portefeuilles.
Vous utilisez encore wallet-adapter ?
Si vous maintenez une application construite sur @solana/wallet-adapter-* et
que vous n'êtes pas prêt à migrer, le dépôt wallet-adapter
reste la référence pour cette
stack. Pour tout nouveau projet, privilégiez le plugin de portefeuille Kit.
Où aller ensuite
- Client Kit — assemblez un client à partir de plugins.
- React — liaisons
@solana/reactet hooks de portefeuille. - Tutoriel Next.js — une application complète de bout en bout.
Is this page helpful?