Closed 0xBraunGuy closed 1 year ago
thanks, could you show me an example of what you mean here?
so creating a new BankrunProvider from an existing context (multiple signers) is easier.
thanks, could you show me an example of what you mean here?
so creating a new BankrunProvider from an existing context (multiple signers) is easier.
something like :
const alice = new NodeWallet(Keypair.generate());
const bob = new NodeWallet(Keypair.generate());
const context = startAnchor(...);
const aliceProvider = new BankrunProvider(context, alice);
const bobProvider = new BankrunProvider(context, bob);
And I suppose you'll fund those accounts using the accounts
parameter of startAnchor
? The ctx.payer
account gets funded by the solana-program-test code but other accounts will need to be funded separately
I think we can intercept connection.requestAirdrop()
and add it to the ConnectionInterface
. Ideally a user would be able to generate keypairs on demand and fund them. At least this would make porting my Anchor integration tests over.
Can throw out a few more MR's if you like this approach.
I don't like relying on the ConnectionInterface too much. Ideally it wouldn't exist, but the Anchor TS client relies on having a web3.js Connection attribute. I would prefer if the Provider interface didn't require a web3.js Connection.
I would also like if the fake Connection object in BankrunProvider wasn't available to the user at all since it's a footgun, but I don't think there's nice way to make it available to anchor-ts but unavailable to anchor-bankrun users.
If we intercept connection.requestAirdrop()
we're encouraging users to rely on the fake Connection which kills type safety and is generally hazardous.
upgrading from an
AnchorProvider
is tough because it exposes thepublicKey
directly, this will help.also adds an optional
wallet
parameter so creating a newBankrunProvider
from an existing context (multiple signers) is easier.