Skip to content

Change Request: Consider adopting prettier internally #17814

@bmish

Description

@bmish

ESLint version

N/A

What problem do you want to solve?

Forgive me / feel free to close this issue if the answer to this inquiry hasn't changed. I couldn't find a dedicated issue for this discussion so I'm opening one here.

Obviously, prettier is popular in the ecosystem for automatic code formatting.

To date, we have not adopted prettier internally in the ESLint codebase because we want to dogfood our own formatting rules (link to comment):

As a side note, I'd love to see our code formatted with Prettier as well, but there's likely a discussion on GitHub somewhere explaining why we haven't adopted it.

Dogfooding. It's a lot easier to find bugs in formatting rules if we use them exclusively.

However, I'm raising this issue due to some recent developments:

  1. We're on the verge of formatting our markdown docs with prettier: Change Request: autoformat docs #17504
  2. We recently deprecated formatting rules: Change Request: Deprecate formatting rules and recommend using a source code formatter #17522
  3. Formatting/stylistic rules have been frozen since 2020: https://eslint.org/blog/2020/05/changes-to-rules-policies/

What do you think is the correct solution?

These developments could be an opening for us to adopt prettier internally in the ESLint codebase for JavaScript files, as it may be less important to dogfood our formatting rules when they are deprecated and frozen (as well as unit-tested like all rules) and we've already adopted prettier elsewhere.

If now is not the time, then would we consider prettier at any of these future milestones?

  1. When we remove formatting rules in a future major version.
  2. During a future rewrite of ESLint.
  3. Never.

The main downside of adopting prettier is that it would pollute the git blame history for virtually every line in the codebase, although it's possible to workaround that by listing the prettier adoption commit to be ignored in a .git-blame-ignore-revs file alongside git blame --ignore-revs-file .git-blame-ignore-revs.

Participation

  • I am willing to submit a pull request for this change.

Additional comments

No response

Metadata

Metadata

Labels

acceptedThere is consensus among the team that this change meets the criteria for inclusioncoreRelates to ESLint's core APIs and featuresenhancementThis change enhances an existing feature of ESLint

Type

No type

Projects

Status

Complete

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions