@zombie-mermaid/ascii-renderer 2.2.6 → 3.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zombie-mermaid/ascii-renderer",
-  "version": "2.2.6",
+  "version": "3.1.0",
   "license": "MIT",
   "description": "ASCII and Unicode box-drawing renderer for zombie-mermaid diagrams.",
   "repository": {
@@ -35,7 +35,7 @@
     "LICENSE"
   ],
   "dependencies": {
-    "@zombie-mermaid/core": "2.2.6",
-    "@zombie-mermaid/mermaid-parser": "2.2.6"
+    "@zombie-mermaid/mermaid-parser": "3.1.0",
+    "@zombie-mermaid/core": "3.1.0"
   }
 }

package/src/__tests__/ascii-decision-lr-box-start.test.ts

@@ -14,7 +14,7 @@
  */
 import { describe, it, expect } from 'vitest'
 import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
-import { findOrphanedJunctions } from '../validate.ts'
+import { findOrphanedJunctions } from './validate.ts'
 import { readdirSync, readFileSync } from 'node:fs'
 import { join, dirname } from 'node:path'
 import { fileURLToPath } from 'node:url'

package/src/__tests__/ascii-er-attribute-column-order-1134.test.ts

@@ -0,0 +1,69 @@
+// ============================================================================
+// ASCII ER diagram: attribute columns render as type/name/keys (issue #1134)
+//
+// formatAttribute (src/ascii/er-diagram.ts) used to build "PK type name" —
+// keys, then type, then name — but real mermaid's SVG lays attribute
+// columns out left-to-right as type/name/keys (confirmed against the SVG's
+// attribute-type/attribute-name/attribute-keys x-coordinates in the
+// form-judge report on issue #1119). This file pins the corrected order.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII ER attribute columns render as type/name/keys (issue #1134)', () => {
+  it('renders a single-key attribute as "type name KEY", not "KEY type name"', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        ORDER {
+          int id PK
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('int id PK')
+    expect(ascii).not.toContain('PK int id')
+  })
+
+  it('renders a multi-key attribute\'s keys joined and trailing, e.g. "type name PK,FK"', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        LINE_ITEM {
+          int product_id PK FK
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('int product_id PK,FK')
+    expect(ascii).not.toContain('PK,FK int product_id')
+  })
+
+  it('renders a keyless attribute with no reserved key-column padding', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        CUSTOMER {
+          string name
+        }`,
+      { colorMode: 'none' },
+    )
+    // The pre-#1134 format always reserved a fixed-width 3-space key
+    // prefix ('   ') even when an attribute had no key at all — a keyless
+    // attribute now renders with nothing but its own type/name text, so
+    // the entity's box no longer wastes 3 columns it never needed.
+    expect(ascii).toContain('string name')
+    expect(ascii).not.toContain('   string name')
+  })
+
+  it('keeps a mix of keyed and keyless attributes readable in the same entity', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        CUSTOMER {
+          string name PK
+          string email UK
+          int age
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('string name PK')
+    expect(ascii).toContain('string email UK')
+    expect(ascii).toContain('int age')
+  })
+})

package/src/__tests__/ascii-er-corner-glyphs.test.ts

@@ -57,17 +57,29 @@ describe('ASCII ER relationship routing draws a corner glyph at each turn (issue
     // the detour line, rather than inset into the detour's own row the
     // way the old inset positioning did. Checked separately below instead
     // of assuming they share a row.
-    expect(ascii).toContain('└─────────────── tracks ────────────┘')
+    //
+    // The detour line used to have "tracks" (MIDDLE_ENTITY--FIFTH_ENTITY's
+    // own label, a *different*, vertical relationship) embedded directly in
+    // its dashes, with no separator — the same label-lands-on-a-foreign-line
+    // defect issue #1119 fixes. "tracks" now relocates to its own row next
+    // to its own marker instead.
+    expect(ascii).toContain('└─────────────────│─────────────────┘')
     const lines = ascii.split('\n')
     const detourLineIndex = lines.findIndex((l) =>
-      l.includes('└─────────────── tracks ────────────┘'),
+      l.includes('└─────────────────│─────────────────┘'),
     )
     expect(detourLineIndex).toBeGreaterThan(0)
     // MIDDLE_ENTITY's "tracks" marker ('┼', flush against its own border)
     // sits on the row immediately above the detour line.
     expect(lines[detourLineIndex - 1]).toMatch(/┼/)
+    // "relates_to" (this detour's own label) sits on the row right below it.
+    expect(lines[detourLineIndex + 1]).toContain('relates_to')
     expect(ascii).toContain('relates_to')
     expect(ascii).toContain('tracks')
+    // "tracks" renders next to its own bottom marker ('○╟'), not spliced
+    // onto the unrelated detour line above.
+    const tracksLine = lines.find((l) => l.includes('tracks'))
+    expect(tracksLine).toContain('○╟')
     expect(ascii).not.toMatch(/[a-z]+[─│┊╌][a-z]+/)
   })
 
@@ -155,8 +167,19 @@ describe('ASCII ER relationship routing draws a corner glyph at each turn (issue
     // from a single shared-center bypass to two side-by-side ones; the
     // corner glyphs at the bypass's own turns are still there, just at the
     // updated column.
-    expect(ascii).toContain('┌─│──────────────────┘')
-    expect(ascii).toContain('○╟─────────────────┘')
+    //
+    // These two exact substrings shifted again with issue #1134's ER
+    // attribute-column reorder (type/name/keys instead of keys/type/name):
+    // A/D/G's boxes carry no keyed attributes here, so the old format's
+    // fixed-width key prefix ('   ' when absent) padded every attribute
+    // line by 3 unused columns; the reordered format only emits a key
+    // suffix when a key actually exists, so these now-narrower boxes shift
+    // the bypass's free-column search enough to change both jog rows'
+    // exact shape — each jog's two corners now land on the very same row
+    // (self-contained '┌'...'┘' runs) rather than sharing a row with a
+    // marker glyph the way the pre-#1134 geometry did.
+    expect(ascii).toContain('┌─────────────────────────┘')
+    expect(ascii).toContain('┌────────────────────┘')
     expect(ascii).toContain('ag')
   })
 

package/src/__tests__/ascii-er-relationship-label-corruption-350.test.ts

@@ -451,8 +451,18 @@ describe('ASCII ER relationship routing — multi-row obstruction (CodeRabbit fo
       (l, i) => l.includes('┌') && lines[i + 1]?.includes('│ D'),
     )
     expect(dTopIdx, 'expected to find D’s top-border row').toBeGreaterThan(-1)
-    const dTopLine = lines[dTopIdx]!
-    const afterDBox = dTopLine.slice(dTopLine.indexOf('┐') + 1)
-    expect(afterDBox).toMatch(/[│╢╟○]/)
+    // Issue #1134 reordered ER attribute columns to type/name/keys, dropping
+    // the old format's fixed-width key prefix ('   ' when an attribute had
+    // no key) that every one of A/D/G's keyless attribute lines used to pay
+    // for unconditionally. That narrows all three boxes here enough that the
+    // "ag" bypass no longer needs to jog laterally past D on D's own
+    // top-border row — it now clears D vertically, with its downward-turn
+    // marker landing in the gap row directly above D's box instead. That gap
+    // row is still unambiguously outside D's box (which starts at dTopIdx),
+    // so a connector/marker character there is the same proof as before:
+    // the line was actually routed around D, not silently guarded away
+    // inside it (setCGuarded would leave no trace at all in that case).
+    const gapLine = lines[dTopIdx - 1]!
+    expect(gapLine).toMatch(/[│╢╟○┌└]/)
   })
 })

package/src/__tests__/ascii-er-relationship-overwrite.test.ts

@@ -322,4 +322,111 @@ describe('ASCII ER relationship draws do not overwrite existing text (issue #392
     expect(row![idx - 1]).toBe(' ')
     expect(row![idx + 'authors'.length]).toBe(' ')
   })
+
+  it('renders the "includes" line solid at its crossing with "ships-via", not dashed (issue #1145)', () => {
+    // Real catalog sample ("ER: Mixed Identifying & Non-Identifying").
+    // PRODUCT--LINE_ITEM ("includes", solid — identifying) and
+    // ORDER--SHIPMENT ("ships-via", dashed — non-identifying, detoured
+    // beneath LINE_ITEM which sits between ORDER and SHIPMENT in the same
+    // row) route through the same cell: ships-via's horizontal detour fill
+    // crosses directly through includes' vertical stem just below
+    // LINE_ITEM. setCGuarded now refuses to let a dashed write land on an
+    // already-drawn solid glyph there, so "includes" renders solid at the
+    // crossing rather than picking up ships-via's dash.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        ORDER ||--|{ LINE_ITEM : contains
+        ORDER ||..o{ SHIPMENT : ships-via
+        PRODUCT ||--o{ LINE_ITEM : includes
+        PRODUCT ||..o{ REVIEW : receives`,
+      { colorMode: 'none' },
+    )
+
+    const lines = ascii.split('\n')
+    // ships-via's detour fill sits one row below LINE_ITEM's own
+    // zero-many marker ('╢○', for "includes") — anchoring on that marker
+    // (unambiguous: it's only ever drawn once, at LINE_ITEM's own bottom
+    // edge) rather than searching for a '└...┘' corner pair directly,
+    // since every entity box's own border also has solid corners and a
+    // naive substring search can match those instead (they're a different
+    // row, but a row can contain more than one corner pair).
+    const markerRowIdx = lines.findIndex((l) => l.includes('╢○'))
+    expect(markerRowIdx).toBeGreaterThanOrEqual(0)
+    const detourRow = lines[markerRowIdx + 1]!
+    const detourStart = detourRow.indexOf('└╌')
+    const detourEnd = detourRow.indexOf('╌┘') + 1
+    expect(detourStart).toBeGreaterThanOrEqual(0)
+
+    // includes' own vertical stem (solid '│') crosses this same row exactly
+    // once, between the detour's two corners — that crossing cell must
+    // read as solid, not dashed.
+    const crossingIdx = detourRow.indexOf('│', detourStart)
+    expect(crossingIdx).toBeGreaterThan(detourStart)
+    expect(crossingIdx).toBeLessThan(detourEnd)
+    expect(detourRow[crossingIdx]).toBe('│')
+
+    // And the fill on either side of that crossing is still ships-via's own
+    // dashed glyph — the fix only protects the one style-conflicting cell,
+    // it doesn't let the solid write bleed into its neighbors.
+    expect(detourRow[crossingIdx - 1]).toBe('╌')
+    expect(detourRow[crossingIdx + 1]).toBe('╌')
+  })
+
+  it('never lets a later-drawn dashed relationship line overwrite an earlier solid one at their crossing (issue #1145)', () => {
+    // Same geometry as the sample above (same entities, same connections,
+    // same declaration/draw order — contains, ships-via, includes,
+    // receives), but with which relationship is solid vs. dashed flipped:
+    // "ships-via" is now identifying (solid, "--") and "includes" is now
+    // non-identifying (dashed, ".."). `rel.identifying` only selects which
+    // glyph set a relationship draws with — it doesn't affect any routing
+    // decision (obstruction detection, jog-row search, detour placement) —
+    // so this renders with the exact same cell layout as the original
+    // sample, just with the two relationships' styles swapped. That makes
+    // it a clean, order-preserving way to flip *which* style the
+    // later-drawn relationship carries, without perturbing the routing
+    // itself the way reordering the relationships outright would.
+    //
+    // ships-via (now solid) is still drawn before includes (now dashed) —
+    // same relationship order as above — so before the fix, includes'
+    // later dashed write unconditionally overwrote ships-via's
+    // already-drawn solid detour fill at their crossing cell, opening a
+    // single-character dashed gap in an otherwise solid line: exactly the
+    // "solid stem ends up showing a dashed glyph, purely from draw order"
+    // defect the issue describes. The fix refuses that overwrite, so the
+    // detour fill must now be solid all the way across, with no dashed
+    // character breaking it.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        ORDER ||--|{ LINE_ITEM : contains
+        ORDER ||--o{ SHIPMENT : ships-via
+        PRODUCT ||..o{ LINE_ITEM : includes
+        PRODUCT ||..o{ REVIEW : receives`,
+      { colorMode: 'none' },
+    )
+
+    const lines = ascii.split('\n')
+    // Same anchor as the test above: ships-via's detour fill sits one row
+    // below LINE_ITEM's zero-many marker. Anchoring there (rather than
+    // searching for a '└...┘' pair directly) avoids a false match against
+    // an entity box's own solid border elsewhere in the render — with the
+    // fill itself now solid too (styles swapped for this test), a naive
+    // substring search matches ORDER's own box border instead of the
+    // detour row.
+    const markerRowIdx = lines.findIndex((l) => l.includes('╢○'))
+    expect(markerRowIdx).toBeGreaterThanOrEqual(0)
+    const detourRow = lines[markerRowIdx + 1]!
+    const detourStart = detourRow.indexOf('└─') // index of the '└' corner
+    const detourEnd = detourRow.indexOf('─┘') + 1 // index of the '┘' corner
+    expect(detourStart).toBeGreaterThanOrEqual(0)
+    // Everything strictly between the two corners.
+    const fill = detourRow.slice(detourStart + 1, detourEnd)
+
+    // No dashed glyph ('┊', includes' own now-dashed vertical stem's
+    // style) may appear anywhere inside the solid detour fill.
+    expect(fill).not.toContain('┊')
+    // And the fill is unbroken solid line across its whole span (not, say,
+    // silently dropped to a blank gap instead of dashed — the crossing
+    // cell must still carry a line glyph, just the solid one).
+    expect(fill).toBe('─'.repeat(fill.length))
+  })
 })

package/src/__tests__/ascii-er-stray-connectors.test.ts

@@ -200,10 +200,15 @@ describe('ASCII ER — relationships routed without colliding (issue #351)', ()
     // occupancy before choosing a jog row. Found by a differential search
     // over random small diagrams comparing the old (narrow) and fixed
     // (label-span-widened) occupancy ranges; this is the minimal case that
-    // reproduces it deterministically — DDDD--CCC's jog lands on a row
-    // that BB--A's own label already used, and without the widened check
-    // DDDD--CCC's own label ends up prefixed with a stray "│" bled through
-    // from BB--A's vertical stem.
+    // reproduces it deterministically — DDDD--CCC's jog used to land on the
+    // exact row BB--A's own label ("l1") already used, splicing the two
+    // together into one unbroken run ("l1longerlabelhere2") with no
+    // separator at all.
+    //
+    // Since #1119's fix (a label search also avoids a *different*
+    // relationship's own line, not just its own), DDDD--CCC's label
+    // relocates to its own row instead of sharing BB--A's — so the two
+    // no longer read as a single spliced word.
     const ascii = renderMermaidASCII(
       `erDiagram
         DDDD ||--o{ A : x0
@@ -211,14 +216,15 @@ describe('ASCII ER — relationships routed without colliding (issue #351)', ()
         DDDD ||--o{ CCC : longerlabelhere2`,
       { colorMode: 'none' },
     )
+    expect(ascii).toContain('longerlabelhere2')
+    expect(ascii).toContain('l1')
+    expect(ascii).not.toContain('l1longerlabelhere2')
     const lines = ascii.split('\n')
     const labelLine = lines.find((l) => l.includes('longerlabelhere2'))
     expect(labelLine).toBeDefined()
-    const idx = labelLine!.indexOf('longerlabelhere2')
-    // The characters immediately before the label must be plain fill dashes,
-    // not a stray "│" bled through from an unrelated relationship's
-    // vertical stem sharing this row.
-    expect(labelLine!.slice(Math.max(0, idx - 3), idx)).not.toContain('│')
+    // The label itself must render as one intact, uninterrupted word — not
+    // split by a stray line character routed through its middle.
+    expect(labelLine).not.toMatch(/longer[─│┊╌]/)
   })
 })
 

package/src/__tests__/ascii-fan-in-then-fan-out-upstream-63.test.ts

@@ -0,0 +1,78 @@
+/**
+ * Regression tests for upstream lukilabs/beautiful-mermaid#63: an LR fan-in
+ * followed by a fan-out (`A --> C`, `B --> C`, `C --> D`, `C --> E`).
+ *
+ * Upstream's bug: C->E was routed along B->C's corridor, so B's row rendered a
+ * misleading `├───┴──►E`, as if B pointed at E. The fixed shape has C->E on its
+ * own trunk (`┬` off C's right side, then `└────┐` down to E) while B->C ends
+ * at `┘` under C.
+ *
+ * This fork fixes it through findUnrelatedOverlap / createEdgeCellOwners
+ * (edge-cell-styles.ts) via rerouteAroundStyleConflicts (grid.ts), not by
+ * porting upstream's routing change; these tests pin the rendered outcome, not
+ * the mechanism.
+ */
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+const lines = (s: string): string[] => s.split('\n').map((l) => l.trimEnd())
+
+const SOURCE = `graph LR
+A --> C
+B --> C
+C --> D
+C --> E`
+
+describe('upstream #63: LR fan-in then fan-out keeps C->E off B->C corridor', () => {
+  it('renders C->E on its own trunk (unicode)', () => {
+    expect(lines(renderMermaidASCII(SOURCE, { colorMode: 'none' }))).toEqual([
+      '┌───┐     ┌───┐     ┌───┐',
+      '│   │     │   │     │   │',
+      '│ A ├────►│ C ├──┬─►│ D │',
+      '│   │     │   │  │  │   │',
+      '└───┘     └───┘  │  └───┘',
+      '            ▲    │',
+      '            │    │',
+      '            │    └────┐',
+      '            │         │',
+      '            │         ▼',
+      '┌───┐       │       ┌───┐',
+      '│   │       │       │   │',
+      '│ B ├───────┘       │ E │',
+      '│   │               │   │',
+      '└───┘               └───┘',
+    ])
+  })
+
+  it('B row ends at the corner under C and never reaches E (unicode)', () => {
+    const out = lines(renderMermaidASCII(SOURCE, { colorMode: 'none' }))
+    const bRow = out.find((l) => l.includes('│ B ├'))!
+    // B's edge terminates at exactly one `┘`; nothing horizontal after it.
+    expect(bRow.match(/┘/g)).toHaveLength(1)
+    expect(bRow.slice(bRow.indexOf('┘') + 1)).not.toMatch(/[─├┴┬►]/)
+    // The misleading tee joining B's corridor to E must not appear anywhere.
+    expect(out.join('\n')).not.toContain('┴')
+  })
+
+  it('renders the same shape with the ASCII charset', () => {
+    expect(
+      lines(renderMermaidASCII(SOURCE, { colorMode: 'none', useAscii: true })),
+    ).toEqual([
+      '+---+     +---+     +---+',
+      '|   |     |   |     |   |',
+      '| A +---->| C +--+->| D |',
+      '|   |     |   |  |  |   |',
+      '+---+     +---+  |  +---+',
+      '            ^    |',
+      '            |    |',
+      '            |    +----+',
+      '            |         |',
+      '            |         v',
+      '+---+       |       +---+',
+      '|   |       |       |   |',
+      '| B +-------+       | E |',
+      '|   |               |   |',
+      '+---+               +---+',
+    ])
+  })
+})

package/src/__tests__/ascii-fan-out-upstream-113.test.ts

@@ -0,0 +1,101 @@
+/**
+ * Regression tests for upstream lukilabs/beautiful-mermaid#113 (fixing
+ * upstream issues #111 and #112): ASCII fan-out routing.
+ *
+ * - #111: sibling edges from one source (TB, labelled) must share a single
+ *   horizontal trunk leaving the source's right border, each label sitting on
+ *   its own vertical branch, instead of later edges detouring to a lower row.
+ * - #112: in an LR fan-out, a sibling edge's label widens the source's border
+ *   column; the first edge's box-start connector must stay flush on the
+ *   source box's real border rather than drifting right with the grid cell.
+ *
+ * This fork solves these through edge-bundling / draw-bundles / draw-arrows
+ * rather than porting upstream's pathfinder changes; these tests pin the
+ * rendered outcome, not the mechanism.
+ */
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+const lines = (s: string): string[] => s.split('\n').map((l) => l.trimEnd())
+
+const TD_FANOUT = `flowchart TB
+    Src["Source"]
+    Left["Left Target"]
+    Center["Center Target"]
+    Right["Right Target"]
+    Src -->|left*| Left
+    Src -->|center*| Center
+    Src -->|right*| Right`
+
+const LR_FANOUT = `flowchart LR
+  Src["Source"]
+  Top["Top Target"]
+  Mid["Middle Target"]
+  Bot["Bottom Target"]
+  Src -->|top*| Top
+  Src -->|mid*| Mid
+  Src -->|bot*| Bot`
+
+describe('upstream #111: TB fan-out siblings share one trunk', () => {
+  it('renders the shared trunk with labels on their own vertical branches (unicode)', () => {
+    const out = renderMermaidASCII(TD_FANOUT, { colorMode: 'none' })
+    expect(lines(out)).toEqual([
+      '┌─────────────┐',
+      '│             │',
+      '│    Source   ├─────────────┬─────────────────────┐',
+      '│             │             │                     │',
+      '└──────┬──────┘          center*               right*',
+      '       │                    │                     │',
+      '     left*                  │                     │',
+      '       │                    │                     │',
+      '       │                    │                     │',
+      '       ▼                    ▼                     ▼',
+      '┌─────────────┐     ┌───────────────┐     ┌──────────────┐',
+      '│             │     │               │     │              │',
+      '│ Left Target │     │ Center Target │     │ Right Target │',
+      '│             │     │               │     │              │',
+      '└─────────────┘     └───────────────┘     └──────────────┘',
+    ])
+  })
+
+  it('has exactly one horizontal trunk row off the source border (ASCII)', () => {
+    const out = lines(
+      renderMermaidASCII(TD_FANOUT, { colorMode: 'none', useAscii: true }),
+    )
+    // Box border rows start with '+'; only the source-border row carries a long horizontal run; the buggy
+    // upstream output put a second run (the "right*" detour) on a lower row.
+    const rowsWithRun = out.filter((l) => !l.startsWith('+') && /-{5,}/.test(l))
+    expect(rowsWithRun).toHaveLength(1)
+    expect(rowsWithRun[0]).toMatch(/^\|\s+Source\s+\+-+\+-+\+$/)
+    // No label is stranded on a horizontal segment.
+    expect(out.join('\n')).not.toMatch(/[-─]\/?(center|right)\*[-─]/)
+  })
+})
+
+describe('upstream #112: LR fan-out box-start connector stays on the border', () => {
+  it('places ├ directly under the source box right border column (unicode)', () => {
+    const out = lines(renderMermaidASCII(LR_FANOUT, { colorMode: 'none' }))
+    const sourceRow = out.find((l) => l.includes('Source'))!
+    const borderCol = sourceRow.indexOf('├')
+    expect(borderCol).toBe(out[0]!.indexOf('┐'))
+    // Every row of the source box (top border down to bottom border) agrees
+    // on the border column.
+    expect(out[0]![borderCol]).toBe('┐')
+    expect(out[4]![borderCol]).toBe('┘')
+    // The connector is the border glyph itself, not preceded by a gap.
+    expect(sourceRow[borderCol - 1]).toBe(' ')
+    expect(sourceRow.slice(0, borderCol)).toBe('│ Source ')
+  })
+
+  it('renders the full fan-out with ├ flush on the border (unicode)', () => {
+    const out = renderMermaidASCII(LR_FANOUT, { colorMode: 'none' })
+    expect(lines(out).slice(0, 6)).toEqual([
+      '┌────────┐      ┌───────────────┐',
+      '│        │      │               │',
+      '│ Source ├top*─►│   Top Target  │',
+      '│        │      │               │',
+      '└────┬───┘      └───────────────┘',
+      '     │',
+    ])
+  })
+})