fmt: add config flag #3827
Comments
|
|
|
Hello 👋 I'd like to try and make the case against supporting any form of configurations. Developers all over the world have flocked over to use Prettier to eliminate the headaches and issues caused from having configurations. Far too much time is wasted from having discussions sometimes even heated discussions over code formatting.I think it was said best by Dan I do not believe the reasons suffice to reintroduce all the heated debates and waste of time discussing formatting. Deno has a built-in formatter so why not decide what the best standard of code is as per Denos team and enforce that. Deno should be opinionated on this and that is okay! I propose that Deno should have its standard code formatting and that is that. So long as the formatting is done automatically, most developers will love it or be able to easily adjust to it. |
|
@Skillz4Killz I don't have a strong opinion here on what Deno decides, but I figured I'd give my thoughts on code formatting configuration.
I disagree. By far the biggest reason for adopting Prettier is to have auto-formatting. Adopting auto-formatting eliminates manual developer time spent formatting code and time consuming nitpicky formatting comments in code reviews due to someone not following a coding standard. These benefits are independent of the formatter having configuration. Sure, adding configuration opens the possibility for debates over what options to use, but the amount of time spent on that is minuscule compared to the time savings of an auto-formatter. Side note: As you know, Prettier does have configuration. I think one of its complexity problems is that it has eight different possible places configuration could be loaded from instead of one.
True, but given the option of an opinionated or non-opinionated code formatter, the choice on time savings between the two is debatable. I would bet more time is collectively lost because developers don't use an auto-formatter because Prettier doesn't support the code style they want. For personal projects, it's a joy to be able to get the code to look like the way you personally want. For projects worked on by a group, the group can have a fun meeting to decide if they want to use configuration or not then if so they can talk about what style they'd like. Once the standard is set then it's generally no longer a problem. If heated discussions occur afterwards then that's a development team process failing. In my opinion, the problem with opinionated code formatters is that code style is a personal preference/taste and having configuration allows me to get a result that more closely aligns to my preferences. I'd rather use a formatter that caters to people's personal preferences instead of one that ignores them and imposes the same style on everyone.
I disagree with their opinion. How does this relate to the tragedy of the commons? I'm probably missing something. On configuration inconsistencies, just because it's possible for inconsistencies to exist does not mean there is no solution to that problem. Configuration will be an evolving design. On regressions, a sufficient test suite prevents regressions from being a major problem and if they do occur then the regression gets added to the test suite so its likelihood will be minimized in the future. Regressions can be further mitigated through a design that can handle the possible scenarios. Sure there will be bugs, but again just because there are bugs does not mean there aren't solutions to those bugs.
Again, I'm fine with whatever Deno decides and it's up to the team, but I won't be using an opinionated formatter for my personal projects unless that opinion happens to align with my personal style/taste. From what I've seen, there's a decent percentage of people who share my opinion on this. |
@dsherret Yep, you are 100% right. In theory, this is the ideal scenario. But in reality, this very rarely happens. This is why Prettier blew up and become so widely adopted. People become so used to and accustomed to something that when someone else suggests a different style, it becomes a massive issue in the team. A new developer comes on and begins the discussion all over again with a slight twist. Time and time I have seen this happen and it's just silly. It is just not worth introducing this headache imo.
The auto-formatting has nothing to do with why developers disable linting rules in ESLint and use Prettier for styling. I think the best proof of the reason people use Prettier is best given by Prettier themself.
There are a ton of auto-formatting options. Developers use prettier because it gets rid of the configurations.
From experience, I can tell you this was not the case with my team. The time wasted on configurations is not minuscule. I agree a auto-formatter is necessary. I just don't like having configurations. In one of my teams, we had about 4 different pull requests made every time a developer joined the team about silly stylistic decisions that would begin an endless debate which in the end was completely a waste of time as it is just styling. In fact, I think styling configurations have been the 2nd biggest time waster only second to rewrites/refactors.
As long as formatting is automated, in the end, people stop caring what the specific configuration/options/style/format is. Just format on file save.
A formatter with options vs one without any options. The one with options will always cause you strife in your team. This issue becomes so big that it causes heated discussions between developers and cause the entire JS community to become split so badly that even TV shows make joke about them.
This isn't even possible tbh once your dev setup is complete. There is no way for a dev to commit code without auto-formatting it. Meaning there is no time lost nor is there a choice of formatting when it is auto-formatted.
I disagree with this. If there is a potential for a problem to exist, and there is a way to avoid that problem entirely you should. You could theoretically say this about Typescript. Just because it's possible for mistakes/errors to exist in JS does not mean there is no solution to that problem. Don't use TS. No. This is not the correct logic in my opinion. Typescript solves a problem. Similarly, having no configurations solves a problem.
I am the other way, I don't care what the style of the opinionated formatter is I only care that it's done automatically without options. In my personal projects, I also have some of the craziest setups that 85%+ of developers would disagree with. In my personaly hobby projects, I want to have customization but in a team project I don't. I won't be using a formatter for any of my team/open-source projects if that formatter has options and configurations. From what I've seen and Prettier being the perfect example that an auto-formatter removing configurations is desired by many developers including me.
Prettier has very few configuration options and that is only because of legacy reasons. Also, I don't personally care if we use Prettier or DPrint or whatever. I hope this doesn't make it sound like I'm trying to pitch 1 or the other. Prettier is my example to show that many developers do love the idea of an auto-formatter without configurations.
We now have the option with Deno to prevent even that mistake of having any options in its built-in formatter, which is why I wanted to open this discussion. To be clear, I don't care whether we use Prettier, Linter, DPrint or whatever. My only goal in this discussion is to get Deno to create an opinionated standard for Any dev team should still be able to use their own custom formatting solutions for their project and just not use Thank you! 😄 |
In my opinion, there's no fundamental difference between this and someone making a PR to change formatters to a configurable one and configuring it. Either way you can say "no, that's a waste of time" since everyone seems to agree that it's a waste of time hence why they like Prettier, right? So long as a configurable formatter exists, making an opinionated formatter is the same as choosing a particular configuration and recommending it. We can do that with our defaults. -- The biggest argument for me, and I'm not totally sure how to say this, is that Deno is this big runtime meant to add a bunch of useful native bindings to JS, and there is a philosophical problem with bundling this with a really strong opinion on how your code should look. "Oh, you like our A dedicated third party formatter can be as opinionated as it wants, but an integrated one should consider what it's piggybacking on before deciding whether or not it's really entitled to an opinion... 😅 |
You are right in theory. But in reality, most people just don't do this. I don't have an answer for why, they just don't make this type of PR. But people make massive issues from configurations. I have never personally experienced anyone trying to change the formatter issue to make it configurable. This is one of those in theory vs in reality issues as well.
Yes! Please do this! Keep the defaults locked so they can't be modified by devs.
There is already precedence of this inside Deno already. JS doesn't care but Deno enforces this really strong opinion on how your code should look for your import file paths. Should Deno overcomplicate and cause headaches trying to make import paths without a suffix work? No. Simplicity is beautiful. Deno made a decision and it is a strong one that affects every user. There is nothing wrong with that.
The column limit is only if they use
I slightly agree with this but also disagree with this. Anything can be opinionated as it wants. Even Deno. It is in fact, Denos built in formatter. Deno has the right to be opinionated on that. It is up to the user who uses the formatter to decide which formatter to use. I can make the same argument for the choice of preferring 1 formatter over another internally. Deno should consider the harm it is introducing to teams everywhere by not allowing Prettier and implementing dprint before deciding whether or not it's really entitled to force users to use one or the other. Deno should allow the dev to select any formatter to be used by |
|
@Skillz4Killz the Prettier website may say all that, but they're conflating the benefits of auto-formatting into their argument for minimal configuration. How is formatting configuration a huge time waster? I'm having trouble understanding how having a Could we walk through a scenario? Here's how I imagine it on my team if we decided on the opinionated
Ok how much time was that... maybe 2 hours collectively max? Am I still going to have a problem with this dev opening up PRs to change the formatting? I'm really curious about why this has been a problem on the teams you've been on. Do you have any processes in place for devs making these changes?
Similarly to what @nayeemrmn said, I think you would be happy with the opinionated |
@dsherret I don't think it is fair to make this claim. They provide evidence that can be checked at any time by anyone to show that their statements are accurate. Any claim to the contrary should be backed with evidence. To say that they are wrong without any evidence is not a good logical argument. Auto-formatting can be done with ESLint. People remove a lot of the ESLint rules by integrating Prettier. Prettier's main benefit is getting rid of configuration options which is why it was so heavily adopted. The evidence to prove this is shown on their website.
The problem with your scenario is that it is using an agreeable dev as an example. There are developers who feel very strongly about the smallest of style decisions. To give my self as an example, when I had felt comfortable in my project to speak my mind, I thought it was best to change all our I have since realized the beauty of not caring about styling and just using an opinionated formatter. It saves so much time and effort. The fact of the matter is, people are different and they will prefer different things. Having the option for different things will entice problems in teamwork. This is what prettier solved by removing a ton of configs for formatting. This is why I believe TBF, a valid point can be made that I am biased because of my own experience. So to remove that point, I am going to copy-paste a message someone said on the Gitter recently. This story can be attributed to so many developers around the world and this is the very reason that SJS and Prettier took the world by storm. To end the debates around configurations. One final point is this very topic we are discussing right now. I've probably spent a couple of hours on this already. Debating about configurations regarding formatting/styling is a major waste of time.
The true nature of a man is determined in battle between his conscious mind and his subconscious. And that the evil in my subconscious is too strong to resist. The only way to win is to deny the battle. Having the ability to configure is the entire problem in and of itself. The only way to win is to just avoid the ability to have options. |
Yup.
This seems indicative of systemic issues in the team/company. Those issues won't be solved with/without --config. |
|
@Skillz4Killz from my past experience, ESLint formatting quick fixes have not been as good as Prettier. Plus, in the past some formatting rules had to be manually fixed. I wouldn't consider those tools to be in the same class because Prettier is a complete rewrite of the source file and does a better job. It's also focused specifically on formatting rather than broadly linting.
Not the best example as Prettier doesn't change template literals to string literals or vice-versa. A team with Prettier could agree to only use template literals. Also, I agree with @hayd that these are systemic issues that would exist on that team regardless of whether adding configuration takes one minute instead of two—again, not having a Sidenote: I hope some introspection and changes were done on the team after that dev left in order to prevent that from happening again.
Sure. Just use |
Your 100% right but this isn't an issue of a team or a company but of the industry. The reason that Prettier grew so much is that this issue is widespread. As shown above, any scenario put as a solution is not a solution at all. The only solution is to prevent configuration.
I agree that ESLint formatting is not perfect but it is pretty darn good. A vast amount of projects still use ESLint alone for formatting. There is a very small difference between the ESLint formatter and the prettier formatter. The reason people use prettier over ESLint is not the small difference in its formatting but because it removes the headaches with configs.
That was the point. This is a debate that will never happen with prettier because there is no option for this is prettier.
Copying pasting my response from above because this is the same point made by nayeem above. You are right in theory. But in reality, most people just don't do this. I don't have an answer for why, they just don't make this type of PR. But people make massive issues from configurations. I have never personally experienced anyone trying to change the formatter issue to make it configurable. This is one of those in theory vs in reality issues as well.
Prettier! 🎉
This doesn't prevent the biggest issue of the --config. If you build configs into the built-in formatter you create the potential for wasting time for every team. The built-in formatter should be opinionated without any form of configs. Since I am just copy-pasting my responses now, I don't feel this discussion is being productive and just losing valuable time so let me try another approach. If Deno was to support configs, it should also support the config of having no configs. It should support a config choice to select your formatter so that devs and teams that don't want to allow configs in their projects can do so by using a formatter that does not have options. |
The bottom line is that nothing prevents a dev from changing to a formatter with configuration other than the team enforcing that. You will have the argument for using a formatter with config or no config on a team regardless of what Deno decides. Again, I think the best experience would be for Deno to recognize this choice exists and bring it into the Deno CLI (default and recommend the opinionated
You mean something like |
|
Regardless of whether Deno supports configs or not, it really should support file exclusion from |
|
Deno itself doesn't use the default rustfmt settings, so arguing against at least some configuration options doesn't really make sense. It gets really hard for me to read JS/TS without at least 4 spaces and just adds cognitive load to an already complex task. If a formatting tool is going to lock the indentation I think it should be done with tabs so that people can set the visual indent to whatever they need to code without added stress. I'm not suggesting to use tabs -- just that in cases where a formatter is going to lock indentation, it should only be done with tabs (like in Golang). Prettier is widely used, and the amount of config that it provides works well enough. |
|
I agree that we should try to keep the configurations consistent, but at least like @j127 mentioned tabs should be used to allow people to configure their tab size in their editor. I don't see why tab size has anything to do with the code itself, and this is something that people have strong personal preferences for and could be the difference between someone deciding to use deno fmt or not. |
|
Now that Prettier exists, there is finally a reasonable way to format the code while still allowing enough freedom to adjust the most important preferences. If Deno follows Prettier's configuration model and even were compatible with Indentation is probably the most important thing, but there are other things that should be configurable. Another example: many people like single quotes in JS/TS. But other people mostly code in languages where single quotes and double quotes have different meanings (Rust, Elixir, Haskell, etc.). If you would try to force them to use single quotes for strings, many people wouldn't be happy about going outside of their muscle memory because of someone else's preferences. Other people might have 20 years of muscle memory typing single quotes in JS. A simple setting could keep everyone happy. There are arguments against semicolons ("cleaner looking") and for semicolons ("more readable"). I'd pick "readable" over "clean" but I wouldn't try to stop people from omitting semicolons in their own projects if they want. A language like Go can have a strict formatter because it's starting from scratch (and they made a good decision about using visually-configurable tabs for indentation). JavaScript is already 24 years old, and people already have their own preferences. I think everyone should be left to code in whatever way they like without experiencing stress from needing to fight the tools. |
|
Since dprint now supports config, deno should allow it.. |
|
@j127 Interesting opinion. I think the most important configuration option is to be able to use tabs, as that allows each user to configure the tab width for themselves in their editor. However, the option to choose between single quotes and double quotes doesn't support your argument when working in a team, since you still need each team member to agree - which is unlikely. I think something like this should be consistent (probably double quotes because that is consistent across languages). This does not interfere with muscle memory as typing in a single quote will be corrected to a double quote when the format command is ran. If, visually, one wants to see a single quote instead, I would love to see an editor extension or similar that displays single quotes but saves them as double quotes. My statement above applies to semi-colons too. With that said, I totally agree that there should be a simple setting if dprint supports it. One can always use the defaults if they want. |
That seems like an organizational problem though. Someone has to be the manager or team leader and/or just vote on it or flip a coin. Like dsherret mentioned above, the simplest solution is to say "just use the defaults." Locking the options for everyone because a few people have trouble saying "just use the defaults" doesn't make sense, especially in a language that already has a long history and a huge amount of existing code. There's another team scenario that is worse: everyone on the team enthusiastically agrees on a format that is not the default, but the tool won't let them do it without jumping through hoops.
That still might end up being a terrible amount of friction for some people, because of Git diffs, collaborative editors, and other reasons. The weight of a large project like Deno could start to bend even more tools into not respecting individual projects' preferences. I think that people shouldn’t have to fight with the tools. |
|
2020 and boomers are still adding semis to JavaScript.. it hurts no one to make this configurable, enforce what you like in your project (that includes deno core), prettierrc et al please for the rest of us. |
|
Just gonna leave this right here. |
|
We're using a TypeScript monorepo (react / node with yarn workspaces) and we were all happy with our "semis" and "single quote" handled by one prettier config file at the root until we wanted to bring our brother The dude doesn't want to behave like the rest of its brothers. TL;DR: support prettier-like config please 🙏 |
|
You don't have to use |
|
The discussion in this issue got quite heated - I want to thank every participant for taking part in it. That said... |
|
You can now use the dprint cli to do this (which wasn't available before) https://dprint.dev/cli/ |
|
I don't think there was anything heated about the discussion. Maybe there is a misunderstanding?
Does that dprint CLI mean that you can pass options to deno fmt? |
No, if you want to use config options you need to use dprint rather than deno fmt. |
|
It seems like the decision to close this issue will just encourage people to use other formatting tools that at least offer some basic configuration options. It doesn't make sense to use |
|
Why does formatter collapse multiline imports just because they fit 80 characters on line? (I presume they'll eventually grow.) IMO, it isn't sensible default. |
|
I just want it single quoted and non-semicolon. Should it be that hard ? Explained: |
|
Just wanted to find a way to configure the formatting a little bit... well I guess I won't be using |
|
That is fine - |
|
It makes sense to have opinionated formatting, but to not even give the ability to decide on tab vs. space seems like an unnecessary constraint. The preference war is based on people reading / understanding code in different directions (horizontally vs. vertically) hence having a strong preference without being able to pinpoint why one feels better than the other. I say: release the config flag for |
|
Yesterday I came across a pretty annoying thing with this, and I'd just like to leave the solution to my problem here for reference: I'm using Deno and as part of what I'm doing I'm calling out to imagemagick: const file = "infile.jpg";
const color = "white";
const args = [
"imconvert",
"-gravity", "center",
"-fill", color,
"-background", "transparent",
"-size", "800x",
"-font", "Rubik",
"pic.jpg"
]I want to keep the option flag and its argument on the same line to make it understandable, but then const file = "infile.jpg"
const color = "white";
let args = [
"imconvert",
"-gravity",
"center",
"-fill",
color,
"-background",
"transparent",
"-size",
"800x",
"-font",
"Rubik",
"pic.jpg",
];This annoyed me and made me want to be able to exclude a region from formatting with some magical comments or something, or ask that the formatter generally respect where I place my line-breaks. But actually it was in this instance pretty easy to fix by mirroring the semantic connection with syntactic connection and do this: const file = "infile.jpg";
const color = "white";
const args = [
"imconvert",
["-gravity", "center"],
["-fill", color],
["-background", "transparent"],
["-size", "800x"],
["-font", "Rubik"],
"pic.jpg",
].flat();which |
There’s |
|
I have spent an hour reading and I think I don't need to write from scratch. Credit to yw662, bricecarpentier, and mathiasrw (I want common-tags comma separated list with oxford comma) for trying to prove my point
A lot of people (including me) don't want to custom every single dprint configurations. we just want sensible defaults to avoid bike-shredding and basic configuration. To quote mathiasrw
Some people prefer convention over configuration and I get it. I use discordeno and have to use discordeno convention like snake case file name, camel case variables/functions and whatnot. I just want to use tabs so my team don't have to argue whether 2 spaces or 4 spaces is better, causing navigation mishap in code editor because it thought 2 indents but it's actually 1 or vice versa, 1 indent but it's actually 2. As of writing, |
|
You could probably write a bash function that overrides the default deno () {
if [ "$1" = "fmt" ]; then
echo "run some other formatter with the args: $@"
else
echo "pass this through to the default deno command: $@"
fi
}It could be done with any language, not just a bash function. |
Tracking issue for flags that were removed in #3820, but are useful:
So probably we'd want to bring back 3 flags in total:
--stdoutprint formatted file to stdout instead of writing to disk (mutually exclusive with--check)deno fmt -formats stdin and print to stdout #3920)--ignore-path- do not format/check files specified in this flag, IMHO--excludeis better (and shorter)--config- flag to read config from file - AFAIK dprint does not yet support it (ref feature request: read configuration from file dprint/dprint#69)The text was updated successfully, but these errors were encountered: