Add Prettier and recommended ESLint rules.

[jgerigmeyer]

I know these are subjective and I'm very open to changes, but I'm proposing a clearer and more opinionated (and automated) set of style/formatting rules. I see two main advantages:

1. Contributors don't need to expend mental energy trying to determine stylistic expectations.
2. Codebase uses a consistent style, reducing inconsistencies between different files.

(I'd also personally prefer a switch from tabs to 2-spaces, but I'm not looking to start any fights 😅)

@LeaVerou @svgeesus Thoughts?

[LeaVerou]

Hi @jgerigmeyer just a quick note that I'm not ignoring this, just want to prepare a thoughtful response that I have not had time to finish. Thank you for your time and patience!

[jgerigmeyer]

Hi @jgerigmeyer just a quick note that I'm not ignoring this, just want to prepare a thoughtful response that I have not had time to finish. Thank you for your time and patience!

No rush -- I recognize there are often a lot of opinions around this! 😄 I'm not tied to this PR, just wanted to propose it.

[LeaVerou]

Hi again @jgerigmeyer,

I started replying to this PR and it turned into a blog post. Here's a draft: https://lea.verou.me/blog/2023/formatters/
Looking forward to your thoughts!

(I'd also personally prefer a switch from tabs to 2-spaces, but I'm not looking to start any fights 😅)

Curious why would you prefer that over just setting your tab width to 2 so others can still see the code with their preferred tab width?

Happy thanksgiving!

[jgerigmeyer]

(I'd also personally prefer a switch from tabs to 2-spaces, but I'm not looking to start any fights 😅)

Curious why would you prefer that over just setting your tab width to 2 so others can still see the code with their preferred tab width?

Yeah, I think you're right on this 👍

I started replying to this PR and it turned into a blog post. Here's a draft: https://lea.verou.me/blog/2023/formatters/ Looking forward to your thoughts!

@LeaVerou Thanks -- this is a more thought-out response than I anticipated. 😅 I don't have strong feelings, and think your points are valid -- especially for a library like Color.js. Some minor thoughts:

1. You mention a few times that users might not have Prettier installed. This is true for individual local editors (and also true for ESLint), but not relevant for npm run lint.
2. The items in "Formatting is Communication" make sense, but also require detailed description in a codebase style guide if new contributors are going to be able to understand and follow them. In some cases I think Prettier can be a substitute unless/until a more verbose custom style guide is available.
3. Nit: spelling of "Johnny" -> "Jonny" in one location.

I think my view is still that the benefits of Prettier often outweigh the cons, and I lean toward "use Prettier and override it in a few select places as-needed" for most codebases -- but I don't have particular counter-arguments to the issues you raise, and it seems like it's not the right fit for Color.js.

I'll close this PR but leave it intact for historical purposes since it's linked from your blog post, but would you entertain a new PR that expands on the current usage of ESLint and enforces some additional recommended rules?

[LeaVerou]

(I'd also personally prefer a switch from tabs to 2-spaces, but I'm not looking to start any fights 😅)

Curious why would you prefer that over just setting your tab width to 2 so others can still see the code with their preferred tab width?

Yeah, I think you're right on this 👍

Yes! One more converted, we'll get there 😅

I started replying to this PR and it turned into a blog post. Here's a draft: lea.verou.me/blog/2023/formatters Looking forward to your thoughts!

@LeaVerou Thanks -- this is a more thought-out response than I anticipated. 😅 I don't have strong feelings, and think your points are valid -- especially for a library like Color.js. Some minor thoughts:

1. You mention a few times that users might not have Prettier installed. This is true for individual local editors (and also true for ESLint), but not relevant for npm run lint.

Yup, but the argument for Prettier was that contributors don't need to expend mental energy trying to determine stylistic expectations. Unless they have it locally installed, they absolutely do. And yes, that's also true with ESLint.

2. The items in "Formatting is Communication" make sense, but also require detailed description in a codebase style guide if new contributors are going to be able to understand and follow them.

Yup, we should absolutely do that!

In some cases I think Prettier can be a substitute unless/until a more verbose custom style guide is available.

That's where I disagree. I think scannability/readaiblity is more important than consistency, and we can enforce the latter manually in PRs until that style guide is written (and ESLint can help a lot too, so thank you for that other PR!)

3. Nit: spelling of "Johnny" -> "Jonny" in one location.

Oops, sorry, will fix!

I think my view is still that the benefits of Prettier often outweigh the cons, and I lean toward "use Prettier and override it in a few select places as-needed" for most codebases

I think that's the main issue: I’m opposed to adding overrides in the codebase, and with Prettier there is no way around it. At least with ESLint you can remove or relax the rule in question.

-- but I don't have particular counter-arguments to the issues you raise, and it seems like it's not the right fit for Color.js.

I'll close this PR but leave it intact for historical purposes since it's linked from your blog post, but would you entertain a new PR that expands on the current usage of ESLint and enforces some additional recommended rules?

Absolutely, thank you so much!! We'll probably need to iterate a bit, but I totally see this one getting merged eventually.