Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[style] Use Prettier #626

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

[style] Use Prettier #626

wants to merge 4 commits into from

Conversation

MysteryBlokHed
Copy link
Member

Adds Prettier to format code for the project.

Since some Prettier rules conflict with eslint preferences, the lint script is currently set to run eslint --fix right after Prettier. I've tried to look for Prettier plugins to customize it to the way our code is formatted, but I couldn't find anything.

Because of these differences, the prettier --check command will always return warnings, so we wouldn't be able to enforce Prettier through CI that way. The best idea I have to check formatting with CI would be to just run prettier --write; eslint --fix and make sure that it doesn't produce any unstaged changes.

Also, I've quickly gone through the code and added some // prettier-ignore comments to maintain custom formatting (eg. spacing for matrices), but lmk if I've missed anything 😄

Copy link

netlify bot commented Dec 30, 2024

Deploy Preview for colorjs ready!

Name Link
🔨 Latest commit 672c9a1
🔍 Latest deploy log https://app.netlify.com/sites/colorjs/deploys/6775b74bc5671300086e74da
😎 Deploy Preview https://deploy-preview-626--colorjs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@MysteryBlokHed MysteryBlokHed marked this pull request as ready for review December 30, 2024 20:14
@LeaVerou
Copy link
Member

LeaVerou commented Jan 1, 2025

Thank you for working on this! I haven't yet looked at the individual changes much so this is an overall comment:

Since some Prettier rules conflict with eslint preferences, the lint script is currently set to run eslint --fix right after Prettier. I've tried to look for Prettier plugins to customize it to the way our code is formatted, but I couldn't find anything.

Because of these differences, the prettier --check command will always return warnings, so we wouldn't be able to enforce Prettier through CI that way. The best idea I have to check formatting with CI would be to just run prettier --write; eslint --fix and make sure that it doesn't produce any unstaged changes.

This kind of defeats the purpose.
I think once we have a Prettier config we like we should just get rid of ESLint or only use it in files ignored by Prettier.

Also, I've quickly gone through the code and added some // prettier-ignore comments to maintain custom formatting (eg. spacing for matrices), but lmk if I've missed anything 😄

I know I’m being weird about this, but is there any way we could use comments that don’t depend on any particular tooling? E.g. if in the future we want to switch to a different code formatter, we should not need to go and change all the // prettier-ignore to something else. Basically the actual intent is to say "I'll handle the formatting of this code" not "Prettier specifically should ignore this but other code formatters shouldn't".

Copy link
Member

@LeaVerou LeaVerou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So yeah, rather than calling ESLint fix after Prettier, let's remove ESLint (or dramatically restrict it to only the things that Prettier doesn't touch at all) in this PR and see how we're doing.

E.g. it looks like the space before the opening paren is kept, but I don't know if that's ESLint or our Prettier config.
Same with stroustrup for braces.

@MysteryBlokHed
Copy link
Member Author

is there any way we could use comments that don’t depend on any particular tooling?

Afaik there isn't any sort of tooling-agnostic ignore comment, so we'd just need to replace the comments if ever we wanted to change formatters. It's a bit annoying, but a global find+replace isn't the worst.

So yeah, rather than calling ESLint fix after Prettier, let's remove ESLint (or dramatically restrict it to only the things that Prettier doesn't touch at all) in this PR and see how we're doing.

I just pushed a commit that has the code formatted without running eslint --fix, so the diff can be used to see how the code looks with/without ESLint: 672c9a1

@LeaVerou
Copy link
Member

LeaVerou commented Jan 2, 2025

Are there any Prettier plugins that could help reduce the difference?

Googling a bit everything that comes up seems to imply that Prettier adds a space between function paren by default (e.g. https://prettier.io/blog/2020/03/21/2.0.0.html#always-add-a-space-after-the-function-keyword-3903httpsgithubcomprettierprettierpull3903-by-j-f1httpsgithubcomj-f1-josephfrazierhttpsgithubcomjosephfrazier-sosukesuzukihttpsgithubcomsosukesuzuki-thorn0httpsgithubcomthorn0-7516httpsgithubcomprettierprettierpull7516-by-bakkothttpsgithubcombakkot ) so I'm puzzled why it doesn't here.

And there's a plugin for brace style: https://www.npmjs.com/package/prettier-plugin-brace-style

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants