fmt: add config flag

[bartlomieju]

Tracking issue for flags that were removed in #3820, but are useful:

@nayeemrmn @ry there are two flags that are not present in this PR that are pretty useful: --stdout and --ignore-path=<FILE...>. Let's do them in follow up PR.

So probably we'd want to bring back 3 flags in total:

• --stdout print formatted file to stdout instead of writing to disk (mutually exclusive with --check) (fmt: deno fmt - formats stdin and print to stdout #3920)
• --ignore-path - do not format/check files specified in this flag, IMHO --exclude is 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)

[nayeemrmn]

--ignore-path is a path to a file listing a bunch of exclude patterns. It's useful alongside --exclude, but maybe not as essential.

[Skillz4Killz]

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.
By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

Far too much time is wasted from having discussions sometimes even heated discussions over code formatting.I think it was said best by Dan

You’re going to be under a lot of pressure to make X, Y, and Z, configurable.
Configuration is a perfect example of tragedy of the commons.

Everybody wants to add just a tiny piece of configuration to satisfy their use case. As a result we end up with inconsistently designed tools, with unexpected combinations that don’t work correctly, with bugs and regressions that, when fixed in one configuration, break something else with another configuration.

The requests for configuration are vocal. The requests to stay simple are often silent.

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.

[dsherret]

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

Developers all over the world have flocked over to use Prettier to eliminate the headaches and issues caused from having configurations. By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

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.

Far too much time is wasted from having discussions sometimes even heated discussions over code formatting.

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.

"Configuration is a perfect example of tragedy of the commons. Everybody wants to add just a tiny piece of configuration to satisfy their use case. As a result we end up with inconsistently designed tools, with unexpected combinations that don’t work correctly, with bugs and regressions that, when fixed in one configuration, break something else with another configuration."

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.

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.

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.

[Skillz4Killz]

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 afterward then that's a development team process failing

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

By far the biggest reason for adopting Prettier is to have auto-formatting.

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.

but the amount of time spent on that is minuscule compared to the time savings of an auto-formatter

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.

True, but given the option of an opinionated or non-opinionated code formatter, the choice on time savings between the two is debatable.

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.

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.

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.

On configuration inconsistencies, just because it's possible for inconsistencies to exist does not mean there is no solution to that problem.

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.

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.

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.

As you know, Prettier does have the configuration. I think one of its complex problems is that it has eight different possible places configuration could be loaded from instead of one.

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

Any dev team should still be able to use their own custom formatting solutions for their project and just not use deno fmt. The built in formatter should be opinionated(another issue can be opened to discuss what are the best options/configs to use for DPrint, as the default settings. Deno has the ability to prevent configurations of deno fmt. This is what I hope to try and keep opinionated.

Thank you! 😄

[nayeemrmn]

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 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 Deno.listen() API? Here's a column limit of 80." They have nothing to do with each other so shouldn't be packaged together so tightly.

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

[Skillz4Killz]

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.

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.

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.

Yes! Please do this! Keep the defaults locked so they can't be modified by devs.

There is a philosophical problem with bundling this with a really strong opinion on how your code should look.

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.

"Oh, you like our Deno.listen() API? Here's a column limit of 80." They have nothing to do with each other so shouldn't be packaged together so tightly.

The column limit is only if they use deno fmt(p.s. I agree 80 is too small). They don't have to. Currently, I still am using Prettier to format my Deno code. It works just fine. Absolutely nothing wrong with any of it. But I would 100% make the switch if Deno were to keep consistant with 1 default formatting standard. If you want to use the built-in Deno formatter it comes as a certain standard.

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

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

[dsherret]

@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 deno fmt --config could potentially be a time waster on your team. I also don't understand how formatting config file changes have historically been the second biggest time waster on your teams.

Could we walk through a scenario? Here's how I imagine it on my team if we decided on the opinionated deno fmt...

1. New dev joins team.
2. Dev unilaterally opens up a PR adding configuration in some way which potentially changes thousands of files because they format differently.
3. I go over talk to dev in person... "hey, we had a vote amongst the team on this already and we're using the opinionated deno fmt command here and not deno fmt --config or some other formatter. We also have a process for introducing coding standard/style changes instead of it being done unilaterally. If you would like to make this change then you could write up a proposal, find a champion, put it for discussion on [internal name for our proposal submission/voting system], and finally the team can vote on this. That said, on the last vote there was pretty strong consensus amongst the team and I doubt any proposal on adding formatting config would pass. Also, think about the negative impact on the git history that PR could have made if approved and merged."
4. Dev: "Sure."

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?

deno fmt opinionated, deno fmt --config unopinionated

I won't be using a formatter for any of my team/open-source projects if that formatter has options and configurations.

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.

Similarly to what @nayeemrmn said, I think you would be happy with the opinionated deno fmt command rather than the non-opinionated deno fmt --config. If not, then why is the existence of a --config flag a problem? Is this about how many keystrokes it takes for someone to add configuration?

[Skillz4Killz]

the Prettier website may say all that, but they're conflating the benefits of auto-formatting into their argument for minimal configuration.

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

Could we walk through a scenario? Here's how I imagine it on my team if we decided on the opinionated deno fmt...

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 ' or " into template literals. I had done my research on it and believed it was the best way to use strings. This began about 3-4 hours long teamwide debate in the channel about whether it was good or bad. Then us going to waste time on performance stuff and continuing down the line just to figure out which style to use since ESLint had the option to allow you to use template literals. I also recall another instance where there was a debate for 6 hours causing one of the developers to leave the team. If I was a developer who is placed in the scenario you just posed, I would have done research(wasting time) opened a discussion(wasting time) and vote(wasting everyone time to read, process, vote) for it giving my thoughts. The vote would ensue and I would begin to question(wasting everyone time to read my reason and respond with their response in a never-ending discussion) every person who voted against it for their reasons and show the reason why I believe their vote was wrong and this would waste everyone time. One day someone on the team showed us all Prettier. I immediately hated it. Hated the idea of it, hated its opinionated philosophy, hated its name. I argued against it for a good amount of time. Eventually, he convinced me to just give it a shot myself and if after a month I don't like it just get rid of it. I tried it and never went back. It felt amazing to be rid of all those configurations. I eventually stopped caring how code was styled.

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 deno fmt should not have any ability to be configured at all. If someone wants to use a custom formatter they should not use deno fmt. Right now, I am using Prettier on my WIP Deno project and I have no issues with it. Formatting/Style is useless to debate about. I would like to switch to using deno fmt but if it is going to be configurable I would never make the switch.

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.

Code formatting is highly subjective, especially in older languages that have never had built in formatter like js. It's the classic bikeshedding topic and sadly many millions of man hours have been lost debating tabs Vs spaces etc. Personally, I've been using standardjs for years now and it's saved a huge amount of time in teams I've worked in. Not having to maintain huge config files and discuss formating is a huge productivity boost

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.

If not, then why is the existence of a --config flag a problem? Is this about how many keystrokes it takes for someone to add configuration?

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.

[hayd]

Formatting/Style is useless to debate about.

Yup.

This began about 3-4 hours long teamwide debate in the channel about whether it was good or bad.

This seems indicative of systemic issues in the team/company. Those issues won't be solved with/without --config.

[dsherret]

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

I thought it was best to change all our ' or " into template literals. I had done my research on it and believed it was the best way to use strings. This began about 3-4 hours long teamwide debate in the channel about whether it was good or bad. Then us going to waste time on performance stuff and continuing down the line just to figure out which style to use since ESLint had the option to allow you to use template literals. I also recall another instance where there was a debate for 6 hours causing one of the developers to leave the team.

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 --config option does not "deny the battle" because it's easy to add a tool to format with configuration... this choice and ability exists regardless.

Sidenote: I hope some introspection and changes were done on the team after that dev left in order to prevent that from happening again.

"Not having to maintain huge config files and discuss formating is a huge productivity boost"

Sure. Just use deno fmt.

[Skillz4Killz]

This seems indicative of systemic issues in the team/company. Those issues won't be solved with/without --config.

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.

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

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.

Not the best example as Prettier doesn't change template literals to string literals or vice-versa.

That was the point. This is a debate that will never happen with prettier because there is no option for this is prettier.

not having a --config option does not "deny the battle" because it's easy to add a tool to format with configuration... this choice and ability exists regardless.

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.

Sidenote: I hope some introspection and changes were done on the team after that dev left in order to prevent that from happening again.

Prettier! 🎉

Sure. Just use deno fmt.

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.

[dsherret]

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 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 deno fmt then have an opt out with deno fmt --config). In my opinion, teams without processes around this choice should not be taken into consideration—they should get their act together.

If Deno was to support configs, it should also support the config of having no configs.

You mean something like deno fmt --no-config? Could just do deno fmt #DO NOT ADD CONFIG on teams with no processes around this and with devs that need a reminder. If Deno ends up without a config option then it sounds like deno fmt #DO NOT CHANGE FORMATTER would work 😉

[tubbo]

Regardless of whether Deno supports configs or not, it really should support file exclusion from deno fmt. In the situation where you have Deno code running alongside front-end JS code (like node_modules/), Deno will attempt to format the node_modules/ dir. The only way I've figured out how to stop it is by doing some advanced shell wildcard globbing, which isn't portable. Not sure any other way to handle this, so having something like deno fmt --exclude=node_modules would be super handy.

[hayd]

@tubbo see also #4459

[j127]

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.

[davidcallanan]

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.

[j127]

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 .prettierrc syntax, I think most people would be happy.

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.

[hayd]

Since dprint now supports config, deno should allow it..

[davidcallanan]

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

[j127]

when working in a team, since you still need each team member to agree - which is unlikely

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.

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.

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.

[tjstebbing]

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.

[humancalico]

Just gonna leave this right here.
"gofmt's style is no one's favorite, yet gofmt is everyone's favorite."

[MaximeBernard]

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 deno in the party.

The dude doesn't want to behave like the rest of its brothers.

TL;DR: support prettier-like config please 🙏

[lucacasonato]

You don't have to use deno fmt on your Deno code. You can use prettier too

[bartlomieju]

The discussion in this issue got quite heated - I want to thank every participant for taking part in it.

That said... deno fmt uses dprint since January without a config flag and current status quo seems seems to work out pretty well. Closing as "wontfix".

[hayd]

You can now use the dprint cli to do this (which wasn't available before) https://dprint.dev/cli/

[j127]

I don't think there was anything heated about the discussion. Maybe there is a misunderstanding?

You can now use the dprint cli to do this (which wasn't available before)

Does that dprint CLI mean that you can pass options to deno fmt?

[hayd]

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.

[j127]

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 deno fmt when it has fewer options than even the formatter it's based on and other formatters like prettier are one-line installs.

[vintprox]

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.

[yw662]

I just want it single quoted and non-semicolon. Should it be that hard ?

Explained:
Single quotes make it easier for embedding HTML and CSS inside JavaScript, as an alternative to back quotes. HTML and CSS use double quotes, so using single quotes in JavaScript is strictly better.
Semicolons make commit history and git diff dirty and less readable, esp. for chaining.

[bricecarpentier]

Just wanted to find a way to configure the formatting a little bit... well I guess I won't be using deno fmt anymore. It is true that "The requests to stay simple are often silent"... that doesn't mean this is a good thing. It just means people will go for another tool.

[lucacasonato]

That is fine - deno fmt is not meant to be everyone's favorite formatting style, but it is a single standard style for everyone. If you really want custom configuration, you can use other fast rust based formatting tools like https://dprint.dev/.

[mathiasrw]

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 deno fmt so we can reach the built-in dprint.

[einarmagnus]

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 deno fmt turns it into this messy thing by putting one element per line:

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 deno fmt keeps like that.

[Liamolucko]

This annoyed me and made me want to be able to exclude a region from formatting with some magical comments or something

There’s // deno-fmt-ignore for that, by the way.

[lts20050703]

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

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 deno fmt when it has fewer options than even the formatter it's based on and other formatters like prettier are one-line installs.

deno fmt based on dprint. What's stopping me from using dprint instead of deno fmt? to quote yw662 and bricecarpentier

I just want it single quoted and non-semicolon. Should it be that hard ?

Just wanted to find a way to configure the formatting a little bit... well I guess I won't be using deno fmt anymore... people will go for another tool.

That is fine - deno fmt is not meant to be everyone's favorite formatting style, but it is a single standard style for everyone. If you really want custom configuration, you can use other fast rust based formatting tools like https://dprint.dev/.

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

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.

release the config flag for deno fmt so we can reach the built-in dprint.

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.
Of course, changing deno fmt default from spaces to tabs would fix my issue, but it's treating the symptoms, not the cause, which is deno fmt do not allow basic configuration.

As of writing, deno fmt canary allows config but I couldn't find anything relating to how to actually config deno fmt

[j127]

You could probably write a bash function that overrides the default deno command. If fmt is the arg, then run dprint or prettier, else just pass the command through to deno.

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.