feat: remove log-symbols dependency

[valadaptive]

PR Checklist

• Addresses an existing open issue: fixes 🚀 Feature: Replace log-symbols with something smaller (maybe just inline it?) #5468
• That issue was marked as status: accepting prs
• Steps in CONTRIBUTING.md were taken

Overview

This PR removes the log-symbols dependency, inlining its functionality. This removes chalk and its many subdependencies from the dependency tree.

We no longer check for explicit Unicode support. In case anyone is running Mocha from the Windows legacy command prompt (and possibly PowerShell?), the characters may not show up properly.

I also noticed that the symbols do not respect Base.useColors, and never seem to have done so. This might be something to look into in the future.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: JoshuaKGoldberg / name: Josh Goldberg ✨ (12dd49a, 1616e56, d96cd18, f7890b7)

[JoshuaKGoldberg]

Windows legacy command prompt (and possibly PowerShell?),

Err, that seems like it might be a blocker. Can you elaborate on that please?

[valadaptive]

Windows legacy command prompt (and possibly PowerShell?),

Err, that seems like it might be a blocker. Can you elaborate on that please?

log-symbols returns different symbols on Windows because it claims that the Windows console host (conhost.exe) doesn't support Unicode. However, I just tested this on Windows 11, and both conhost.exe and the new Terminal app output the characters in question just fine. Maybe it doesn't work on older Windows versions?

[JoshuaKGoldberg]

IMO we'll need to answer that "maybe" before being able to fully review this PR. Shell/terminal symbols and OSes are notoriously difficult to get right. It's possible that some important supported variants of Powershell and/or Windows would be very broken by this change.

I'm not saying "unconditionally no" - rather, "please answer the open questions on this PR".

[valadaptive]

OK, I've investigated a bit further.

In cmd.exe on Windows 7, and PowerShell in some configurations (a fresh Windows 10 1507 VM didn't experience this, but my actual up-to-date Windows 10 machine does), the wrong code page is used and all the symbols are mojibake. This includes the "fallback" symbols used by log-symbols.

In pre-Windows 11 consoles with the correct code page, the symbols show up as boxes, meaning the terminal font doesn't support them. In Windows 11, everything shows up correctly.

This means that the is-unicode-supported package, which is what log-symbols uses, doesn't actually check for Unicode support, which is completely irrelevant since both the preferred and fallback symbols are Unicode code points. What it's actually checking for is whether we're running in Windows conhost.exe, by trying as hard as it can to check for every other terminal app it could be instead, as a rough proxy for whether the terminal's font contains emoji.

One course of action would be to depend on is-unicode-supported and include the fallback symbols here too. That would avoid depending on two different color libraries, and give us the option to make symbols respect Base.useColors in the future.

[JoshuaKGoldberg]

One course of action would be to depend on is-unicode-supported and include the fallback symbols here too

That seems reasonable to me as a first step. I'm very wary of completely dropping detection for any of terminal color/TTY/unicode support/type. Mocha has a lot of legacy users who tend to pop up with reported breakages when these nuanced edge cases get changed.

Fun fact: Windows 10 is still in support through October 14, 2025!

[mark-wiemer]

Hi @valadaptive, are you able to continue on this one?

[valadaptive]

I've rebased the PR and re-added the is-unicode-supported dependency (version 0.1, which is the last version that isn't ESM-only).

[mark-wiemer]

@valadaptive Mocha v12 (including current main branch) now targets Node 20.19.0, so we can include ESM-only versions of packages :)

[valadaptive]

Nice! I've bumped is-unicode-supported.

[mark-wiemer]

@valadaptive welcome to 2026! I think this one is still giving some weird CI failures, are you able to check it out?

[valadaptive]

Rebased and fixed the import + merge conflicts.

[mark-wiemer]

another day, another weird CI issue :/ I don't have any advice for you, but I appreciate you continuing to work on this :)

[JoshuaKGoldberg]

I merged from main and re-ran the tests twice. The new failure seems to be deterministic. Example from https://github.com/mochajs/mocha/actions/runs/21633121802/job/62353168387?pr=5469:

  1) esm
       should throw an ERR_MODULE_NOT_FOUND and not ERR_REQUIRE_ESM if file imports a non-existing module with a loader:
     UnexpectedError: 
expected '(node:2863) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:\n--import \'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("./test/integration/fixtures/esm/loader-with-module-not-found/loader-that-recognizes-ts.mjs", pathToFileURL("./"));\'\n    at createModuleLoader (node:internal/modules/esm/loader:970:17)\n    at Object.getOrInitializeCascadedLoader (node:internal/modules/esm/loader:1014:22)\n    at asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:106:65)\n    at runEntryPointWithESMLoader (node:internal/modules/run_main:139:19)\n    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:176:5)\n    at node:internal/main/run_main_module:36:49\n\nnode:internal/modules/run_main:123\n    triggerUncaughtException(\n    ^\nTypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file\n    at fileURLToPath (node:internal/url:1612:11)\n    at resol
to contain 'ERR_MODULE_NOT_FOUND'
(node:2863) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("./test/integration/fixtures/esm/loader-with-module-not-found/loader-that-recognizes-ts.mjs", pathToFileURL("./"));'
    at createModuleLoader (node:internal/modules/esm/loader:970:17)
    at Object.getOrInitializeCascadedLoader (node:internal/modules/esm/loader:1014:22)
    at asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:106:65)
    at runEntryPointWithESMLoader (node:internal/modules/run_main:139:19)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:176:5)
    at node:internal/main/run_main_module:36:49
node:internal/modules/run_main:123
    triggerUncaughtException(
    ^
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
           ^^^^
    at fileURLToPath (node:internal/url:1612:11)
    at resolve (file:///home/runner/work/mocha/mocha/test/integration/fixtures/esm/loader-with-module-not-found/loader-that-recognizes-ts.mjs:15:5)
    at nextResolve (node:internal/modules/esm/hooks:748:28)
    at Hooks.resolve (node:internal/modules/esm/hooks:240:30)
    at MessagePort.handleMessage (node:internal/modules/esm/worker:199:24)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:845:20)
    at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28) {
  code: 'ERR_INVALID_URL_SCHEME'
         ^^^^
}
Node.js v22.22.0
      at Context.<anonymous> (test/integration/esm.spec.js:100:5)
      at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
      set UNEXPECTED_FULL_TRACE=true to see the full stack trace

This hasn't happened on the last few commits to main.

I wonder if it's some oddity with is-unicode-supported? None of the lib/ file changes seem like likely culprits to me. The only real Node.js-y area change is switching is-unicode-supported from 0.1.0 to 2.1.0.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.41%. Comparing base (15fb31a) to head (f7890b7).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5469      +/-   ##
==========================================
- Coverage   88.44%   88.41%   -0.04%     
==========================================
  Files          66       66              
  Lines        4794     4798       +4     
  Branches      978      982       +4     
==========================================
+ Hits         4240     4242       +2     
- Misses        554      556       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JoshuaKGoldberg]

Yup, looks like that fixed things. Fun. We're setting up Renovate to bump dependencies to latest anyway (#5055 -> #5678) so bumping is-unicode-supported to the latest 2.x line will be automatically triggered soon.