[Suggestion] Allow configuring spaces in deno fmt

[grian32]

I understand that this has been brought up(as formatter options, but i think it would include this) before, but please read what I have to say as I believe I have newer and more solid reasoning for this change.

Since a meta/config file(#3179) is on the Q3 2021 Roadmap and Q3 is coming soon, I'd like to bring up adding space amount customizations:

I've decided to bring this up as an issue instead of in #3179 itself because #3179 in particular seems to be targeted at putting current configuration options into a file, and the discussion in that issue seems to have mostly went to a config file format.

The reason I am bringing this up in the first place is that I don't use deno fmt because I am unable to make it format my code with 4 spaces, I will be focusing on that:

Reasoning

• It doesn't make any sense to not allow customizations for such a simple option that has no reason for being as they are in the current settings, the defaults can still be whatever it is now, but it wouldn't hurt anyone to have an option for 4 spaces that, in my experience. doesn't even impact readability.

• It is not some obscure formatting option that is only used by a few people(like having semicolons after a functions closing bracket), it is a formatting option that a lot of people want, like, and want to be able to use with deno fmt

• This wouldn't really change a lot(if anything) in terms of consistency, most people will still use the default, if someone wants to use 4 spaces they will either: 1. Adapt to 2 spaces because they don't have the option; or 2. Use 4 spaces anyway with some other formatter(I've seen projects like this) or manually(me); Not having this option makes people's lives harder(having to adapt to 2 spaces or use a different tool) at no real benefit since there's always going to be projects with 2 spaces and 4 spaces.

• A few people have brought up the option of using Prettier, dprint by itself, or writing my own formatter, I do not want to do that personally and I wouldn't really expect someone if they were working on a project of mine to install prettier or dprint or my own formatter. I understand that the "adapt or go" philosophy(which is whats happening here) is not wanted in the Deno community, and as such, it should not be wanted in the toolchain either, especially as it is a simple change that is wanted by many.

• Some have brought up the argument that it wastes company time and money to decide on formatting options, I do not think this holds up, because it is 1 simple option and as such would not take very long to decide on.

• I do not believe that making this change would force the core team to include small things as an option in deno fmt, because most things in deno fmt are reasonable and have a good reason for them being as they are. If this is wanted and eventually merged, it will be up to core and others to decide if similar options shall get in. Although I do not believe making these kind of decisions will be necessary because there are not many other things that have no reason to be as they are.

• Deno is supposed to be a one-stop shop for all JavaScript needs this, alienizing people like this is not a good way to achieve that goal and make people use Deno as the one-stop shop for their JS needs, this also feeds into my earlier reasoning regarding using prettier or dprint.

Prior Art

• I understand that Deno likes following other projects such as Rust or Go in it's decisions, so I will be listing a few formatters that allow this option, or has other changes that fixes this problem:
  • gofmt: Formats using tabs, this fixes this problem and also allows for better accesibility
  • rustfmt: Has 4 spaces by default, allows changing this amount in rustfmt.toml file
  • Prettier: Allows changing spaces in a .prettierc file

Development/Meeting Time

A few people on discord have brought up the topic of (core's) wasting development and/or meeting time on such simple and opinionated things:

• I am willing to implement this myself, if that is what is needed, and if a PR implementing that will get accepted.
• A meta/config file is already going to be discussed due to proposal: support a comprehensive meta-data file #3179 being on the Q3 Roadmap, and it is a simple addition to that, so I do not think it will take long to discuss.

Discord

I have created a thread on discord in the #dev-fmt channel where there was some discussion related to this:

https://discord.com/channels/684898665143206084/870438916136771614/870438917860651028

[kitsonk]

In a way this is a duplicate of #3695

[bartlomieju]

This was addressed in #11857