Allow custom matching.

[jamestalmage]

See avajs/ava#1031

The issue arises because users don't necessarily want to use t as their variable name.

Instead of just allowing patterns, it seems possible to allow a more complex matching scheme where implementors can actually use the Babel API for matching.

// Example implementation for AVA

const patterns = [
  't.is(actual, expected, [message])',
  't.not(actual, expected, [message])',
  // ...
];

function isAvaTestCall(callExpression) {
  // figure out if this is a call to AVA's `test` function
}

function isAvaImplementation(functionDeclaration) {
  // figure out if this is a valid test implementation (i.e. function declaration, arrow function) 
}

const matcher = {
  CallExpression: function (path, state) {
    const args = path.get('arguments');
    let param;

    if (isAvaTestCall(path)) {
      if (isAvaImplementation(args[0])) {
        // implementation is the first param (no message)
        param = args[0];
      } else if (isAvaImplementation(args[1])) {
        // implementation is the second param (message is the first)
        param = args[1];
      } else {
        return;
      }

      // The register function is provided as a mixin for your matcher.
      // Registration causes the param to be treated as `t` for the purpose of pattern matching, regardless of what it is actually called by the user.
      this.registerInterestAs(param, 't');
    }
  }
};

const plugin = createEspowerPlugin(patterns, matcher);

[twada]

@jamestalmage Thanks & Understood. I'm going to design it.

[novemberborn]

For our purposes, if we could match <identifier>.assert() that would be sufficient. Currently the pattern must be valid JavaScript. Perhaps we could specify a custom call-matcher instance?