-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Consider using Prettier #12
Comments
We actually use Prettier in the v1 trunk! I didn't add it here because I tend to dislike some stylistic choices Prettier makes, which didn't put it at the top of my priority list. That being said, the point you make here is completely spot-on:
Given that one of the explicit goals of the project is to encourage external contributors to step in, it only makes sense to decrease the friction as much as possible - and that includes enforcing the style. So if you're willing to add Prettier support to this trunk, go for it! For reference our previous configuration is here. Except for the parser part, I think it makes sense to reuse it. One note: I really want to enforce backticks everywhere, but I'm not sure Prettier can do it - I've seen prettier/prettier#54 but it didn't go anywhere. At the very least I would make sure that adding Prettier won't change all the backtick strings into old style ones. |
I tried setting up eslint + prettier today, but discovered that prettier fails when loaded from a zip. We can fix that by making a PR upstream but that will take time. As a local workaround I tried unplugging prettier. That made it work but the vscode eslint plugin wasn't working even without prettier installed, and I couldn't figure out why. Didn't have much time to debug, but I suspect it's also something to do with pnp. Would working editor integration be a prerequisite for including prettier/eslint in this project? re: backtick strings, prettier will leave those alone ✔️ |
Editor integration isn't needed (we can solve that iteratively), but it would be nice to figure out what's the zip problem. I'm pretty sure I've actually fixed it in prettier/prettier#5819, but it doesn't seem to have been released yet - I'll make a ping! |
Ah yes that fixes the error I was seeing. Nice one! |
Closing for now (cf discussion in #94 (comment); tldr let's start with autofixable rules rather than prettier and see where it brings us). |
Just a quick remark here to say that I recently did my first contribution to yarn, and the absence of prettier actually made it more difficult to get in, which caused @arcanis to have to reformat my code. The goal of prettier is to be a standard, so I think discussing personal readability preferences is irrelevant here, the question is more about: do we want to use the same formatting rules as most big project out there (which use prettier) or do we want custom rules that, as a newbie, I don't really want to learn... |
Prettier is an opinionated code formatter which is widely used in the JavaScript and TypeScript ecosystems. It has a number of important advantages for any software engineering project, documented in fine detail over here: https://prettier.io/docs/en/why-prettier.html
I'll pick out a few of parts that I think are most important for this project:
Enforcing a code style
Prettier is the only way to enforce code style requirements which is 100% automatic. Linters can get most of the way there, but can have trouble folding expressions over multiple lines. Prettier eliminates the need to even think about style during code reviews.
Lowering the bar for new contributors
Learning about the particular idiosyncrasies of a project's code style can be frustrating to new contributors if it is significantly different from what they are accustomed to, raising the bar higher than it needs to be. In addition, for the very large contingent of JS/TS devs who already use prettier every day, having to manually format code can feel like a pointless burden.
In the excellent introduction to the future of Yarn the rationale for moving to TypeScript was given as lowering the bar for contributors. Prettier would be another clear win for that cause.
It will save everybody time when actually writing code
It's staggering how much time one saves with prettier. Just hit a key combination and your code is formatted exactly how it should be ✨. In addition it prevents the mental context switching that happens when formatting code manually. This helps one to focus on solving the actual problems at hand.
Describe the drawbacks of your solution
The main drawback is that the first commit after adding prettier will be a pretty huge diff. In addition people who don't currently use prettier will need to configure their editors to use it, and to become accustomed to it's particular usage patterns and ways of formatting code. In my experience people start to feel like they can't live without it within a week :)
Prettier's output is not always as 'pretty' as one can achieve manually, but it is always readable. Subjectively speaking, the time saved is well worth it. In the extremely rare case that something should be formatted in a particular way, you can tell prettier to ignore particular AST nodes with inline comments.
Thanks for you time ❤️ I cannot wait to start using berry!
The text was updated successfully, but these errors were encountered: