Is there an existing issue that is already proposing this?

• I have searched the existing issues

I previously opened a PR for this (#3677), so I understand if this issue is closed. However, I did want the opportunity to share more of my reason behind suggesting the change

Is your feature request related to a problem? Please describe it

fast-glob consists of 18 packages with an install size of 513KB

Describe the solution you'd like

Switch to tinyglobby, which consists of 3 packages with an install size of 162KB

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

Understood, but I thought I'd share my reason for proposing this just in case...

High adoption enables deduplication

Of course fast-glob is widely used so you may question whether switching a library to use tinyglobby just results in more dependencies rather than any savings once dependency deduplication is factored in.

A majority of the top 100 consumers of fast-glob and globby have now fully switched to tinyglobby. Of those that haven't switched, 8 are officially deprecated or legacy and a handful of others are unmaintained with no commits or releases for years, so a very large majority of actively maintained libraries have switched.

For example, 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

Newly created apps using these frameworks no longer have transitive dependencies on any glob libraries other than tinyglobby

For others like Nuxt, SolidStart, and TanStack Start, all dependencies have fully switched to tinyglobby and those frameworks will use solely tinyglobby once they update their dependencies to the latest versions. Most remaining frameworks (i.e. Next) use both tinyglobby and fast-glob.

Many ecosystems now rely almost entirely on tinyglobby — you can now setup a new SvelteKit project with every integration it offers (drizzle, eslint, lucia, mdsvex, paraglide, playwright, prettier, storybook, tailwindcss, vitest, and all SvelteKit adapters) and your project will exclusively use tinyglobby - unless you use chose to use typescript and eslint in which case typescript-eslint pulls in fast-glob.

For projects that are new or have recently updated dependencies, tinyglobby is more likely to be used than fast-glob or globby. On both a relative and absolute basis, tinyglobby usage is growing faster than alternatives. Something important to keep in mind here is that all usage of tinyglobby is on a single release line where as it's split across major versions for alternatives. E.g. globby usage is split across ten versions (v5-14 all have more than 1m downloads/week). This means that the rate at which tinyglobby is being used on new projects compared to alternatives is even higher than raw download numbers might indicate.

Supply chain risk

Having fewer packages reduces the need to have as many people with access to merge and release new versions thus reducing supply chain vulnerabilities, of which we've seen a number of in the npm ecosystem. For example, just recently, users of glob were affected by a supply chain attack in which a dependency - strip-ansi - was compromised. Users of tinyglobby would not have been affected by this particular attack and face far less risk of similar attacks in the future that other glob libraries do.

And for most new and actively updated projects, this isn't just 18 packages vs 3 packages, but 18 new packages vs 3 packages already in your dependency tree.

Performance

tinyglobby is the fastest globbing library available.

Run node --run bench
packages/*/tsconfig.json (typescript-eslint)
┌─────────┬────────────────┬───────────────────┬───────────────────┬────────────────────────┬────────────────────────┬─────────┐
│ (index) │ Task name      │ Latency avg (ns)  │ Latency med (ns)  │ Throughput avg (ops/s) │ Throughput med (ops/s) │ Samples │
├─────────┼────────────────┼───────────────────┼───────────────────┼────────────────────────┼────────────────────────┼─────────┤
│ 0       │ 'tinyglobby'   │ '456457 ± 1.49%'  │ '427974 ± 16605'  │ '2260 ± 0.50%'         │ '2337 ± 93'            │ 2191    │
│ 1       │ 'fast-glob'    │ '579812 ± 2.54%'  │ '543256 ± 32441'  │ '1813 ± 0.60%'         │ '1841 ± 111'           │ 1725    │
│ 2       │ 'glob'         │ '612492 ± 3.46%'  │ '562362 ± 29505'  │ '1731 ± 0.61%'         │ '1778 ± 96'            │ 1633    │
│ 3       │ 'node:fs glob' │ '1170626 ± 1.09%' │ '1157149 ± 73148' │ '869 ± 0.76%'          │ '864 ± 55'             │ 855     │
└─────────┴────────────────┴───────────────────┴───────────────────┴────────────────────────┴────────────────────────┴─────────┘
**/* (typescript-eslint)
┌─────────┬────────────────┬─────────────────────┬───────────────────────┬────────────────────────┬────────────────────────┬─────────┐
│ (index) │ Task name      │ Latency avg (ns)    │ Latency med (ns)      │ Throughput avg (ops/s) │ Throughput med (ops/s) │ Samples │
├─────────┼────────────────┼─────────────────────┼───────────────────────┼────────────────────────┼────────────────────────┼─────────┤
│ 0       │ 'tinyglobby'   │ '24789520 ± 3.19%'  │ '23973377 ± 644311'   │ '41 ± 2.24%'           │ '42 ± 1'               │ 64      │
│ 1       │ 'fast-glob'    │ '50366452 ± 3.48%'  │ '50897896 ± 6895020'  │ '20 ± 3.33%'           │ '20 ± 3'               │ 64      │
│ 2       │ 'glob'         │ '60154522 ± 2.01%'  │ '60383243 ± 2965111'  │ '17 ± 2.06%'           │ '17 ± 1'               │ 64      │
│ 3       │ 'node:fs glob' │ '208721426 ± 1.68%' │ '207200996 ± 8277252' │ '5 ± 1.66%'            │ '5 ± 0'                │ 64      │
└─────────┴────────────────┴─────────────────────┴───────────────────────┴────────────────────────┴────────────────────────┴─────────┘

Stability

tinyglobby is a newer library, so you may ask whether switching to it introduces a higher risk of bugs. It is true that libraries take time to mature and in tinyglobby's earlier days some projects faced regressions. However, those issues have all now been fixed. With such widespread adoption by high profile widely-used projects in the ecosystem, any bugs in tinyglobby are found and reported quickly. Each issue has been patched with an included test and as a result tinyglobby now has over a hundred individual tests. When there has been a bug in tinyglobby, it's been relatively straightforward to identify whether it's in tinyglobby itself or one of its two dependencies. It can be much harder to track down an issue in a library with 17 dependencies or even to see all of the issues across all of the repos that might be present. In fact, fast-glob and its dependencies together have roughly twice as many open issues as tinyglobby and its dependencies combined. tinyglobby has been very actively maintained and has the support of the e18e community, so there has always been multiple contributors willing to look at issues.

tinyglobby now has 37m downloads/week coming from well known projects like vite, pnpm, and node-gyp showing that it has been widely adopted. With the majority of widely used actively maintained projects in the JS ecosystem having switched, this project would not be an early or even mid-stage adopter.