Replace glob with tinyglobby, minimatch with micromatch

[wojtekmaj]

This PR replaces two key dependencies to make test-exclude install size smaller and improve performance. Both replacement dependencies are reputable, popular packages used widely by other equally reputable projects (e.g. Vite).

• glob was replaced with tinyglobby (install size: 3.36 MB, 158 KB respectively)
• minimatch was replaced with micromatch (install size: 490 KB, 235 KB respectively)

Dependency tree before:

Dependency tree after:

Fixes #51
Supersedes #63

[PrasathHari]

Would love to see this PR merged as the glob package has some vulnerabilities and popular build tools are already using tinyglobby.

[benmccann]

To expand on that, see the tinyglobby blog post on the e18e site: https://e18e.dev/blog/tinyglobby-migration.html. There's lots of reasons to make the switch including performance and ecosystem adoption

An excerpt:

A whole raft of popular build tools now rely solely on tinyglobby for glob functionality:

• Vite
• SWC
• copy-webpack-plugin
• tsup
• tsdown
• unbuild
• nx
• lerna
• and many more...

None of these tools have a deep dependency on other glob libraries - all of them use tinyglobby all the way down 🎉

Similarly, many popular frameworks have made the same move:

• React Router
• Preact
• Angular
• SvelteKit
• Astro
• Starlight
• Eleventy

New apps using these frameworks will no longer have deep dependencies on multiple glob libraries.

For others like Nuxt, SolidStart, and TanStack Start, all dependencies have fully switched to tinyglobby and those frameworks will only use tinyglobby once they update their dependencies. Most remaining frameworks use both tinyglobby and fast-glob.

Some ecosystems now rely almost entirely on tinyglobby — Svelte maintainer benmccann has switched over most of the Svelte ecosystem to using tinyglobby. Once the pending PR to typescript-eslint is merged, you will be able to setup a new SvelteKit project with every integration it offers and your project will exclusively use tinyglobby. Many other notable projects such as pnpm, node-gyp, and eslint-import-resolver-typescript have made the switch as well.

[43081j]

@bcoe can we have this?

most of c8's bloat comes from this subtree of dependencies, not to mention this will also be much faster

@benmccann will know better than me but i also suspect we could switch to picomatch. the obscure brace expansion stuff micromatch offers is barely used in the wild iirc

[jakub-vaillant]

@bcoe Can you accept this? Its such a small change, and it's really necessary

[bcoe]

@bcoe Can you accept this? Its such a small change, and it's really necessary

@wojtekmaj @jakub-vaillant I appreciate this PR, but I barely touch this package any more and am going to take the approach of updating the existing dependencies.

The beauty of open source, is if folks are relying on this heavily you shouldn't hesitate to fork nyc and swap out the dependencies 👍 I'll almost assuredly end up breaking things since I never use this library any more personally.

[43081j]

It is very expensive to start an ecosystem-wide migration from c8 to a fork of c8. It is an option but it would be much nicer to update the existing package so consumers can benefit immediately via updates rather than having to migrate.

Have you considered adding maintainers who do use this library (and c8)?