Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[hardhat-waffle] types for "loadFixture" are broken #849

Open
PaulRBerg opened this issue Oct 3, 2020 · 9 comments
Open

[hardhat-waffle] types for "loadFixture" are broken #849

PaulRBerg opened this issue Oct 3, 2020 · 9 comments
Labels
area:hardhat-waffle status:blocked Blocked by other issues or external reasons type:bug Something isn't working

Comments

@PaulRBerg
Copy link
Contributor

PaulRBerg commented Oct 3, 2020

Description

As explained on Discord, the 2.1.0 release for @nomiclabs/buidler-waffle broke the loadFixture function.

The root of the issue is in the fixtures.ts file. If overrideSigners is not manually overridden by end-users, the default loadFixture function has this argument to 'undefined', as per its definition in index.ts:

loadFixture: buidlerCreateFixtureLoader(buidlerWaffleProvider)

As you can see, there is no second or third argument, so overrideSigners ends up being assigned to 'undefined'.

Current Workaround

Fortunately, it is possible to band-aid this bug by creating a custom fixture loader, as per the Waffle docs. Here's how I did it:

import { Fixture } from "ethereum-waffle";
import { Signer } from "@ethersproject/abstract-signer";
import { waffle } from "@nomiclabs/buidler";

const { createFixtureLoader } = waffle;

export function loadFixture(signers: Signer[]): <T>(fixture: Fixture<T>) => Promise<T> {
  return createFixtureLoader(Object.values(signers));
}

Possible Solution

The definition of loadFixture should be changed to something like this:

loadFixture: buidlerCreateFixtureLoader(buidlerWaffleProvider, await bre.ethers.getSigners()),

I would have made a PR, but:

  • I'm not sure how to call bre.ethers from within that context
  • The function type passed on to extendEnvironment is non-async so await functions cannot be executed
@PaulRBerg
Copy link
Contributor Author

PaulRBerg commented Oct 3, 2020

I've also just noticed that there is another potentially linked issue with the implementation of fixtures in buidler-waffle.

In the fixtures.ts file, the types are Signer, but in type-extensions.d.ts file, the types are the implicit ones provided by Waffle, i.e. Wallet. This means that end-users must cast the Signer array as a Wallet] array, which works in most cases, but it goes against what Richard Moore (creator of ethers.js) recommends doing:

Waffle should certainly not be using Wallet as their low-level Signer as Wallet is a fairly high-level Signer. The Signer sub-class should be what they use, since a Wallet requires a private key, which many situations do not have access to.

Possibly related: TrueFiEng/Waffle#355

@PaulRBerg
Copy link
Contributor Author

PaulRBerg commented Jan 9, 2021

Hey @alcuadrado, has this been addressed in Hardhat?

@Mrtenz
Copy link

Mrtenz commented Jan 9, 2021

@PaulRBerg I was running into this issue today with Hardhat, so it seems like this is not fixed yet.

@fvictorio
Copy link
Member

Hi, I recently was able to use loadFixture by just using the signers from ethers.getSigners() instead of the ones that loadFixture receives. So the workaround is to just declare your fixture without any parameters.

I'm going to leave this open because at some point we need to put some serious effort into making waffle work more seamlessly with hardhat, and this is one of the several things that should work better.

@PaulRBerg
Copy link
Contributor Author

PaulRBerg commented Jun 11, 2021

I can confirm that it works now.

Yes, increasing compatibility between Hardhat and Waffle (or even implementing some of the latter's features natively) would go a long way.

@PaulRBerg
Copy link
Contributor Author

Update: it doesn't work. The only improvement is that the types match now. I am getting this error:

TypeError: Cannot read property '0' of undefined
      at /Users/paulrberg/projects/prb-math/test/shared/fixtures.ts:28:35
      at step (test/shared/fixtures.ts:33:23)
      at Object.next (test/shared/fixtures.ts:14:53)
      at /Users/paulrberg/projects/prb-math/test/shared/fixtures.ts:8:71
      at new Promise (<anonymous>)
      at __awaiter (test/shared/fixtures.ts:4:12)
      at unitFixturePrbMathUd60x18 (test/shared/fixtures.ts:65:12)
      at Proxy.load (node_modules/@nomiclabs/hardhat-waffle/src/fixtures.ts:32:26)
      at Context.<anonymous> (test/prbMathUd60x18/PRBMathUD60x18.ts:9:45)
      at step (test/prbMathUd60x18/PRBMathUD60x18.ts:33:23)

The issue is that the array of signers is empty.

@fvictorio
Copy link
Member

The issue is that the array of signers is empty.

Which array of signers? The one received by the fixture? As far as I could tell, the fixture isn't receiving anything, that's why I mentioned that you should just manually get the signers instead of using the arguments. That's it, try:

async function myFixture() {
  const signers = await ethers.getSigners()
  ...

and use that.

@PaulRBerg
Copy link
Contributor Author

Which array of signers? The one received by the fixture?

Yes.

that's why I mentioned that you should just manually get the signers instead of using the arguments.

Oh, I see.

@PaulRBerg PaulRBerg changed the title loadFixture in buidler-waffle is broken [hardhat-waffle] types for "loadFixture" are broken Sep 2, 2021
@Diego-c22
Copy link

You can create different functions to call a fixture with different arguments and use that functions with loadFixture()

@fvictorio fvictorio added status:blocked Blocked by other issues or external reasons area:hardhat-waffle type:bug Something isn't working and removed priority:medium labels Dec 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:hardhat-waffle status:blocked Blocked by other issues or external reasons type:bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

4 participants