You can roll your own or use a utility library. A simple zero-dependency library would be something like just-* [1]. Although I now prefer remeda [2] as it seems to have the best typescript support, especially the strict variants such as `groupBy.strict`.
Yeah they're not even deprecated really, that's the wrong word. That implies there not actively encouraged to be used. They just moved them to their own repo outside of eslint itself.
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 wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no...
Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?
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):
> 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.
Do you work with a large team? There is no correct answer for formatting for a team, there is only correct answer for individual person. The line limit 80/120/160 will work for certain people with their setup, but not others. Stuff like using a ultrawide screen with two columns, or code on laptop screen with single column, or code with half screen code editor and half screen browser, etc, there are endless mutation, all of them can benefit from different settings. It is essentially not possible to find the best option for everyone on the team. You may think 120 is the best, but there is no way to prove it. It just worked for you because of your coding setup and preference.
I don't care what the limit is unless it's consistently applied.
My least favorite though no limit + soft wrapping, the philosophy being the code adapts to the user, but in actuality means the file looks completely different based on your monitor and setup removing visual aid to code navigation and familiarity.
I work on a ruby/ts/js codebase and seem to recall different file extensions having different line lengths. Something like that is annoying but at least it's more consistent within the file extension
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.
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
I guess Rust made the same reasoning than Python. For this kind of things, the PEP documents tend to be well based on experience and be a good guideline which even applies for other languages. Check the PEP 8 that I linked in my comment: although they recommend a very conservative limit of 80 (79 actually) it says that if it makes sense, 100 (99) can be used too. And that's from 2001.
I understand not wanting to bike shed on the actual number but I refuse to accept 80. I simply do not agree that the greybeards with 70s technology got it figured out perfectly in their day and nothing has changed.
I ignored this point on purpose, to be more succint. But yes, it could be possible to have a soft limit (e.g. 80, or 100) and then you would have to set a hard limit (say, 85 or 105). But in the end you'd end up having someone who complains because their beautiful line was 84 chars and after adding the closing paren and the semicolon, it got wrapped into something that they don't like because subjective tastes.
So in the end, we just moved the goalpost +5 chars.
80 character limit? Are we trying to relive the late 80s. Soon we'll move back to 40 characters. Screens can support higher resolutions now limiting lines to 80 so developers can turn their brains off seems silly. Turn your brain on and learn to filter the noise of 100 characters.
People use ultrawide screen, with half screen dedicated to browser, half screen for code editor, and two columns open in editor. This is very modern setup, and 80 is perfect for it. Don't limit your thinking to your own setup.
I think discussion on the perfect limit on public forum is non-sense. It might be slightly less non-sense to discuss it with your team, but even that I think it is bike-shredding most of the time, unless the entire team for some reason (like they share the same equipment setup and happen to have same preference) overwhelmingly share the sentiment.
> People use ultrawide screen, with half screen dedicated to browser, half screen for code editor, and two columns open in editor. This is very modern setup, and 80 is perfect for it. Don't limit your thinking to your own setup.
It kind of sounds like you're promoting your own setup.
The funny thing I see the most is that people with these crazy widescreen monitors still maximize just one window, with just one file open. Not sure why, maybe for focus?
100 is OK. But better to wager for 80, so people complain about their preferred 120+, and ending up with an acceptable 100 as a middle ground.
On my screen with 1920x1080, 2 side-by-side panels can fit 100 chars, but only if the sidebar is hidden (project layout, list of open files, that kind of stuff).
On my laptop, 2 side-by-side files won't fit if they exceed 90 chars.
I just don't want to concede to those devs who use a single editor pane with an ultrawide monitor, and believe that everybody must work like they do.
These are web developers. Of course they're going to try to force content into a narrow width view and not let you choose to have a wider view even if it makes perfectly valid sense for the given content. These are usability problems that people aren't allowed to make their own decisions about because the UI designer knows the only right answer. "It makes the content more readable" and all that. /s
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.
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.
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.
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.
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.
On the one hand, yes, there should be tests. On the other, `goto fail;` :P
Also, adding braces from the start means that adding one new line of code is a one-line patch, instead of a four-line one - I do that for the same reason that I always put trailing commas on my array definitions
On the flipside, having three trivial early-return ifs at the beginning of a function will become 9 lines long with braces instead of 6 (or just 3, when doing single-line ifs). Very often, such cases never expand to multiple lines in the future.
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?
> 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?
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).
the delta, when prettier is introduced in a project for the first time, not counting +/- whitespace and semicolons (where none existed) isn’t huge. where it matters, the configuration options you get is all that’s necessary.
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/1797837351782e7...
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!
- eslint + prettier doesn't need lots of configuration from the user. You add eslint-plugin-prettier and say `"extends": ["plugin:prettier/recommended"]`
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].
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.
eh -- this is a one-time occurrence with prettier. Subsequent changes are guaranteed to be changes-only since formatting is consistent between authors.
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.
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.
If you're looking for a VS Code extension or a GitHub app, check out https://semanticdiff.com/. I'm a co-founder of this project.
If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.
Is that down to the formatter - which you've configured to enforce a certain line length (https://prettier.io/docs/en/options.html#print-width) - or the diff visualiser that doesn't show a difference between whitespace and other changes?
It's impossible to turn off line length rules. You can only change the width, which means if you set it to a big number it will aggressively unwrap code you want to keep wrapped sensibly. Awful and unacceptable.
I'm in the same boat, currently using Raindrop and looking to switch. I'm currently eyeing Linkwarden as the alternative, but I'm not sure how painless the migration will be.
[1] https://github.com/angus-c/just#just-group-by
[2] https://remedajs.com/docs#groupBy