指定の文字数には全然達してないのに 折り返されたり折り返されなかったりして意味がわからないと思っていたら インデントサイズが影響していました

abcd.method({
    a: 1,
}).method()

このコードはフォーマットしてもそのままでしたが abcde にして 5 文字になると

abcde
    .method({
        a: 1,
    })
    .method()

のように折り返されました

別のところに持っていくと
abcd まででも折り返されました
printWidth は同じです

ab.method({
  a: 1,
}).method()

abc
  .method({
    a: 1,
  })
  .method()

理由がわからずバージョンの違いかと思ってバージョンをあわせても同じ挙動
相変わらずの意味不明な挙動と思ってたら tabWidth の違いでした

ab のところが tabWidth を超えると折り返されてるようです
上のときは tabWidth が 4 なので 4 文字の abcd で折り返されず abcde の 5 文字で折り返されていました
下のときは tabWidth が 2 だったので 2 文字で折り返されず 3 文字で折り返されていました
ここの文字数を見る意味がよくわからないです
printWidth に収まってるのですから 気にせず 1 行にまとめてくれればいいのですけど

それよりも タブを使ってるのにタブの幅を見て動作を変えるのはやめてほしいです
タブを使うのは各自がインデント幅を自分の見やすい形にしていて 固定のタブ幅なんていうものはないはずです
相変わらずタブに対する理解のない動きをするんですよね

Prettier 3.1.0 で条件演算子が昔の動きに戻ったと聞いたり 新モードも追加されたと聞いて 試してました
ただ今回の記事の内容は新モードではなく通常モードについてです

Prettier の更新で条件演算子がフラットになる問題が起きて以降 Prettier のバージョンを固定して上げないようにしているプロジェクトがありました
この数年は触れることもなかったので 別フォーマッターに移行せず Prettier のままです
とりあえずこれを通常モードの 3.1.0 にしてみました

差分なしになるのが期待の動作だったのですが 結果は謎のスペースが入るというものでした

[元]

const value = aaaaaaaaaaaaaaaaaaaaaaa
	? bbbbbbbbbbbbbbbbbbbbbb
	: cccccccccccccccccccccc
		? dddddddddddddddddddd
		: eeeeeeeeeeeeeeeeeeee

[フォーマット後]

const value = aaaaaaaaaaaaaaaaaaaaaaa
	? bbbbbbbbbbbbbbbbbbbbbb
	: cccccccccccccccccccccc
	  ? dddddddddddddddddddd
	  : eeeeeeeeeeeeeeeeeeee

インデントにはタブを使っています
元のコードは b, c の行は 1 つのタブで d, e の行は 2 つのタブです
このままが期待するものです

しかしフォーマット後は d, e の行は 1 つのタブとそれに続く 2 つのスペースです
一応 タブサイズは 4 にはしているのに 2 つのスペースのインデントが追加されました

以前 インデントをフラットにした理由の一つにネストが深くなるというのがあるので 浅くしたいというのはわからなくもないですが タブを使ってるときはタブに揃えてもらいたいです
ただ すでに似たような問題としてこういうのがあります

[元]

const value = aaaaaaaaaaaaaaaaaaaaaaa
	? {
		a: 1,
	}
	: {
		a: 2,
	}

[フォーマット後]

const value = aaaaaaaaaaaaaaaaaaaaaaa
	? {
			a: 1,
	  }
	: {
			a: 2,
	  }

これも元のコードが期待するものです
しかしフォーマットすると 「{」 と 「}」 の縦の位置をそろえようとしてスペースが入ります
タブを使用する設定なので 「}」 の前には 1 つのタブと 2 つのスペースです

タブのインデントは見た目を揃える以上に論理的な構造を視覚化するためのものだと思うのですが Prettier 開発者は考えが違うみたいなので仕方ないですね

……と諦めてましたが issues を探してみるとすでに存在して バグ とラベル付けされています
https://github.com/prettier/prettier/issues/15655

修正されるのでしょうか？
今回の変更は 「前の動きに戻す」 というものだったはずなのでそういう意味では意図したものではなさそうですし修正されるのかもしれません
とはいえ 2 つめの例のような問題が残るのなら もうどっちでもいいのですけどね

でもこれをバグとするなら タブを使うモードでテストしてないというわけで やっぱり Prettier 開発者はタブを重視してなさそうです
デフォルトをタブにするという issue にコメントが 450 以上ついてますが これも実現するのか怪しいところがありますね
https://github.com/prettier/prettier/issues/7475

https://sosukesuzuki.dev/posts/prettier-curious-ternaries/

Prettier を使わなくなって結構経つので 最近どんな変化があったかは把握してなかったですが あの微妙な条件演算子のフォーマットが改善されたようです
まだ フラグ付きの実験的導入みたいですが 以前の全フラットよりは良さそうに見えますね

少し試してみようかな

Prettier 2.3 が出たようです
https://prettier.io/blog/2021/05/09/2.3.0.html

相変わらずメジャーアップデートでもないのに これまでのフォーマット済みコードに差分が出るような変更ありです
フォーマッタの都合で余計な差分を出してほしくないですし そもそも変更が改善とは限らないんですよね （以前あった条件演算子のインデントとか）
今回の変更は軽く見た感じだとどっちでもいい部分が多くそこまで困るほどではなさそうですけど

アップデートの影響を受けたくないから結構古いバージョンで使い続けてるところもありますが 古いバージョンのままにしておくと新構文の対応やソースコードが壊れるような重要なバグの修正があったときに これらも受け取れずリスクもあります
構文対応やバグ修正はフォーマットルールとは別に管理して どのバージョンのフォーマットルールを使うかを選択できるようになればまだマシなんですけどね

Prettier は 長く議論が続いていて未だに確定せず意見が分かれるところでも頑なにオプションを導入しませんし
それでいて オブジェクトリテラルでは改行の有無は元のコードを尊重すると言ってるのに 配列リテラルやメソッドチェーンなどの他のところでは改行の有無を保持しないと矛盾もあります
Prettier のニュースを見かけるたびに他に良さそうなフォーマッタが出てないのかと思うほどです

以前から期待の dprint ですが まだ開発中としてバージョン管理下で出力を確認したほうが良いと書かれてる状態です
コミットは頻繁にあるようで 以前からスター数も 2 ～ 3 倍に増えてます
以前は npm からインストールできましたが今では deprecated で インストールスクリプトを使う方法に変わってました
あと JavaScript フォーマッタは TypeScript フォーマッタに統合されて構文的には TypeScript コンパイラがサポートしているものが使えるようです
そんなまだ安定してなさそうな状態ですが deno のデフォルトフォーマッタとして使われてました
それくらい使われてるツールならそろそろ移行先として使い始めようかな

f(1, g(x => 1))

は

f(
	1,
	g((x) => 1)
)

にするのに

foo(0)
	.bar(10)
	.baz(20)
	.qux(30)

は

foo(0).bar(10).baz(20).qux(30)

にするのか