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

Consider using Prettier #12

Closed
1 task done
ds300 opened this issue Feb 23, 2019 · 6 comments
Closed
1 task done

Consider using Prettier #12

ds300 opened this issue Feb 23, 2019 · 6 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@ds300
Copy link

ds300 commented Feb 23, 2019

  • I'd be willing to implement this feature

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!

@ds300 ds300 added the enhancement New feature or request label Feb 23, 2019
@arcanis
Copy link
Member

arcanis commented Feb 23, 2019

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:

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.

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.

@arcanis arcanis added the help wanted Extra attention is needed label Feb 23, 2019
@ds300
Copy link
Author

ds300 commented Feb 24, 2019

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 ✔️

@arcanis
Copy link
Member

arcanis commented Feb 24, 2019

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!

@ds300
Copy link
Author

ds300 commented Feb 24, 2019

Ah yes that fixes the error I was seeing. Nice one!

@arcanis
Copy link
Member

arcanis commented May 7, 2019

Closing for now (cf discussion in #94 (comment); tldr let's start with autofixable rules rather than prettier and see where it brings us).

@arcanis arcanis closed this as completed May 7, 2019
@crubier
Copy link
Contributor

crubier commented Feb 29, 2020

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants