zombie-mermaid 2.2.1 → 2.2.2

package/src/__tests__/statements.test.ts

@@ -15,13 +15,18 @@ import { describe, it, expect } from 'vitest'
 import { splitStatements, detectDiagramType } from '@zombie-mermaid/core'
 import { renderMermaidASCII, renderMermaidSVG } from '../index.ts'
 
+/** Project a `splitStatements` result down to just the text, for assertions
+ * that don't care about position (see the dedicated `line` tests below for
+ * position coverage). */
+const texts = (source: string) => splitStatements(source).map((s) => s.text)
+
 describe('splitStatements (issue #181)', () => {
   it('splits on newlines', () => {
-    expect(splitStatements('graph TD\nA-->B')).toEqual(['graph TD', 'A-->B'])
+    expect(texts('graph TD\nA-->B')).toEqual(['graph TD', 'A-->B'])
   })
 
   it('splits on semicolons', () => {
-    expect(splitStatements('graph TD;A-->B;B-->C')).toEqual([
+    expect(texts('graph TD;A-->B;B-->C')).toEqual([
       'graph TD',
       'A-->B',
       'B-->C',
@@ -29,59 +34,53 @@ describe('splitStatements (issue #181)', () => {
   })
 
   it('drops empty statements from trailing or repeated separators', () => {
-    expect(splitStatements('graph TD;A-->B;')).toEqual(['graph TD', 'A-->B'])
-    expect(splitStatements('graph TD;;;A-->B')).toEqual(['graph TD', 'A-->B'])
-    expect(splitStatements('graph TD\n\n\nA-->B')).toEqual([
-      'graph TD',
-      'A-->B',
-    ])
+    expect(texts('graph TD;A-->B;')).toEqual(['graph TD', 'A-->B'])
+    expect(texts('graph TD;;;A-->B')).toEqual(['graph TD', 'A-->B'])
+    expect(texts('graph TD\n\n\nA-->B')).toEqual(['graph TD', 'A-->B'])
   })
 
   it('trims whitespace around each statement', () => {
-    expect(splitStatements('  graph TD  ;  A-->B  ')).toEqual([
-      'graph TD',
-      'A-->B',
-    ])
+    expect(texts('  graph TD  ;  A-->B  ')).toEqual(['graph TD', 'A-->B'])
   })
 
   describe('does not split a semicolon that is not a separator', () => {
     it('inside a double-quoted label', () => {
-      expect(splitStatements('graph TD\nA["a; b"]-->B')).toEqual([
+      expect(texts('graph TD\nA["a; b"]-->B')).toEqual([
         'graph TD',
         'A["a; b"]-->B',
       ])
     })
 
     it('inside a single-quoted label', () => {
-      expect(splitStatements("graph TD\nA['x; y']-->B")).toEqual([
+      expect(texts("graph TD\nA['x; y']-->B")).toEqual([
         'graph TD',
         "A['x; y']-->B",
       ])
     })
 
     it('terminating a named character reference', () => {
-      expect(splitStatements('graph TD\nA[&]-->B')).toEqual([
+      expect(texts('graph TD\nA[&]-->B')).toEqual([
         'graph TD',
         'A[&]-->B',
       ])
     })
 
     it('terminating a numeric character reference', () => {
-      expect(splitStatements('graph TD\nA[#]-->B')).toEqual([
+      expect(texts('graph TD\nA[#]-->B')).toEqual([
         'graph TD',
         'A[#]-->B',
       ])
     })
 
     it('terminating a hex character reference', () => {
-      expect(splitStatements('graph TD\nA[😀]-->B')).toEqual([
+      expect(texts('graph TD\nA[😀]-->B')).toEqual([
         'graph TD',
         'A[😀]-->B',
       ])
     })
 
     it('but still splits a real separator on the same line as an entity', () => {
-      expect(splitStatements('graph TD;A[&]-->B;B-->C')).toEqual([
+      expect(texts('graph TD;A[&]-->B;B-->C')).toEqual([
         'graph TD',
         'A[&]-->B',
         'B-->C',
@@ -90,26 +89,20 @@ describe('splitStatements (issue #181)', () => {
 
     it('and treats a lone ampersand as an ordinary character', () => {
       // `A & B` is flowchart's parallel-link syntax, not an entity.
-      expect(splitStatements('graph TD;A-->B & C')).toEqual([
-        'graph TD',
-        'A-->B & C',
-      ])
+      expect(texts('graph TD;A-->B & C')).toEqual(['graph TD', 'A-->B & C'])
     })
   })
 
   describe('comments', () => {
     it('drops whole-line comments without splitting their semicolons', () => {
-      expect(splitStatements('graph TD\n%% note; not code\nA-->B')).toEqual([
+      expect(texts('graph TD\n%% note; not code\nA-->B')).toEqual([
         'graph TD',
         'A-->B',
       ])
     })
 
     it('drops a comment that only begins after a semicolon', () => {
-      expect(splitStatements('graph TD\nA-->B; %% note')).toEqual([
-        'graph TD',
-        'A-->B',
-      ])
+      expect(texts('graph TD\nA-->B; %% note')).toEqual(['graph TD', 'A-->B'])
     })
 
     it('lets the comment swallow the rest of the line', () => {
@@ -118,14 +111,14 @@ describe('splitStatements (issue #181)', () => {
        * resurrect what follows. Splitting first and then discarding fragments
        * that merely begin with `%%` left `C-->D` parsing as code.
        */
-      expect(splitStatements('graph TD\nA-->B; %% note; C-->D')).toEqual([
+      expect(texts('graph TD\nA-->B; %% note; C-->D')).toEqual([
         'graph TD',
         'A-->B',
       ])
     })
 
     it('treats %% inside a quoted label as text, not a comment', () => {
-      expect(splitStatements('graph TD\nA["100%% done"]-->B')).toEqual([
+      expect(texts('graph TD\nA["100%% done"]-->B')).toEqual([
         'graph TD',
         'A["100%% done"]-->B',
       ])
@@ -144,14 +137,11 @@ describe('splitStatements (issue #181)', () => {
       ['A[heart #9829; x]-->B', 'a symbol reference'],
       ['A[say #quot;hi#quot;]-->B', 'a named reference'],
     ])('keeps %s intact (%s)', (statement) => {
-      expect(splitStatements(`graph TD\n  ${statement}`)).toEqual([
-        'graph TD',
-        statement,
-      ])
+      expect(texts(`graph TD\n  ${statement}`)).toEqual(['graph TD', statement])
     })
 
     it('still splits a real separator on the same line as one', () => {
-      expect(splitStatements('graph TD;A[#59;]-->B;B-->C')).toEqual([
+      expect(texts('graph TD;A[#59;]-->B;B-->C')).toEqual([
         'graph TD',
         'A[#59;]-->B',
         'B-->C',
@@ -159,7 +149,7 @@ describe('splitStatements (issue #181)', () => {
     })
 
     it('leaves a bare # that is not a reference alone', () => {
-      expect(splitStatements('graph TD;A[C# lang]-->B')).toEqual([
+      expect(texts('graph TD;A[C# lang]-->B')).toEqual([
         'graph TD',
         'A[C# lang]-->B',
       ])
@@ -167,6 +157,34 @@ describe('splitStatements (issue #181)', () => {
   })
 })
 
+describe('splitStatements — line numbers (issue #760)', () => {
+  it('reports the 1-based physical source line for each newline-separated statement', () => {
+    const stmts = splitStatements('graph TD\nA-->B\nB-->C')
+    expect(stmts.map((s) => s.line)).toEqual([1, 2, 3])
+  })
+
+  it('carries forward the original line number across dropped blank lines', () => {
+    const stmts = splitStatements('graph TD\n\n\nA-->B')
+    expect(stmts.map((s) => ({ text: s.text, line: s.line }))).toEqual([
+      { text: 'graph TD', line: 1 },
+      { text: 'A-->B', line: 4 },
+    ])
+  })
+
+  it('carries forward the original line number across a dropped comment line', () => {
+    const stmts = splitStatements('graph TD\n%% a comment\nA-->B')
+    expect(stmts.map((s) => ({ text: s.text, line: s.line }))).toEqual([
+      { text: 'graph TD', line: 1 },
+      { text: 'A-->B', line: 3 },
+    ])
+  })
+
+  it('gives every semicolon-separated statement on one physical line the same line number', () => {
+    const stmts = splitStatements('graph TD\nA-->B;B-->C;C-->D')
+    expect(stmts.map((s) => s.line)).toEqual([1, 2, 2, 2])
+  })
+})
+
 describe('semicolon-separated diagrams render their bodies (issue #181)', () => {
   const cases = [
     {

package/src/__tests__/testdata/ascii/subgraph_direction_override.txt

@@ -16,27 +16,27 @@ B --> Y
     |
     |
     |
-+---|---+
-|LR Grou|
-|   |   |
-|   v   |
-| +---+ |
-| |   | |
-| | A | |
-| |   | |
-| +-+-+ |
-|   |   |
-|   |   |
-|   |   |
-|   |   |
-|   v   |
-| +---+ |
-| |   | |
-| | B | |
-| |   | |
-| +-+-+ |
-|   |   |
-+---|---+
++---|----+
+|LR Group|
+|   |    |
+|   v    |
+| +---+  |
+| |   |  |
+| | A |  |
+| |   |  |
+| +-+-+  |
+|   |    |
+|   |    |
+|   |    |
+|   |    |
+|   v    |
+| +---+  |
+| |   |  |
+| | B |  |
+| |   |  |
+| +-+-+  |
+|   |    |
++---|----+
     |
     |
     v

package/src/__tests__/theme-palette-contrast.test.ts

@@ -0,0 +1,84 @@
+/**
+ * Guards the "legible, readable contrast" acceptance criterion the #684
+ * theme-selector restoration's 16 per-theme verification sub-issues
+ * (#691-706) each individually ask for, systematically across every
+ * built-in theme at once rather than eyeballing 16 screenshots one at a
+ * time — see docs/decisions/theme-selector-shared-state.md and this
+ * repo's CLAUDE.md's "favor tooling over manual scanning" convention.
+ *
+ * Computes the actual WCAG 2.x contrast ratio (relative luminance, per
+ * https://www.w3.org/TR/WCAG21/#dfn-relative-luminance) between each
+ * theme's `bg`/`fg` pair — not a hand-picked pass/fail per theme, so a
+ * future THEMES addition with a genuinely illegible pair fails this test
+ * automatically instead of only being caught by a human noticing a
+ * screenshot looks wrong.
+ */
+import { describe, it, expect } from 'vitest'
+import { THEMES } from '@zombie-mermaid/core'
+
+/**
+ * The threshold every theme must clear. WCAG AA's own thresholds are 4.5:1
+ * for normal text and 3:1 for large/bold text; diagram node labels here
+ * are typically medium, semi-bold text, closer to the "large text"
+ * category than dense body copy. 4.0 sits between the two -- strict enough
+ * to catch a genuinely illegible pair, loose enough not to fail
+ * `solarized-light` (4.13:1), whose muted bg/fg pair matches Ethan
+ * Schoonover's actual published Solarized values rather than being a
+ * mistake in this repo's THEMES data -- #684's own non-goals rule out
+ * changing THEMES' colors to "fix" a curated editor-theme's real values.
+ */
+const MIN_CONTRAST_RATIO = 4.0
+
+function hexToRgb(hex: string): [number, number, number] {
+  const clean = hex.replace('#', '')
+  return [
+    parseInt(clean.slice(0, 2), 16),
+    parseInt(clean.slice(2, 4), 16),
+    parseInt(clean.slice(4, 6), 16),
+  ]
+}
+
+/** sRGB channel -> linear-light value, the WCAG relative-luminance step. */
+function linearize(channel: number): number {
+  const c = channel / 255
+  return c <= 0.03928 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4
+}
+
+function relativeLuminance(hex: string): number {
+  const [r, g, b] = hexToRgb(hex)
+  return 0.2126 * linearize(r) + 0.7152 * linearize(g) + 0.0722 * linearize(b)
+}
+
+/** WCAG contrast ratio between two colors, always >= 1 (order-independent). */
+function contrastRatio(hexA: string, hexB: string): number {
+  const lumA = relativeLuminance(hexA)
+  const lumB = relativeLuminance(hexB)
+  const lighter = Math.max(lumA, lumB)
+  const darker = Math.min(lumA, lumB)
+  return (lighter + 0.05) / (darker + 0.05)
+}
+
+describe('every built-in theme has a legible bg/fg contrast ratio', () => {
+  for (const [themeKey, colors] of Object.entries(THEMES)) {
+    it(`${themeKey}: bg/fg contrast is at least ${MIN_CONTRAST_RATIO}:1`, () => {
+      const ratio = contrastRatio(colors.bg, colors.fg)
+      expect(ratio).toBeGreaterThanOrEqual(MIN_CONTRAST_RATIO)
+    })
+  }
+})
+
+describe('contrastRatio() itself', () => {
+  it('returns 1 for identical colors', () => {
+    expect(contrastRatio('#808080', '#808080')).toBeCloseTo(1, 5)
+  })
+
+  it('returns 21 for pure black vs pure white (the WCAG maximum)', () => {
+    expect(contrastRatio('#000000', '#FFFFFF')).toBeCloseTo(21, 1)
+  })
+
+  it('is symmetric regardless of argument order', () => {
+    const a = contrastRatio('#1a1b26', '#a9b1d6')
+    const b = contrastRatio('#a9b1d6', '#1a1b26')
+    expect(a).toBeCloseTo(b, 10)
+  })
+})

package/src/__tests__/workspace-package-boundaries.test.ts

@@ -14,12 +14,21 @@
 //
 // So: walk what the files actually import, and assert the shape.
 //
-//   core          -> nothing in this repo, only `elkjs` (type-only)
-//   svg-renderer  -> `@zombie-mermaid/core` and `elkjs`, nothing else
+//   core            -> nothing in this repo, only `elkjs` (type-only)
+//   mermaid-parser  -> `@zombie-mermaid/core`, nothing else
+//   svg-renderer    -> `@zombie-mermaid/core`, `@zombie-mermaid/mermaid-parser`,
+//                      and `elkjs`, nothing else
 //
-// Neither may reach back into `src/` by relative path or by importing
-// `zombie-mermaid` itself — the umbrella depends on them, never the
-// reverse.
+// `svg-renderer` depending on `mermaid-parser` (added under #624) is a new
+// edge, not a violation of the sink property above: it is an ordinary,
+// acyclic dependency (both `svg-renderer` and the future `ascii-renderer`
+// depend on `mermaid-parser` directly — the scoping doc's finding 2), and
+// `mermaid-parser` itself stays a sink exactly like `core` — it does not
+// import `svg-renderer` back.
+//
+// None of the three may reach back into `src/` by relative path or by
+// importing `zombie-mermaid` itself — the umbrella depends on them, never
+// the reverse.
 
 import { describe, it, expect } from 'vitest'
 import { readdirSync, readFileSync, statSync } from 'node:fs'
@@ -43,6 +52,20 @@ const PACKAGES = resolve(REPO_ROOT, 'packages')
 const SPECIFIER_RE =
   /(?:^|\n)[ \t]*(?:import|export)\b[^'"\n]*?from[ \t]*['"]([^'"]+)['"]|(?:^|\n)[ \t]*import[ \t]*['"]([^'"]+)['"]|\bimport\([ \t]*['"]([^'"]+)['"]/g
 
+/**
+ * Same three shapes as `SPECIFIER_RE`'s first alternative, but split into
+ * the `import`/`export` keyword and the clause between it and `from`, so a
+ * whole-clause type-only import (`import type { X } from '...'` /
+ * `export type { X } from '...'`) can be told apart from a real value one.
+ * Used only by `valueSpecifiersOf` below — `specifiersOf`/`SPECIFIER_RE`
+ * stay untouched since the import-graph tests above are deliberately
+ * over-approximating.
+ */
+const FROM_CLAUSE_RE =
+  /(?:^|\n)[ \t]*(?:import|export)\b([^'"\n]*?)from[ \t]*['"]([^'"]+)['"]/g
+const SIDE_EFFECT_IMPORT_RE = /(?:^|\n)[ \t]*import[ \t]*['"]([^'"]+)['"]/g
+const DYNAMIC_IMPORT_RE = /\bimport\([ \t]*['"]([^'"]+)['"]/g
+
 function tsFilesUnder(dir: string): string[] {
   const out: string[] = []
   for (const entry of readdirSync(dir)) {
@@ -77,12 +100,63 @@ function externalSpecifiers(pkg: string): string[] {
     .sort()
 }
 
+/**
+ * Every specifier named by a *value* import in `packages/<name>/src` —
+ * i.e. excluding a whole-clause `import type { X } from '...'` /
+ * `export type { X } from '...'`, which is erased before bundling and so
+ * shouldn't obligate a `dependencies` entry (#742). A per-symbol inline
+ * `import { type X, y } from '...'` still counts as a value import here,
+ * since `y` binds to a real runtime export from that module — this repo
+ * doesn't currently mix the two on one specifier, so that distinction
+ * isn't exercised, but the whole-clause check stays conservative rather
+ * than trying to parse the individual specifiers in the braces.
+ */
+function valueSpecifiersOf(pkg: string): Map<string, string[]> {
+  const bySpecifier = new Map<string, string[]>()
+  const record = (specifier: string, file: string) => {
+    const seen = bySpecifier.get(specifier) ?? []
+    seen.push(relative(REPO_ROOT, file))
+    bySpecifier.set(specifier, seen)
+  }
+  for (const file of tsFilesUnder(resolve(PACKAGES, pkg, 'src'))) {
+    const source = readFileSync(file, 'utf8')
+    for (const match of source.matchAll(FROM_CLAUSE_RE)) {
+      const [, clause, specifier] = match
+      if (/^\s*type\b/.test(clause ?? '')) continue
+      record(specifier!, file)
+    }
+    for (const match of source.matchAll(SIDE_EFFECT_IMPORT_RE)) {
+      record(match[1]!, file)
+    }
+    for (const match of source.matchAll(DYNAMIC_IMPORT_RE)) {
+      record(match[1]!, file)
+    }
+  }
+  return bySpecifier
+}
+
+/**
+ * Non-relative value-import specifiers only — what a package's
+ * `dependencies` should actually list, since a type-only import is erased
+ * before anything is bundled and never needs a runtime package present.
+ */
+function externalValueSpecifiers(pkg: string): string[] {
+  return [...valueSpecifiersOf(pkg).keys()]
+    .filter((s) => !s.startsWith('.'))
+    .map((s) => (s.startsWith('@') ? s : s.split('/')[0]!))
+    .filter((s, i, all) => all.indexOf(s) === i)
+    .sort()
+}
+
 /**
  * A relative specifier that climbs out of `packages/<name>/src` — i.e. a
  * reach-around into the umbrella's `src/` or into a sibling package. The
- * three legitimate `../` hops inside `svg-renderer` (`layout-engine/*.ts`
- * importing `../styles.ts` and friends) stay within the package and are
- * resolved, not pattern-matched, so this can't be fooled by depth.
+ * many legitimate `../` hops inside `svg-renderer` (`layout-engine/*.ts`
+ * importing `../styles.ts`, and — since #624 — each `class/`, `er/`,
+ * `sequence/`, `xychart/` subdirectory's `layout.ts`/`renderer.ts`
+ * importing sibling modules like `../elk-instance.ts`/`../renderer.ts`)
+ * stay within the package and are resolved, not pattern-matched, so this
+ * can't be fooled by depth.
  */
 function escapingRelativeImports(pkg: string): string[] {
   const packageSrc = resolve(PACKAGES, pkg, 'src')
@@ -115,10 +189,27 @@ describe('@zombie-mermaid/core is a workspace sink', () => {
   })
 })
 
-describe('@zombie-mermaid/svg-renderer depends only on core', () => {
-  it('imports no workspace package other than @zombie-mermaid/core', () => {
+describe('@zombie-mermaid/mermaid-parser is a workspace sink', () => {
+  // Verified (#624, umbrella #620): no file under packages/mermaid-parser/src
+  // imports `elkjs`, `@zombie-mermaid/svg-renderer`, or anything from the
+  // umbrella — the property that lets both `svg-renderer` and the future
+  // `ascii-renderer` depend on it without either dragging the other in.
+  it('imports no workspace package and no npm dependency other than @zombie-mermaid/core', () => {
+    expect(externalSpecifiers('mermaid-parser')).toEqual([
+      '@zombie-mermaid/core',
+    ])
+  })
+
+  it('never reaches outside its own src/ by relative path', () => {
+    expect(escapingRelativeImports('mermaid-parser')).toEqual([])
+  })
+})
+
+describe('@zombie-mermaid/svg-renderer depends only on core and mermaid-parser', () => {
+  it('imports no workspace package other than @zombie-mermaid/core and @zombie-mermaid/mermaid-parser', () => {
     expect(externalSpecifiers('svg-renderer')).toEqual([
       '@zombie-mermaid/core',
+      '@zombie-mermaid/mermaid-parser',
       'elkjs',
     ])
   })
@@ -129,27 +220,110 @@ describe('@zombie-mermaid/svg-renderer depends only on core', () => {
 })
 
 describe('workspace package manifests', () => {
-  // The umbrella bundles both packages into its own `dist/` (they are
-  // absent from `isExternal` in vite.config.lib.ts), so nothing resolves
-  // these names at install time and publishing them would be misleading.
-  // Recommendation 2 of the scoping doc; the umbrella declares them as
-  // devDependencies for the same reason.
-  it.each(['core', 'svg-renderer'])('%s is private and unpublished', (pkg) => {
-    const manifest = JSON.parse(
-      readFileSync(resolve(PACKAGES, pkg, 'package.json'), 'utf8'),
-    ) as { name: string; private: boolean }
-    expect(manifest.name).toBe(`@zombie-mermaid/${pkg}`)
-    expect(manifest.private).toBe(true)
-  })
+  // As of #769, each of the five `@zombie-mermaid/*` packages has a
+  // genuinely publishable `package.json` shape — real `name`/`exports`
+  // pointing at its own built `dist/`, `publishConfig.access: "public"`,
+  // no longer `"private": true` — and its own independent build
+  // (`packages/<name>/vite.config.ts`, via `vite.config.package.ts`).
+  //
+  // That is preparation only. The umbrella (`vite.config.lib.ts`) still
+  // bundles all five packages' source directly into its own `dist/` (they
+  // are absent from `isExternal` there, same as before #769) — none of
+  // them is a real external `dependencies` entry of `zombie-mermaid`, none
+  // is part of `.changeset/config.json`'s `fixed` group (still `[]`), and
+  // none has ever actually been published to npm. Externalizing them for
+  // real is a separate, future PR gated on completing npm's one-time
+  // trusted-publishing setup for each new package name — see
+  // RELEASING.md's "Future: multi-package publish" section.
+  it.each(['core', 'mermaid-parser', 'svg-renderer', 'ascii-renderer', 'mcp'])(
+    '%s is publish-ready in shape under the @zombie-mermaid/ scope (not yet externalized or published)',
+    (pkg) => {
+      const manifest = JSON.parse(
+        readFileSync(resolve(PACKAGES, pkg, 'package.json'), 'utf8'),
+      ) as {
+        name: string
+        private?: boolean
+        publishConfig?: { access?: string }
+      }
+      expect(manifest.name).toBe(`@zombie-mermaid/${pkg}`)
+      // Not `"private": true` — a scoped package still defaults to a
+      // *private* npm publish unless `publishConfig.access` says otherwise,
+      // which is the actual thing preventing an accidental unscoped-style
+      // public leak here; `private` merely gates `pnpm publish`/`npm publish`
+      // from running against this package at all.
+      expect(manifest.private).not.toBe(true)
+      expect(manifest.publishConfig?.access).toBe('public')
+    },
+  )
 
-  it('declares every external specifier its source actually imports', () => {
-    for (const pkg of ['core', 'svg-renderer'] as const) {
+  // Declared `dependencies` must match actual *runtime* imports, not the
+  // over-approximating `externalSpecifiers` above — a type-only import
+  // (e.g. `mermaid-parser`'s hypothetical future one) is erased before
+  // bundling and belongs in `devDependencies` instead, or a published
+  // consumer of the package would pull in a runtime dependency it never
+  // executes (#742) — UNLESS that type is itself part of this package's own
+  // published public surface (its rolled-up `dist/index.d.ts`, built via
+  // api-extractor's `bundleTypes` — see vite.config.package.ts), in which
+  // case a real downstream `tsc` consumer needs the type resolvable and a
+  // `devDependency` (never installed for a consumer) won't do. `core` is
+  // exactly this case: `LayoutCache`'s public field types reference
+  // `elkjs`'s `ElkNode` (`import type { ElkNode } from 'elkjs'` in
+  // `types.ts`), so `elkjs` is a real `dependencies` entry there despite
+  // never being a *value* import in `core`'s own source.
+  it('declares every runtime (non-type-only) external specifier its source actually imports', () => {
+    for (const pkg of ['mermaid-parser', 'svg-renderer'] as const) {
       const manifest = JSON.parse(
         readFileSync(resolve(PACKAGES, pkg, 'package.json'), 'utf8'),
       ) as { dependencies?: Record<string, string> }
       expect(Object.keys(manifest.dependencies ?? {}).sort()).toEqual(
-        externalSpecifiers(pkg),
+        externalValueSpecifiers(pkg),
       )
     }
   })
+
+  it('core additionally declares elkjs — type-only in source, but part of its own published public types', () => {
+    const manifest = JSON.parse(
+      readFileSync(resolve(PACKAGES, 'core', 'package.json'), 'utf8'),
+    ) as { dependencies?: Record<string, string> }
+    expect(Object.keys(manifest.dependencies ?? {}).sort()).toEqual([
+      'elkjs',
+      ...externalValueSpecifiers('core'),
+    ])
+  })
+
+  // `ascii-renderer` and `mcp` each bundle one (`packages/ascii-renderer/src/flowchart.ts`
+  // -> `../../../src/parser.ts`) or two (`packages/mcp/src/{server,tools/render-svg}.ts`
+  // -> `../../../src/{package-info,index}.ts`) files from *outside* their
+  // own `packages/<name>/src/` — see vite.config.package.ts's header and
+  // each package's own vite.config.ts for why (their build still compiles
+  // that source in directly, same as before #769). `externalValueSpecifiers`
+  // above only scans each package's own `src/`, so it can't see what those
+  // reach-through files themselves import — this asserts the full,
+  // hand-traced transitive set instead of extending that scanner to follow
+  // an out-of-package relative import (which `escapingRelativeImports`
+  // above deliberately treats as a violation for the other three packages).
+  it('ascii-renderer declares every specifier its reach-through into src/parser.ts needs, on top of its own', () => {
+    const manifest = JSON.parse(
+      readFileSync(resolve(PACKAGES, 'ascii-renderer', 'package.json'), 'utf8'),
+    ) as { dependencies?: Record<string, string> }
+    expect(Object.keys(manifest.dependencies ?? {}).sort()).toEqual([
+      '@zombie-mermaid/core',
+      '@zombie-mermaid/mermaid-parser',
+    ])
+  })
+
+  it('mcp declares every specifier its reach-through into src/{package-info,index}.ts needs, on top of its own', () => {
+    const manifest = JSON.parse(
+      readFileSync(resolve(PACKAGES, 'mcp', 'package.json'), 'utf8'),
+    ) as { dependencies?: Record<string, string> }
+    expect(Object.keys(manifest.dependencies ?? {}).sort()).toEqual([
+      '@modelcontextprotocol/sdk',
+      '@zombie-mermaid/ascii-renderer',
+      '@zombie-mermaid/core',
+      '@zombie-mermaid/mermaid-parser',
+      '@zombie-mermaid/svg-renderer',
+      'entities',
+      'zod',
+    ])
+  })
 })

package/src/__tests__/xychart-ascii.test.ts

@@ -5,7 +5,7 @@
  * multi-series support, staircase line routing, and edge cases.
  */
 import { describe, it, expect } from 'vitest'
-import { renderMermaidASCII } from '../ascii/index.ts'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
 
 // ============================================================================
 // Helper — render with no colors for easy string matching

package/src/__tests__/xychart-colors.test.ts

@@ -1,5 +1,6 @@
 /**
- * Tests for xychart color palette generation (src/xychart/colors.ts).
+ * Tests for xychart color palette generation
+ * (packages/mermaid-parser/src/xychart/colors.ts).
  */
 import { describe, it, expect } from 'vitest'
 import {
@@ -8,7 +9,7 @@ import {
   isDarkBackground,
   mixHexColors,
   getSeriesColor,
-} from '../xychart/colors.ts'
+} from '@zombie-mermaid/mermaid-parser'
 
 describe('isValidHex', () => {
   it('accepts a well-formed 6-digit hex color', () => {

package/src/__tests__/xychart-layout.test.ts

@@ -1,5 +1,5 @@
 /**
- * Coverage-focused tests for src/xychart/layout.ts.
+ * Coverage-focused tests for packages/svg-renderer/src/xychart/layout.ts.
  *
  * Exercises the horizontal layout path (previously untested), numeric
  * x-axis ranges (category label interpolation), multi-series bar groups,