Files
oxc-project__oxc/crates/oxc_formatter_graphql/DIVERGENCES.md
leaysgur 3b054de895 fix(formatter_graphql): align comment printing after open { (#26271)
Aligned the handling of line comments immediately following an opening `{`.

(For GraphQL only,) previously kept their own line, now matches other languages by inserting a line break and treating them as leading comments for the next element.

This brings it in line with Prettier's style. The only drawback is that the behavior of `-line` style comments. However, since most of these can be replaced with `-next-line` style comments, we are going to standardize on this consistent behavior for now.

prettier/prettier#1267 (won't fix)
2026-09-03 08:17:35 +00:00

2.6 KiB

Known divergences

Admission reasons and rules: see crates/oxc_formatter_core/FORMATTER_POLICY.md "Known divergences".

comment-after-keyword

  • Why: invariant
  • Pin: tests/fixtures/graphql/comments-inside-node-spans.graphql
# input
"d" type # c
A {
  f: String
}

# ours
"d"
type # c
A {
  f: String
}

# prettier
"d" # c
type A {
  f: String
}

Prettier's attachment pulls the comment backwards across the type keyword (user content) onto the description's line.

own-line-comment-after-description

  • Why: invariant
  • Pin: tests/fixtures/graphql/comments-inside-node-spans.graphql
# input
"d"
# c
type A {
  f: String
}

# ours
"d"
# c
type A {
  f: String
}

# prettier
"d"
type # c
A {
  f: String
}

Prettier's attachment pushes the comment forward across the type keyword (user content), own-line to same-line.

fields-block-opener-comment

  • Why: uniform-rule (same construct, same output: a selection set's { # c)
  • Pin: tests/fixtures/graphql/comment-after-opening-delimiter.graphql
# input
type B implements I @d { # c
  f: Int
}

# ours
type B implements I @d {
  # c
  f: Int
}

# prettier
type B implements I
  @d { # c
  f: Int
}

A comment right after an opening { leads the first item, as in a selection set or schema block (Prettier agrees there: no node precedes the comment inside the parent). In a type / interface / input / enum / extend block the comment follows the name, an interface or a directive, so Prettier's attachment makes it that node's trailing comment and lineSuffix carries it to the line end past {; the breakParent it adds pushes a preceding directive onto its own line.

argument-list-opener-comment

  • Why: invariant
  • Pin: tests/fixtures/graphql/comment-after-opening-delimiter.graphql
# input
query T { a( # c
  x: 1) }

# ours
query T {
  a(
    # c
    x: 1
  )
}

# prettier
query T {
  a(x: 1) # c
}

Prettier's attachment makes the comment a trailing of the field name and lineSuffix carries it past (x: 1) (user content crossed). Same class: query R( # c -> query R($a: Int) { # c, directive @d( # c -> directive @d(a: Int) on FIELD # c.

trailing-comment-before-continuation

  • Why: invariant
  • Pin: tests/fixtures/graphql/comments-inside-node-spans.graphql
# input
type A # c
implements B {
  f: String
}

# ours
type A # c
implements B {
  f: String
}

# prettier
type A implements B { # c
  f: String
}

Prettier's attachment scatters the comment to the line end, across implements B {; same class: f(x) # c + break + : T is pulled inside the parens (x # c before the )), user content crossed in both.