📦 Package: Bump log-symbols from 10 to 11

[JoshuaKGoldberg]

Feature Request Checklist

• I have read and agree to Mocha's Code of Conduct and Contributing Guidelines
• I have searched for related issues and issues with the faq label, but none matched my issue.
• I want to provide a PR to resolve this

Overview

Mocha currently depends an older major version of log-symbols:

mocha/package.json

Line 106 in 5cf2b09

"log-symbols": "^4.1.0",

Suggested Solution

[email protected] is the latest. It'd be nice to bump to that, so users aren't stuck on a dep that's two major versions behind.

Alternatives

This isn't critical and I don't think we need to do it. But it's nice ecosystem cleanup in general.

Additional Info

log-symbols@7 still supports Node.js >=18, so I don't believe we're blocked on that. However, it is an ESM-only package, so this could only happen once Mocha requires Node.js versions that include require(ESM) (^20.19.0 || >=22.12.0).

[mark-wiemer]

@JoshuaKGoldberg do we have any issue to support ESM-only packages? Or would that require us to go ESM-only as well? I forget how all this works :(

[JoshuaKGoldberg]

Yeah, prior to require(esm) in Node.js it's "viral" in the same way async/await is. In Node.js versions without require(esm) if something is ESM then it can only be imported by an import. That's either an ESM import ... from ... or a dynamic await import(...).

My personal hope is that for Mocha 12 we do roughly only "clean up old cruft" work, similar to & expanding on what we did for Mocha 11:

• By increasing the minimum Node.js to ^20.19.0 || >=22.12.0 we can assume all consumers support require(esm), making this not an issue
• Other cleanups, like removing long-deprecated options and switching manual .prototype shenanigans to actual classes

...so that most consumers who aren't on old Node.js versions can "just" update to Mocha 12. Then Mocha 13 would start landing behavioral changes.

I haven't talked about this with anybody recently, and was hoping to start a conversation soon. 😄