Bryan Mishkin

Doing some initial testing on this [branch](https://github.com/bmish/eslint/tree/prettier). 1. Add `.prettierrc.js`: ```js /** @type {import("prettier").Config} */ const config = { arrowParens: "avoid", // Current ESLint style. printWidth: 160, // ESLint sets...

I don't think a precommit hook would be desirable as it would risk polluting PR diffs with formatting changes and result in mixed/inconsistent formatting throughout the codebase. Plus, we can't...

Limiting the automated formatting changes to a separate commit from everything else is a good idea. That makes it easier to ignore those changes for git blame and also easier...

Thinking about this some more, I agree with @nzakas that utilizing the existing `configs` exported object makes sense. Ideally, all configs would be represented in this `configs` object, as they...

The `-legacy` suffix makes sense. But renaming a config to use that suffix is a breaking change. So plugins have needed an intermediary solution for adding flat support--thus some of...

If we don't want to encourage `flat` in any naming, that's OK. The most important point of this ticket is just that all configs are included in the `configs` object....

Omitting this particular format from the documentation and annotating the type with `@deprecated`, assuming removing it is the eventual plan, makes sense to me. I think it's okay to be...

Based on https://lodash.com/per-method-packages, it sounds like it would make sense to switch, would be interested to see a PR.

If we were designing this from scratch, then yeah I'd likely put everything inside the `deprecated` object. I'm leaning toward keeping the two existing properties for backwards-compatibility, but this potential...

Thinking about it some more, perhaps I can just leave `replacedBy` alone as a string array for backwards-compat, possibly deprecating it, while adding the more sophisticated object array version of...