Allow `anyValue` option for emitWithArgs, revertWithCustomErrorWithArgs

[drortirosh]

Allow anyValue option for emitWithArgs, revertWithCustomErrorWithArgs

e.g. check that in this tx, if my account received tokens (ignoring sender or amount)

      await emitWithArgs(viem, tx,
        myToken,
        'Transfer',
        [ anyValue, myAccount, anyValue ]
      )

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 24bfac6df837a0a9660a55a95a716155136c408d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[drortirosh]

Ethershmatchers and viem-assertions have different philosophy on the assertion error output: Matchers deep-dive a single parameter value. Assertions dump the entire expected error (with args) and actual. Personally, I like the latter, so that the assertion is not only a pass/fail value but also give some insight to the cause. If the matcher if a predicate, it can't be displayed this way. Currently it dumps Expected Error(1,ANY,2) But got Error(5,5,2) But with predicate, there is no easy way to display the "expected" array.

I think that the anyValue covers most of the cases. Do you have suggestions?

(Currently, the error strings are not tested at all)

[fvictorio]

Ah, I see your point, but I think these are two separate concerns, right?

On one hand, there's the question of how arguments matchers are implemented. I think the predicate approach is simple and powerful, and it's also consistent with what we already do in chai matchers, so I strongly prefer it.

On the other hand, your point about the diffs is completely valid, but to me it's quite independent from the implementation. We can have better diffs and use the predicates approach. For example, we could show something like:

Expected Error(1,<predicate>,2)
But got Error(5,5,2)

What's more, we could use the name of the predicate if it's not an anonymous function:

Expected Error(1,<predicate: anyValue>,2)
But got Error(5,5,2)

I know implementing this is a bit harder than the hardcoded "ANY" string approach, but this is not something I would do anyway, because that string it's also a valid value. I mean, even if the chances of someone actually having "ANY" as an expected value are tiny... I'd rather avoid the possibility altogether. (We could use a Symbol here instead of a hardcoded string, but we'd lose the simplicity of the implementation and at that point I'd rather go with my preferred predicates approach).

[kanej]

Hey, I am going to close this PR for the moment. We can restart the conversation as an issue initially if that is something we want to pursue.

[drortirosh]

do you have an alternative ? ideally, having "chai matchers" to support viem is the best. any timeline for that?

[fvictorio]

I think we should support predicates in viem matchers asap, because I don't think there's any workaround for ignoring values right now and I can see how that's important.

cc @kanej