-
Notifications
You must be signed in to change notification settings - Fork 61
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
Use prettier with no config #580
Conversation
I think this makes sense. And I'm fine with merging this all now; I think it's probably less noisy than spreading it across future commits as we touch files, particularly if we use |
Oh, good call, I didn't realize GitHub honored that file automatically if it was present! 🎉 Yeah, I'll add one after merging these that points to the squash commit and just push it to |
use rome instead |
If they ever finish the rest of the toolchain, I would honestly consider it! I love the integrated toolchain approach. As it is, they've replaced the two tools that I think are well served on the ecosystem already by prettier and eslint. |
Going to wait for a few more things to land and then rebase this before merging. |
8798f6d
to
818a4f2
Compare
Alright, this is a little gratuitous, but I think the point of the entire ecosystem adopting prettier is to have a rust-fmt/gofmt kind of experience where you just let the formatter do it's thing without arguing about how to configure it. It turns out, we hadn't been enforcing the other rules for a while and there were already 31 files in violation anyway, so I also introduced a check with prettier to CI to ensure we are consistent going forward. I personally hate these big reformatting commits, and the
--ignore-revs
feature in git is a pain to setup and onboard people into, but I think the pros slightly outweigh the cons here.I don't feel too strongly about this, so if this just feels too noisy, I'm fine with just keeping things as is and fixing formatting as we touch older files.