Blocked on azat-io/eslint-plugin-perfectionist#111. We sometimes use comments to delineate specific members of enums.

Edit: no longer ✅

@JoshuaKGoldberg Here is some info that I discovered while working on #8726, that you might find helpful when you begin working on this!

• In eslint.config.mjs, it seems like the pattern is to // register all of the plugins up-front. However, because of an interesting coincidence, this breaks for eslint-plugin-perfectionist:
  For the six existing ESLint plugins where we are using a preset (@typescript-eslint, eslint-plugin-eslint-plugin, jsdoc, jsx-a11y, react-hooks and react), it is unnecessary to register them up front, since those plugins are registered again in the preset. However, it does not break anything either.
  For eslint-plugin-perfectionist, it does break to register it up front in addition to using a preset. The reason is because eslint-plugin-perfectionist has two completely separate JS files — an ESM build and a CJS build. When we import eslint-plugin-perfectionist into eslint.config.mjs, we pull in the ESM build, but inside compat.config() when ESLint pulls in the plugin, it requires it, thus pulling in the CJS build. This causes ESLint to complain that two distinct object references are both trying to register themselves under the name eslint-plugin-perfectionist. By coincidence, none of the six existing double-registered ESLint plugins have this issue.

• As mentioned in Bug(repo): yarn lint-fix in this repository doesn't work on the eslint-plugin package #8733, yarn lint-fix does not work on packages/eslint-plugin. I was unable to determine the root cause of this issue.

• Several files in the root of the repo were either not linted (.github, tools), or not properly ignored from linting (.nx/cache, .yarn/releases)

• yarn lint was very slow due to the build step, which seemed unnecessary for this task. Therefore, I ran eslint directly with caching and progress (DEBUG=eslint:flat-eslint npx eslint . --cache) which seemed much more performant for this task. At times, when autofixing, I had to increase Node's memory with --max-old-space-size.

• Pretty obvious, but I autofixed one rule at a time in order to easily review changes.

• At times, when autofixing, some unrelated things were wrongly autofixed, such as wrongly removing necessary optional chaining or === true/false checks. I'm guessing this is related to something with typed linting, and potentially how I was running ESLint. I did not investigate the root cause, but in any case, I was able to manually revert those bad autofixes with no issues, and re-running lint showed no further issues.

Marking as blocked on the v8 launch because the main <> v8 branch merge conflicts from doing this would be infuriating. 😂

@JoshuaKGoldberg, just curious — what did you end up doing with .git-blame-ignore-revs (#8726 (comment))?

I figured we could add that in after the PRs are merged. We won't know the full list of commit hashes until then. 🤷

Note from #9842 (comment): we'd like to customize the perfectionist/sort-imports groups option at some point.

Edit: #9846 (comment), too.

Notes, too, on bugs or feature requests to file:

• chore: enable eslint-plugin-perfectionist on scope-manager package #9848 (comment): incorrect comment placement
• chore: enable eslint-plugin-perfectionist on rule-tester package #9847 (comment): wanting to not consider quote characters as part of a string in sorting

Suggestion @JoshuaKGoldberg - lets disable sorting on enums.
So much of our codebase is setup with enums sorted by value and sorting by label breaks that really nice value ordering.
EG:

enum BagOfValues {
  Foo = 1,
  Bar = 2,
  Baz = 3,
  Bang = 4,
}

Is much better than

enum BagOfValues {
  Bang = 4,
  Bar = 2,
  Baz = 3,
  Foo = 1,
}

Or for a real example:

Is much better than