`display-name` `ignoreTranspilerName` is too strict

[ljharb]

The purpose of ignoreTranspilerName is to ignore inferred names:

const SFC = () => <div />; // inferred name
const Foo = class extends React.Component {} // inferred name

It should not, however, ignore explicit names:

function SFC() { return <div />; } // explicit name
class Foo extends React.Component {} // explicit name

I think that the ignoreTranspilerName option should be deprecated, and replaced with new options that cover the current use cases:

1. always require an explicit displayName (ignoreTranspilerName: true)
2. only require an explicit displayName on React.createClasses (ignoreTranspilerName: false)

As well as cover these additional use cases:

1. always require an explicit name - ie, an explicit displayName or a named function or named `class
2. always require a name - either explicit, or ES6-inferred
3. Never allow an explicit displayName? (i don't really care about this one, but it seems useful for consistency)

[ljharb]

@yannickcr @lencioni @EvHaus thoughts?

[rodoabad]

Voting for option 2!

[ljharb]

These aren't exclusive options, they're use cases :-) also there's two lists, which "option 2" do you have in mind?

[rodoabad]

@ljharb if it can be inferred then I think not explicitly setting a displayName is fine. Anonymous functions or classes though should still be required to have a display name.

export default function() {
  return <span>{'foo'}</span>;
}

This should throw an error.

[ljharb]

Yes, that's what it's already doing - but in my example, I need "always require an explicit name", because I never want to rely on name inference.

[rodoabad]

@ljharb yeah you're talking about having three options right? I agree to that.

1. Explicit everything.
2. Inferred if possible otherwise you gotta do it bro!
3. Do not set a display name.

This is the one that I like that's why I said I like option 2. Now I just realized it could mean the second item in both those lists. Hahaha. 😭

[chiawendt]

How about "always" | "only-unnamed" | "only-create-class"?

┌────────────────────────────────┬────────┬──────────────┬────────────────────┐
│                                │ always │ only-unnamed │  only-create-class │
├────────────────────────────────┼────────┼──────────────┼────────────────────┤
│ function Cat() {}              │ fail   │  pass        │  pass              │
│ class Cat extends Component {} │ fail   │  pass        │  pass              │
│ export default () => <></>     │ fail   │  fail        │  pass              │
│ exports.Cat = () => <></>      │ fail   │  fail        │  pass              │
│ const Cat = createClass({})    │ fail   │  fail        │  fail              │
└────────────────────────────────┴────────┴──────────────┴────────────────────┘

[ljharb]

@golopot exports.Cat = () => {} doesn't have inference; maybe add const Cat = () => {} which should be fail/fail/pass?

[SevenOutman]

Any update on this? Agree that it should not report positive on SFCs that have explicit names - which is almost every component in 2022.

function DontComplainAboutMyName() {
  return <div></div>;
}

[ljharb]

@SevenOutman it doesn’t report on those, as far as I’m aware. This issue is about reporting on arrow function components that lack inferred names.

[SevenOutman]

it doesn’t report on those, as far as I’m aware.

Oops, turns out it was reporting anonymous arrow function components wrapped with forwardRef. My mistake.