Ref: previous discussion #3277 (comment)

We have to read through #1026 (the PR that added tabs support) again, because as far as I remember all of this was discussed back then.

When using spaces, Prettier indents with 2 spaces + 1 indent level. When using tabs, there are three ways to go:

• Indent with one tab.
• Indent with two tabs.
• Indent with 2 spaces + 1 tab.

As far as I remember, all of those were discussed with pros and cons, but I don't have the time right now to dig into it.

@ikatyang I'm amazed at the effort you put into this. I recognize that the output indeed looks very nice.

However, the reason the code is the way it is is because <tabs> do not have an intrinsic length.

It looks very nice when you're formatting the code in your machine, with your editor tab length.

But the purpose of tabs is to be tab length agnostic.

When you share your tab indented code with another user who have an different tab length, the code will no longer be perfectly aligned.

That's why it is better to indent only with tabs, and to let the code be a little misaligned.

It seems the trailing part is fine but the middle part should be still transformed into tabs per align?

@ikatyang Ah, the trailing part. It's simple when all you have inside a ternary is an literal, variable or object with simple properties (again, literal and variables).

But it gets messy very fast - inside the object might be another object, an array or even a function, with endless combinations.

That's why I think in useTabs mode, every indentation level must be a <tab>.

Removed the middle part and fixed the nested ternary case, @rhengles I think it should be fine now. If not, could you provide some examples so that I can improve it?

Prettier pr-3745
Playground link

--tab-width 4
--use-tabs

Input:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
?
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
?
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
?
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


a
    ? {
        a: 0
      }
    : {
        a: {
             a: 0
           }
            ? {
                a: 0
              }
            : {
                y: {
                    a: 0
                }
                    ? {
                        a: 0
                    }
                    : {
                        a: 0
                    }
            }
      }

Output:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
	? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
		? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
		: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
	: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;

a
	? {
			a: 0
	  }
	: {
			a: {
				a: 0
			}
				? {
						a: 0
				  }
				: {
						y: {
							a: 0
						}
							? {
									a: 0
							  }
							: {
									a: 0
							  }
				  }
	  };

@ikatyang Ah, I see it now. You only ever put spaces on the closing bracket of an object who is a direct child of the result part of a ternary expression.

Just so we have a comprehensive test case to ensure no regressions, can you add this test case?
Of course no one should ever write code like this, but we have to make sure nothing breaks in the future 😃

a
	? {
			a: function() {
				return a
					? {
							a: [
								a
									? {
											a: 0,
											b: [
												a
													? [
															0,
															1
													  ]
													: []
											]
									  }
									: [
											[
												0,
												{
													a: 0
												},
												a
													? 0
													: 1
											],
											function() {
												return a
													? {
															a: 0
													  }
													: [
															{
																a: 0
															},
															{}
													  ];
											}
									  ]
							]
					  }
					: [
							a
								? function() {
										a
											? a(
													a
														? {
																a: a(
																	{
																		a: 0
																	}
																)
														  }
														: [
																0,
																a(),
																a(
																	a(),
																	{
																		a: 0
																	},
																	a
																		? a()
																		: a(
																				{
																					a: 0
																				}
																		  )
																),
																a()
																	? {
																			a: a(),
																			b: []
																	  }
																	: {}
														  ]
											  )
											: a();
										a(
											a()
												? {
														a: 0
												  }
												: (function(a) {
														return a()
															? [
																	{
																		a: 0,
																		b: a()
																	}
															  ]
															: a(
																	[
																		a
																			? {
																					a: 0
																			  }
																			: {},
																		{
																			a: 0
																		}
																	]
															  );
												  })(
														a
															? function(a) {
																	return function() {
																		return 0;
																	};
															  }
															: function(a) {
																	return function() {
																		return 1;
																	}
															  }
												  )
										);
								  }
								: function() {
										
								  }
					  ];
			}
	  }
	: a;

At first I was like 🤔 and then I was like 😕 but it kinda looks ok so I'll just kill that eslint mixed spaces rule and be like 🤷‍♂️

I appreciate all the effort that has gone into this but wanted to give another view. We recently ran into this issue when prettier got upgraded and are not so excited about the change:

• Our company requires all projects to use tabs
• Our company provides a set of eslint rules to projects, that are not supposed to be overridden
• Prettier can be used by teams/projects if they want to, but this is not mandatory (as it can be too opinionated for some teams, their loss... 😄)

This change doesn't play well with this setup. We cannot disable the ESLint rule related to mixing spaces and tabs (well we can, but we are asked not to).

So for us, that means we would have to stick to the older version of prettier. 😞

@jseminck Is/are the rule/rules auto-fixable?

In that case you can use prettier-eslint to fix the stuff after Prettier formats everything

I am not sure if this is fix-able ( https://eslint.org/docs/rules/no-mixed-spaces-and-tabs ). I will check how that could work. Thanks for the suggestion. 👍

• Our company provides a set of eslint rules to projects, that are not supposed to be overridden
• Prettier can be used by teams/projects if they want to

That sounds like a constant uphill battle to me. Why not allow people to use eslint-config-prettier?

It hasn't caused any problems until now. We have over 100 repositories and having a shared eslint config helps switching from one project to another a bit easier. 😄

Is there any place where I can follow how this decision was made? I just don't understand why spaces are used when the option is specifically set to use tabs (even it looks prettier).

This is the difference that we noticed:

previous:

function test() {
	<other code>

	return isNotLinkedToAnyOrganisation
		? Promise.resolve({ data: { id: null } })
		: api.get(`/endpoint`, {
				method: 'POST',
				body: JSON.stringify({ name: organisation.org_name }),
			});
}

to current:

function test() {
	<other code>

	return isNotLinkedToAnyOrganisation
		? Promise.resolve({ data: { id: null } })
		: api.get(`/endpoint`, {
				method: 'POST',
				body: JSON.stringify({ name: organisation.org_name }),
		  });
}

Tabs only solution could just simply be so, but maybe this was discussed and not chosen due to some other reasons that I am not aware of:

function test() {
        <other code>

	return isNotLinkedToAnyOrganisation
		? Promise.resolve({ data: { id: null } })
		: api.get(`/endpoint`, {
			method: 'POST',
			body: JSON.stringify({ name: organisation.org_name }),
		});
}

Anyway, I don't want to complain 😄Prettier has already saved me so much time and I have come to love it. If this new approach will be the standard then I will find a way to adjust (eslint-config-prettier seems to be the solution), but just wanted to share my view on this particular topic.

As you can see in your example:

function test() {
	const isNotLinkedToAnyOrganisation = false;
	const api = {};
	const organisation = {};

	return isNotLinkedToAnyOrganisation
		? Promise.resolve({ data: { id: null } })
		: api.get(`/endpoint`, {
				method: 'POST',
				body: JSON.stringify({ name: organisation.org_name }),
-			});
+		  });
}

(I'm not sure if everyone's browser display tabs as 4 char width, so here's the screenshot.)

Its alignment looks odd before this PR if your tabs are not displayed as 2 char width, and it's not consistent with space-only:

function test() {
    const isNotLinkedToAnyOrganisation = false;
    const api = {};
    const organisation = {};

    return isNotLinkedToAnyOrganisation
        ? Promise.resolve({ data: { id: null } })
        : api.get(`/endpoint`, {
              method: "POST",
              body: JSON.stringify({ name: organisation.org_name })
          });
}

The only solution I can think of is to add alignment spaces for it, don't know if there's a better one.

(I saw there's a smart-tabs option in ESLint, it should work in this case.)