Update test dependency stack

[tortmayr]

Reevaluate and update our dependency stack for unit testing.
Currently we are using mocha-chai-sinon.
With the introduction of the node-built in testrunner in Node 20 they might be no longer necessary.
The node test runner ships with built-in mockin and assertions support.
We should quickly evaluate whether switching to the built in test runner is feasible.
It would simplify the test setup and eliminating not necessary third party dependencies is always a plus.

[tortmayr]

GLSP Test Stack — Combined Comparison & Recommendation

Issue: eclipse-glsp/glsp#1635
Scope: repos with mocha tests — glsp (dev-packages/cli), glsp-client, glsp-server-node
(~137 spec files, ~2557 expect() assertions; inversify DI throughout; client renders SVG into the DOM).

The three options compared:

1. Status quo — mocha + chai + sinon + nyc (+ ts-node loader).
2. node:test — Node's built-in runner + node:assert + node:test mock + c8 (+ tsx/swc loader).
3. Vitest — Vitest 4 (expect/chai + vi + @vitest/coverage-v8, oxc transform, optional browser mode).

---

1. Executive summary

	Status quo (mocha)	node:test	Vitest
Modernity / industry trend	❌ declining, legacy	🟡 emerging, minimal	✅ fastest-growing, #1 satisfaction
Dependencies	4 libs + types	fewest (≈0 runtime)	most (vite+vitest toolchain)
Migration effort from today	— (baseline)	highest (rewrite assertions+mocks+wiring)	lowest (chai-compatible expect)
Assertion changes (~2557)	none	full rewrite → node:assert	import swap only
Mocking	sinon	node:test mock (gaps)	vi (rich, sinon-like)
Coverage	nyc (istanbul)	c8 + custom merge rework	built-in coverage-v8
TS/decorators	ts-node	needs loader choice	built-in (oxc + tsconfig)
Browser testing (client)	❌ none	❌ none	✅ real browser (Playwright)
Sprotty (base project) alignment	❌	❌	✅ sprotty already uses Vitest
Maintenance burden	high (4 deps, dated)	low	medium (fast-moving major versions)

Bottom line: the status quo is the industry's declining option; node:test minimizes dependencies but
maximizes migration work and lacks browser testing; Vitest is the least migration effort, aligns with
sprotty, and is the only option that unlocks real-browser client testing — at the cost of a larger toolchain.

---

2. Industry context (why this matters beyond GLSP)

The intuition that "mocha is out of favor, Vitest is in" is well supported by current data:

• State of JS 2024/2025: Vitest ranks Split public API from internal implementations  #1 in developer satisfaction (overtaking Jest for the first
  time) and leads interest/retention; it has grown 400%+ since 2023. Mocha is in steady decline;
  Jest's usage has plateaued.
• npm downloads: Vitest ≈ 39M/week vs Mocha ≈ 14M/week — Vitest now ~3× Mocha's volume and
  climbing while Mocha falls.
• Ecosystem default: Nuxt, SvelteKit, Astro, and Angular's modern tooling ship with or recommend
  Vitest. Mocha is increasingly seen as "less forward-looking" vs ESM-first runners.
• node:test is the platform's answer to "zero-dependency testing" — credible and improving, but
  deliberately minimal; it is not (yet) a mainstream replacement for feature-rich runners, and tooling
  (reporters, coverage UX, browser testing) is thinner.

For an open-source project that wants longevity, contributor familiarity, and good docs/examples, Vitest
is where the ecosystem momentum is; mocha is the one to leave; node:test is a reasonable minimalist bet
but swims against the feature-richness most projects expect.

Sources: State of JS 2024 — Testing,
State of JS 2025 — Testing,
mocha vs vitest — npm trends,
Testing framework adoption trends (npm data),
Vitest browser mode stable (Vitest 4).

---

3. Dimension-by-dimension comparison

3.1 Test runner & API

• mocha: mature BDD (describe/it). Fine, but the runner is dated (callback-era ergonomics, separate
  assertion/mock/coverage libs, CJS-first).
• node:test: BDD built in; lean. No watch UI, thinner reporter ecosystem, more manual wiring.
• Vitest: BDD + test.concurrent, fixtures, globals, watch mode, --ui, snapshots. Richest DX.

3.2 Assertions (~2557 sites — the dominant migration cost)

• chai (today): expect(x).to.be.true etc. No plugins in use.
• node:test → node:assert: full rewrite of all 2557 sites (codemod + manual tail). Real risk of
  weakening assertions (assert.ok where strict equality was meant). Largest, riskiest chunk of that plan.
• Vitest: expect is built on chai → the existing assertions work as-is; migration is changing
  import { expect } from 'chai' → from 'vitest'. Jest-style matchers also available. Verified.

3.3 Mocking (~32 files)

• sinon (today): spies/stubs/sandboxes; ~14 sites use whole-object stubbing (SinonStubbedInstance).
• node:test mock: covers spies/stubs/timers, but no whole-object/interface stubbing and no arg
  matchers → needs custom createStubInstance/stubInterface helpers.
• Vitest vi: vi.fn/vi.spyOn/vi.mock/vi.useFakeTimers, auto-restore, module mocking — closest
  to sinon; most mechanical migration. Verified vi.spyOn + call assertions.

3.4 TypeScript / decorators (inversify)

• All three need legacy-decorator support + useDefineForClassFields: false (already set in ts-config).
• mocha: ts-node (emits metadata). node:test: must pick a loader (tsx/swc/ts-node); tsx works
  because GLSP is metadata-free. Vitest: built-in via oxc, configured by a real tsconfig.json
  (gotcha: a missing/empty tsconfig makes decorators throw — verified both ways). None emit metadata
  except ts-node/swc, but GLSP doesn't need it (see test-migration-eval.md §8.3).

3.5 DOM / browser (the client-specific differentiator)

• mocha & node:test: no DOM; client DOM/render code is tested DOM-less or not at all.
• Vitest: happy-dom/jsdom for fast DOM, and Vitest 4 stable Browser Mode (Playwright) for
  real-browser component/render tests with visual regression. This is a capability the other two lack
  entirely — directly relevant to glsp-client's SVG/sprotty rendering. CSS imports also work natively
  (vite) → deletes the ignore-styles shim.

3.6 Coverage

• nyc (today): istanbul; the glsp coverageReport CLI aggregates per-package JSON into one HTML.
• node:test: native coverage can't build the combined HTML → must add c8 and rework glsp coverageReport.
• Vitest: built-in @vitest/coverage-v8 (lcov/html/json, thresholds, workspace merge) — least wiring.

3.7 CI / reporters (CTRF)

• today: mocha-ctrf-json-reporter → ctrf-io/github-test-reporter action.
• node:test: built-in junit + junit-to-ctrf conversion.
• Vitest: dedicated vitest-ctrf-json-reporter (+ built-in junit/json/html/github-actions). Direct.

3.8 Dependency footprint (the core tension with #1635)

• mocha: removes nothing; 4 libs + types, all dated.
• node:test: lightest — drops mocha/chai/sinon/nyc, adds only c8 + a loader + junit-to-ctrf.
  Best serves Update test dependency stack #1635's literal "reduce dependencies" goal.
• Vitest: heaviest — adds the vite+vitest toolchain (+ Playwright browsers for browser mode).
  Directly contradicts a strict reduce-deps reading.

---

4. Pros & cons

Option 1 — Status quo (mocha + chai + sinon + nyc)

• Pros: zero migration; well understood; works today.
• Cons: industry-declining/legacy; 4 separate dated deps; CJS-era ergonomics; no DOM/browser testing;
  diverges from sprotty; does nothing for Update test dependency stack #1635. Not a real candidate — it's the thing being replaced.

Option 2 — node:test

• Pros: fewest dependencies (best fit for the literal Update test dependency stack #1635 goal); no framework to track; fast; platform-native.
• Cons: most migration work (rewrite 2557 assertions + sinon + coverage/CTRF wiring + loader choice);
  assertion-weakening risk; thinner tooling (reporters, watch/UI); no browser testing; diverges from
  sprotty; against industry momentum.

Option 3 — Vitest

• Pros: least migration effort (chai-compatible expect); real-browser testing for the client;
  sprotty alignment; vi ≈ sinon; built-in coverage + CTRF + native CSS; best DX (watch/UI/snapshots);
  strongest industry momentum & satisfaction; simplifies the implementation plan (no loader/c8/css-hook/junit
  decisions).
• Cons: adds the largest toolchain (counter to a strict Update test dependency stack #1635 reduce-deps reading); more config
  surface (shared vite.config.ts, oxc/tsconfig decorator gotcha); fast-moving major versions (pin + budget
  upgrades); browser-mode CI setup (Playwright install) — though GLSP already runs Playwright elsewhere.

---

5. GLSP-specific fit

• Sprotty is the GLSP base layer and already uses Vitest — one shared stack/config/mental model is a
  durable maintenance win; node:test and mocha both diverge from it.
• glsp-client renders SVG via sprotty into the DOM — browser mode is genuinely useful here, and only
  Vitest offers it.
• GLSP DI is metadata-free — so the esbuild/oxc "no decorator metadata" limitation (which would block a
  naive tsx/Vitest adoption elsewhere) does not affect GLSP; all three work with useDefineForClassFields: false.
• glsp-server-node / cli are pure Node — they gain less from Vitest (no browser need), so node:test
  would technically suffice there; but a single stack across all repos beats per-repo divergence.

---

6. Recommendation

Adopt Vitest, repo-wide, with browser mode introduced incrementally for glsp-client.

Rationale, in priority order:

1. Lowest migration risk & effort. chai-compatible expect turns the biggest, riskiest part of the
   node:test plan (rewriting 2557 assertions) into an import swap. vi makes sinon removal mechanical.
2. Strategic capability node:test can't match: real-browser testing for the client's rendering code,
   plus alignment with sprotty's existing Vitest setup.
3. Industry direction: Vitest is the fastest-growing, highest-satisfaction runner; mocha is declining.
   For a long-lived OSS project, this means better contributor familiarity, docs, and longevity.
4. It still satisfies Update test dependency stack #1635's intent — drop the dated mocha/chai/sinon/nyc quartet for a single modern
   tool — even though it does not satisfy a literal "fewer total dependencies" reading. This reframe
   ("modernize + align + enable browser testing" over "minimize dep count") is the one explicit decision to
   confirm. If, and only if, minimizing dependency count is a hard non-negotiable, choose node:test
   instead — accepting more migration work and no browser testing.

Do not keep the status quo; it's the option the rest of the ecosystem is leaving.

Suggested shape

• Reuse sprotty's vite.config.ts pattern; provide shared vite.config.ts + vitest.config.ts from a
  dev-package (replacing mocha-config/nyc-config); config-test/@eclipse-glsp/dev carry vitest +
  @vitest/coverage-v8 (+ @vitest/browser-playwright for the client).
• Migrate node-only repos (cli, server-node) first (pure unit, fastest), then glsp-client; add a
  browser-mode pilot for a handful of client rendering specs, expanding over time.
• Keep the local dry-run harness from the implementation plan (worktrees + verdaccio + herdr + parallel
  tracks + Phase-7 review); the Vitest choice removes the loader/c8/css-hook/junit sub-tasks.

Fallback

If the project rejects the added toolchain, node:test is the documented alternative (see
test-migration-eval.md / test-migration-implementation-plan.md). The status quo is not recommended.
repos → update MIGRATION_GUIDE.md (downstream repos consume these configs).