Support function calls as custom names (to stop false warnings)

[scottmcginness]

Motivation

Hi. I'd like the following sorts of things to be supported, but they actually give errors in the recommended set:

// Say we have a custom function (this one is supposed to ignore tests completely in some situations):
describe.on = (platform) => (process.env.PLATFORM === platform ? describe : (() => {}));

describe('does something', () => {
  before(...);

  // This isn't treated as a suite, so we can get errors about multiple top-level suites, multiple sibling hooks, etc:
  describe.on('windows')('nested', () => {
    before(...); // <- this is treated as a sibling of the above before.
  });
});

and

const forEach = require('mocha-each');

forEach([ 1, 2, 3 ]).describe('works', (n) => {
  before(...); // <- this is treated as a hook at the top level, even though it's nested here.
  it(...);
});

Possible solution

Allow call expressions to have a name when getting the node. It's already the case that dotted names will work and can be specified as custom additional ones.
It's then possible for additionalCustomNames to support names of the form

• { name: 'describe.on()', type: 'suite' },
• { name: 'forEach().describe', type: 'suite' }

so that I can selectively rule these ones in to the set of suites.

Alternatives

• I tried turning off the rule with some eslint-disables but we actually have too many (of the first form I gave in Motivation) to want to do this. And of course, we do want the rules in most places, so globally switching it off isn't suitable.
• In the related PR, my first attempt was to have call expressions with just the name, but this didn't work for the max-top-level-suites rule (because describe.on() and describe.on()(...) had the "same" name)

[lo1tuma]

I think this is a valid use-case. I’ve actually done something very similar many years ago.

[scottmcginness]

Great stuff, thank you!