📦 Package: Bump glob from 10 to 11

[JoshuaKGoldberg]

Feature Request Checklist

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

Overview

Back in #5148 -> #5250, we'd noted:

We can't yet use glob@11, as it only supports Node.js 20 up and Mocha 11 still supports Node.js 18.

Filing this issue to track bumping to glob@11 after/when we drop Node.js 18 support.

Suggested Solution

Bumping the version in package.json once it wouldn't break any consumers on supported Node.js versions.

Alternatives

We could stay on the old version. But it's a pretty important dependency and it'd be nice to not grow more and more out of date over the years (again).

Additional Info

No response

[mark-wiemer]

Note that Node 18 goes EOL 2025-04-30, @JoshuaKGoldberg what is Mocha's general guidance for dropping Node support? I know we like to support old versions but when something is clearly EOL... 😬

[JoshuaKGoldberg]

Yeah, we don't really have a lot of specifics 😅. https://github.com/mochajs/mocha/issues/5332#issuecomment-2796843106 is my personal hopes, not yet verified with anybody. For Mocha 11 we just went with roughly what was non-LTS and supported by other common tools at the time (#5216).

We definitely can't breaking change increase the minimum version numbers outside of major versions.

[beeequeue]

If you'd be open to it I could look into replacing glob with tinyglobby or fdir + picomatch (which tinyglobbyis a wrapper around)

tinyglobby is used by Vite, and fdir by Rollup

I saw the comment mentioning alternatives to minimatch in #5333, and could look into replacing it with picomatch at the same time

[JoshuaKGoldberg]

Not a bad idea! My personal opinion is that it's probably safest to stick to the same libraries for now (Mocha 12) and look at swapping to a leaner library for 13. ACK on the size savings for moving, I just worry that because so many projects rely on Mocha, even minor differences in the libraries would risk an accidental breakage to some edge case users on upgrade.

But, if anybody on the team feels strongly on switching to tinyglobby in Mocha 12 rather than 13+, I wouldn't block.

[beeequeue]

I've been trying my hand at it for fun and there are some issues with swapping effortlessly - details like glob returning absolute paths if the input is an absolute path, or handling back-slashes in the input (which technically shouldn't be allowed in a glob, but the tests expect it).

I also think I found a bug in tinyglobby that I'm debugging.

[beeequeue]

I have some updates from the testing and work I did.

Most of the complexity comes from supporting globs with windows' back-slashes instead of unix slashes, which is non-standard for globs.

I think the best solution would either be to simply drop support for globs with windows separators in v13, or refactoring the config/input parsing to convert windows separators to unix ones, so the code always handles paths with forward-slashes.

---

As for the bug(s) with tinyglobby, they are specific to windows and most likely only occur because of the way Mocha runs its tests.

Bug 1. is that if you pass a glob/path that only shares the root (C:/) with the CWD, it will freeze. (This was fixed for unix paths but not windows.) This shows up for Mocha because it was running tests in the temp folder C:/.../Local/Temp/mocha-x from the project directory (for me: C:/dev/mocha)

Bug 2. is that tinyglobby cannot handle scanning two drives at once, so passing ["C:/*.js", "F:/*.js"] will not work. I do not think this is a common user pattern for Mocha.