Support custom error selectors in `revertedWithCustomError` Chai matcher

[ItsNickBarry]

Describe the feature

What is the reasoning behind requiring an interface to be passed to revertedWithCustomError? The error name string itself should be enough to run the assertion.

In my case, the contract I'm testing takes a custom error selector as a parameter and reverts with that error using assembly. The errors do not exist in the contract ABI, so I have to pass in a fake interface to the matcher.

const customError = 'TestError';

const placeholder = {
  interface: new ethers.Interface([`error ${ customError }()`]),
};

const selector = placeholder.interface.getError(customError)?.selector!;

await expect(
  contract.revertWithCustomErrorSelector(selector),
).to.be.revertedWithCustomError(placeholder, customError);

If this process could be encapsulated within the matcher code, the matcher could be used like this:

await expect(...).to.be.revertedWithCustomError(customError);
// or
await expect(...).to.be.revertedWithCustomError(selector);

Maybe the withArgs extension needs the full interface to process its arguments. In that case, maybe require the full error signature?

await expect(...).to.be.revertedWithCustomError('TestError(uint256)`);

Search terms

revertedWithCustomError

Similar to #5818, but more specifically related to errors that do not exist on the contract being tested.

[ChristopherDedominici]

Hi @ItsNickBarry, the reason revertedWithCustomError requires an interface is to resolve the full error signature, especially when the custom error includes parameters (e.g.: ErrorName(uint256), ErrorName(bool, bool), etc.).
Just passing the error name ErrorName is ambiguous, and without more context, the matcher can't determine the correct selector.

So, not requiring the full error signature and instead relying on an interface was a deliberate design choice to balance usability and clarity.

[ChristopherDedominici]

Hi @ItsNickBarry, thanks for opening the PR! I took a quick look and noticed that tests are currently missing. At the moment, we're quite focused on Hardhat 3 and not planning to add new functionalities to hardhat-chai-matchers. That said, we’d be happy to merge the PR if it includes both manual testing and automated tests.

I also saw that you were having trouble using the plugin locally, perhaps you could try using verdaccio? I gave it a shot on my end and was able to get the plugin working.

What to do:

• install Verdaccio
• build the hardhat-chai-matchers package via pnpm build
• bump the package version to 2.0.9, otherwise verdaccio will (rightfully) complain that the package already exists
• publish the package in verdaccio: pnpm publish --registry http://localhost:4873 --no-git-checks
• install the package in an example project using: pnpm add @nomicfoundation/hardhat-chai-matchers --registry http://localhost:4873/