Allow exceptions to be added to camelcase

[smably]

What rule do you want to change?
camelcase

Does this change cause the rule to produce more or fewer warnings?
Fewer (if the exceptions option is used).

How will the change be implemented? (New option, new default behavior, etc.)?
New option, something like:

"camelcase": ['error', {
  "exceptions": [
    "UNSAFE_componentDidMount",
    "UNSAFE_componentWillReceiveProps",
    "UNSAFE_componentWillUpdate"
  ]
}]

Please provide some example code that this change will affect:

import React from 'react';

class UnsafeComponent extends React.Component {
  UNSAFE_componentWillMount() {
    // deprecated lifecycle code
  }
  render() {
    return <div>FIXME</div>;
  }
}

Demo link

What does the rule currently do for this code?
Errors on UNSAFE_componentWillMount.

What will the rule do after it's changed?
Ignore UNSAFE_componentWillMount even though it's not camelCase.

---

As React deprecates its legacy lifecycle methods, we're going to see a proliferation of the new UNSAFE_-prefixed lifecycle methods. There's currently no good way to ignore these while enforcing camelCase elsewhere.

id-match is one possible workaround, but it results in an ugly and verbose rule that doesn't clearly describe its intent. Compare the proposed camelcase option above to the equivalent id-match rule:

'id-match': [
  'error',
  '^(UNSAFE_componentDidMount|UNSAFE_componentWillReceiveProps|UNSAFE_componentWillUpdate|[a-z]+([A-Z][a-z]+)*)$'
]

This proposal was previously discussed in #9233 but didn't achieve consensus. I think the new option is worth revisiting in the context of React's new lifecycle methods, as it will be a much more frequent pain point for developers.

[platinumazure]

Hi @smably, thanks for creating a new issue.

I could get behind either a list of identifiers or a regular expression. (Maybe we could convert an identifier list into a regex behind the scenes?)

[sindresorhus]

I think it should support Array<string|RegExp>. Strings for the common-case, and RegExp for maximum power. In this case, [/UNSAFE_component.*/] would be much easier.

[AlicanC]

Can't "eslint-plugin-react" solve this issue by disabling camelcase for these, just like "eslint-plugin-prettier" disables style rules?

Also disabling camelcase for all usage doesn't solve this issue correctly. These should still be errors:

const UNSAFE_componentDidMount = 13;

function UNSAFE_componentDidMount() {}

class MySomething extends NotReactComponent {
  UNSAFE_componentDidMount() {}
}

[platinumazure]

I'll champion this.

@eslint/eslint-team Can we review this one? It's pretty popular among the community, allowing the convenience of camelcase while also allowing users to list a small number of exceptions. Hopefully minimal implementation cost.

[nzakas]

I think it's a good idea. I would suggest changing exceptions to allow for better clarity, but otherwise, 👍 .

[hjylewis]

Is someone working on this? I would be happy to take a crack at it.

[platinumazure]

Hi @hjylewis, thanks for reaching out!

It looks like PR #10783 was independently created before this issue and is not quite following the proposal we eventually accepted here. I think I'll ping in that PR and see if they're willing to make the changes to match this issue; if they're busy/don't reply, then you could take a shot.

[hjylewis]

@platinumazure Sounds good!

[platinumazure]

Is this issue resolved with #10783?

[platinumazure]

I'm going to close this as it seems it should be resolved with #10783. Please feel free to leave a comment if that's not the case. Thanks!