[code-infra] Replace all instances of e with event and add eslint rule

[samuelsycamore]

From the DevEx task backlog: https://www.notion.so/mui-org/core-Replace-all-references-of-event-as-e-event-bc82f57fbe8f4bfea10cc2fcebaee8c5

[mui-bot]

Netlify deploy preview

https://deploy-preview-43866--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against e088fea

[Janpot]

In #41968 I proposed to use the id-denylist rule instead for this purpose

[samuelsycamore]

In #41968 I proposed to use the id-denylist rule instead for this purpose

Oh cool! I missed that conversation. I'll add that here then.

[Janpot]

cc @LukasTy Just a heads up, this will generate new lint errors on X

[Janpot]

Looks good, I would suggest, before merging this, to do the same exercise on the X repo. To avoid monorepo upgrade in X being blocked on code changes.
Did it for toolpad here

[oliviertassinari]

I love to see this 👍

[JCQuintas]

what about specifically targeting function/trycatch parameters?

In x there are some instances of valid use-cases for the e key inside an object, {e} eg: inside the date adapters

    'no-restricted-syntax': [
      'error',
      {
        selector: 'FunctionDeclaration > Identifier[name="e"]',
        message: 'Don\'t use "e" as an identifier, it\'s too easy to confuse with "c" or "o".',
      },
      {
        selector: 'ArrowFunctionExpression > Identifier[name="e"]',
        message: 'Don\'t use "e" as an identifier, it\'s too easy to confuse with "c" or "o".',
      },
      {
        selector: 'CatchClause > Identifier[name="e"]',
        message: 'Don\'t use "e" as an identifier, it\'s too easy to confuse with "c" or "o".',
      },
    ],

[Janpot]

Some drawbacks of that approach is that

• It's cumbersome to add more identifiers than just "e" ("err", "res", "t"), perhaps can be solved by generating those rules dynamically.
• It misses cases such as

  import e from 'foo'
  
  const e = 'foo'

  but we could add two extra rules for these cases

Personally, If we have to add one or two ignore comments, I wouldn't bother complicating it too much. If it's more systemic, then it makes sense to me.

[JCQuintas]

no-restricted-syntax

We can use regex and selectors to make it more generic. I just went with easy ones.

https://eslint.org/docs/latest/extend/selectors

[samuelsycamore]

@JCQuintas I propose we merge this as-is now, and if/when the ignore comments become cumbersome then we should consider implementing the no-restricted-syntax rules.

[JCQuintas]

@JCQuintas I propose we merge this as-is now, and if/when the ignore comments become cumbersome then we should consider implementing the no-restricted-syntax rules.

That works for me