7 ms·

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wr

• jakub_g 3y ago
  This is indeed the biggest annoyance of mine. I quite often end up rewriting code or changing variable names to counterbalance prettier making code ugly/unreadable.
  • deleted 3y ago
    [deleted]
• tills13 3y ago
  eh -- this is a one-time occurrence with prettier. Subsequent changes are guaranteed to be changes-only since formatting is consistent between authors.
  • c-hendricks 3y ago
    It happens often in JSX, you add one prop, which makes the line longer than the line width, which turns it into a multi line change. It's annoying, but not a reason to throw the baby out with the bathwater.
    • WirelessGigabit 3y ago
      This isn't just a JSX problem. This is in any language that once you go over the column limit that it'll try to break it somewhere.
• ljm 3y ago
  Prettier’s biggest win is that it automates 99% of style complaints away and practically eliminates most classes of nitpicking. But, as well as the issue with line noise, it also encourages patterns that I think detract from code comprehension. It favours expressions over statements and even now, it’s not easy to set a breakpoint in the middle of one, so you end up rewriting into statements just so you can step through. It will favour deeply nested ternary statements in react so your code reads more like a tree with densely tangled roots. It will favour shorthand syntax for optionally merging properties into an object, which basically relies on a quirk of the splat operator. There is fuck all standard library to speak of without pulling in an insane amount of dependencies, but surely stuff like deep merge and compact should be provided out of the box?
  • tubthumper8 3y ago
    > It favours expressions over statements and even now, it’s not easy to set a breakpoint in the middle of one, so you end up rewriting into statements just so you can step through. I've never had an issue setting an inline breakpoint[1] in VS Code, is it an issue in other IDEs? [1] https://code.visualstudio.com/Docs/editor/debugging#_inline-breakpoints https://code.visualstudio.com/Docs/editor/debugging#_inline-...
    • ljm 3y ago
      I use emacs, but chrome/firefox are a bit finicky about where you can set a breakpoint. (Most people I know just use console.log - print debugging works all the time but I like having a repl)
  • yawboakye 3y ago
    does it? prettier is extremely configurable, unlike gofmt. so deferring to the authority of prettier is essentially deferring to the authority of the prettier.yml config. not that i have a problem with that _per se_, i’d expect the author(s) to take responsibility and appreciate that they’re defining/imposing their own taste(s).
    • nicoburns 3y ago
• SamBam 3y ago
  It's not really an issue if you do a one-time Prettification commit, and then stick to Prettifying automatically thereafter. Then you won't ever see line-width changes mixed in with functional changes. Isn't this an issue with every linter? At some point you're going to have to decide what to do with old code that doesn't match the new style rules.
  • richardwhiuk 3y ago
    > Then you won't ever see line-width changes mixed in with functional changes. You will - every time you extend a line which now exceeds the limit.
    • twicetwice 3y ago
      Isn't this a natural consequence of having line length limits? This seems like a general problem, not a problem with Prettier.
      • richardwhiuk 3y ago
        Sure
      • francislavoie 3y ago
        It's an issue with prettier because it cannot be disabled.
  • lainga 3y ago
    Sure you will. Whoops, my regex got too long and now the diff is - filter: /\.(jimmy|jimbo|jeremiad)$/ + filter: + /\.(jimmy|jimbo|jeremiad|james)$/ . And it's not clear where the change is. GP's article has an example of that in a linked tweet.
    • JasonSage 3y ago
      This is fine for a text diff, but I want my code review tool to show me something different. Separate problem, and the flaw here isn’t the diff, or the tool that produced the diff, rather the tool displaying it to me. Let me do whatever I want to my code and show me BOTH the visual (unimportant) and semantic differences.
• j1elo 3y ago
  I'd rather have a strict line length limit, than having my coworker creating objects in lines 150 or 180 chars long. So we'd end up discussing what is the best choice. I bet I'd also end up discussing those things with Anthony Fu. If the limit is 80, then the limit is 80, not 81. Come Prettier. No more discussions. I definitely buy the tiny amount of "noise" it brings, in exchange for freeing me from an immense amount of actual noise when having to discuss these things with other people. EDIT: This comes from a backend dev (C/C++, sometimes Go, recently did some stuff with TypeScript). Prettier was a refreshing discovery, and other languages like Python are able to express the rule very sensibly (albeit I round it and go for 80 or 100): https://peps.python.org/pep-0008/#maximum-line-length https://peps.python.org/pep-0008/#maximum-line-length
  • nicoburns 3y ago
    > If the limit is 80, then the limit is 80, not 81. I agree with that. But the limit should be 120 or 160, not 80 (and my formatter should allow me to set a wider limit like that without making all my lines extra-wide - I want to be able to put things on one line where appropriate and not where it's not). > I definitely buy the tiny amount of "noise" it brings Tiny? It makes a lot of my code 3-5x as long. And often breaks things in weird places. This is IMO not a small reduction in readability.
    • j1elo 3y ago
      Like I mentioned to the sibling parent, 100 is an OK middle ground. 120, or more, is too long already, and 160 is waaaay beyond what I'd consider acceptable. No way you can fit 2 side-by-side editor panes with those line lengths, unless you use a tiny sized font. I get it, 160 looks OK and fits into a 4K display without any other windows open. I believe working with dual panes is more productive, so I'll always stand behind shorter line lengths that allow for it. Even Rust, a modern language that is usually said to collect the best learnings from the industry, thankfully chose a conservative and sensible 100 chars limit by default.
      • culi 3y ago
        I wasn't aware Rust chose a 100 line default. I'll definitely be using this to argue on my teams for why we should stretch the line length limit past 80. Thank you Rust for moving the industry forward
• c-hendricks 3y ago
  Some things overlooked in that blog post for others to take into consideration: - eslint only works on javascript + typescript (eslint + typescript needs _more_ configuration than eslint + prettier), while prettier works on https://github.com/prettier/prettier/blob/03ebc7869dc9e8f2fc9810ca33f288152243c598/docs/index.md?plain=1#L8-L20 https://github.com/prettier/prettier/blob/03ebc7869dc9e8f2fc... - eslint + prettier doesn't need lots of configuration from the user. You add eslint-plugin-prettier and say `"extends": ["plugin:prettier/recommended"]`
  • thenbe 3y ago
    By default, eslint only lints files with a .js extension[1]. Eslint plugins are what allow eslint to support more languages. A list can be found here[2]. For the record, prettier can also be extended to support more languages[3]. [1] https://eslint.org/docs/latest/use/command-line-interface#--ext https://eslint.org/docs/latest/use/command-line-interface#--... [2] https://github.com/dustinspecker/awesome-eslint#plugins https://github.com/dustinspecker/awesome-eslint#plugins [3] https://prettier.io/docs/en/plugins#official-plugins https://prettier.io/docs/en/plugins#official-plugins
• varrock 3y ago
  Specifically for reviewing a pull request in GitHub, wouldn't the "Hide whitespace" setting reduce some of this noise? I could be mistaken, though, but that's how I interpreted that setting. 0: https://github.blog/2011-10-21-github-secrets/ https://github.blog/2011-10-21-github-secrets/
  • sltkr 3y ago
    This is often useful, but JavaScript specifically has the annoying property that newlines can be semantically meaningful. For example, if someone changes: function isUserBanned(username) { return db.findUserByName(username)?.banned; } To: function isUserBanned(username) { return db.findUserByName(username)?.banned; } you want to see that diff because the second version always returns undefined. If you ignore whitespace changes entirely, it becomes possible for people to sneak in bugs intentionally or unintentionally.
    • tharkun__ 3y ago
      Enforce semicolons.
    • chris_wot 3y ago
      gawd and this is why the semicolon debate wasn't just bike shedding.
    • HALtheWise 3y ago
      How much does prettier formatting help here for practical cases? In particular, if the autoformatter allowed that second example with the indentation on the last line, I'd treat that as an autoformatter bug.
    • blauditore 3y ago
      That's technically true, but extrememly rare to cause real problems (short of bad intent). It reminds me of people/teams enforcing braces on single-line ifs, because one might add another line someday, forget to add braces, and break the logic. Even when it happens, there should still be tests that catch this.
• IshKebab 3y ago
  That's not an issue with Prettier; it's an issue with having a consistent style and not using syntax aware diff tools.
• adam_arthur 3y ago
  Yes, Prettier largely won by not having many competitors strictly focused on formatting in a simple to consume package. I don't think many people who are serious about high "signal to noise" code formatting are supportive of the design decisions prettier makes. e.g. the staggered import lines, left-shifting and up-shifting of implementation details, not allowing trailing comments on the same line We can have consistent formatting and also avoid tons of visual noise that prettier produces... I've wanted to build a competing solution for awhile, but never made the time for it. Perhaps Anthony's project achieves that... I'll give it a try!
• Cthulhu_ 3y ago
  It's not a dichotomy though; performance is imo essential for a tool that will run on every save, every commit, every pull request. It might be fast enough, but adding all runs up adds up to a lot of unnecessary energy waste. With regards to the whitespace issue, that's down to the line length rules used I think. It's also down to the diff viewer how to show it, not the formatter.
• dsherret 3y ago
  You can already mostly do this with dprint's TypeScript plugin if you tweak the config (and I'm open to adding more config to support this scenario in case something is missing). For example, the TypeScript team uses a line limit of 1000: https://github.com/microsoft/TypeScript/blob/1797837351782e7f7ea9b23a1fceb027094b38db/.dprint.jsonc#L3 https://github.com/microsoft/TypeScript/blob/1797837351782e7...
• deleted 3y ago
  [deleted]