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: valadaptive / name: valadaptive (58d4fdb, 78f49eb, bd30b79)

[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.