Some codebases use camelCase for enums, some PascalCase. I suspect we should allow both for the default convention.

I'm not sure about this, tbh.
This has been the default since the rule was released (so it's been this way for a few years now) and this is the first time we've had this asked.

Either that means one of:

• not many people use the rule
• not many people use the rule with the defaults
• people use the rule with defaults and are happy with camelCase for enum names

Could do a sourcegraph query of public githubs to roughly determine which it is. If it's the 3rd then making this change would be bad as it would allow inconsistency in codebases - IMO you want one or the other in a codebase - not both.

I agree with @JoshuaKGoldberg that camelCase should be added for backward compatibility reasons.

And for the casing, I searched npm homepage Popular libraries and fronend packages sorted by popularity

I omit any package which does not have built-in typescript (even it as @types/xxx package), also a lot of package does not use enum such as React.

1. Vue: using PascalCase and small ammount of UPPERCASE (shims them to single char in prod) https://github.com/search?q=repo%3Avuejs%2Fcore%20enum&type=code
2. axios: using PascalCase https://github.com/axios/axios/blob/f7adacdbaa569281253c8cfc623ad3f4dc909c60/index.d.cts#L138
3. Preact: camelCase https://github.com/preactjs/preact/blob/9a9967d4edab22581e4f9245741e62452d4b43d2/src/internal.d.ts#L4
4. Vite: both camelCase and PascalCase https://github.com/search?q=repo%3Avitejs%2Fvite%20enum%20language%3ATypeScript%20&type=code
5. Webpack: camelCase https://github.com/search?q=repo%3Awebpack%2Fwebpack%20enum%20language%3ATypeScript%20&type=code
6. Nest.js: UPPERCASE https://github.com/search?q=repo%3Anestjs%2Fnest%20enum%20language%3ATypeScript%20&type=code
7. Grape.js: UPPERCASE camelCase and PascalCase https://github.com/search?q=repo%3AGrapesJS%2Fgrapesjs%20enum%20language%3ATypeScript%20&type=code
8. Cheerio: PascalCase https://github.com/search?q=repo%3Acheeriojs%2Fcheerio%20enum%20language%3ATypeScript%20&type=code
9. Babel: UPPERCASE camelCase and PascalCase https://github.com/search?q=repo%3Ababel%2Fbabel+enum+language%3ATypeScript+&type=code
10. TypeScript: UPPERCASE camelCase and PascalCase, but >80% PascalCase https://github.com/search?q=repo%3Amicrosoft%2FTypeScript+enum+language%3ATypeScript+&type=code
11. Angular: PascalCase mostly, only a small ammount of camelCase https://github.com/search?q=repo%3Aangular%2Fangular%20enum%20language%3ATypeScript%20&type=code
12. VSCode: PascalCase mostly https://github.com/search?q=repo%3Amicrosoft%2Fvscode%20enum%20language%3ATypeScript%20&type=code

For the above repo, only Webpack and Preact is using camelCase enum. Others are all using PascalCase mostly.

A lot of repo includes camelCase (or lowercase) to represent the same keyword strings, e.g.:

const enum Log {
  debug = 'debug',
  info = 'info',
  // ...
}

And some libraries like Vue use UPPERCASE for internal usage of enum to slim package size:

// this is internal and only used to slim pro size
export const enum LifecycleHooks {
  BEFORE_CREATE = 'bc',
  CREATED = 'c',
  BEFORE_MOUNT = 'bm',
  MOUNTED = 'm',
  BEFORE_UPDATE = 'bu',
  UPDATED = 'u',
  BEFORE_UNMOUNT = 'bum',
  UNMOUNTED = 'um',
  DEACTIVATED = 'da',
  ACTIVATED = 'a',
  RENDER_TRIGGERED = 'rtg',
  RENDER_TRACKED = 'rtc',
  ERROR_CAPTURED = 'ec',
  SERVER_PREFETCH = 'sp'
}

enum for other usage are mostly PascalCase, and follows TypeScript docs/blogs syntax.

So I still insist my point @bradzacher, at least PascalCase should be added to defaults. Nobody would expect that codes having the same syntax as TypeScript docs example are "incorrect" with this linter.

Another reason according to my usage, using PascalCase for enum makes it easier to recognize them through codes:

// Probably a class property
Abc.def
// TypeScript enum / const enum
Abc.Def
// object property
abc.def

I also agree to add PascalCase by default. The reason we don't get these requests often is because (a) people don't bother reading the default options and figuring out if they will work well; they just hand-configure them anyway (b) they don't know about conventions and/or they don't read the TS docs, so they trust the default options and they just use camelCase all along since they created the project (c) they don't use enums at all (d) they don't find it meaningful to argue about configurable default options. But I think it's a nice improvement both for developer education and alignment with conventions.

In theory, per #8792, we're feature freezing this rule. It's reached the point of complexity where we're having a hard time justifying working on it.

In practice, I think this is a nice and straightforward enough improvement for users that we can allow it regardless. cc @Josh-Cena