Ooh nice spot! I'm in favor of this personally. 👍

Ooh nice spot! I'm in favor of this personally. 👍

In case the proposal is accepted, I am wondering whether the change should be introduced to v8 only, or backport it to v7 as well. What do you think?

Both libraries are quite large. What about using something smaller like fdir?

Compare https://npmgraph.js.org/?q=fast-glob vs https://npmgraph.js.org/?q=fdir

See rollup/plugins#1741 for an example of switching

Both libraries are quite large. What about using something smaller like fdir?

The user-land config of typescript-eslint supports extended glob patterns, thus we have to choose one that has first-party glob pattern supports, where picomatch doesn't have.

typescript-eslint is currently Node 18+. Once you reach Node 22 (end of the year?) you will be able to use the native globbing library for a total of 0k and 0 dependencies 😃

• fs: expose glob and globSync nodejs/node#51912
• https://nodejs.org/en/blog/announcements/v22-release-announce#glob-and-globsync

We (and the entire ecosystem really) won't drop node 18 till it's EOL - 2025-04-30.
Same for v20 - 2026-04-30.

https://github.com/nodejs/Release?tab=readme-ov-file#release-schedule

Also, there might be some behavior differences between fast-glob and Node.js glob. And Node.js built-in glob is not stable yet.

just my two cents: after weeks of trying to replace globby with lighter alternatives i've published tinyglobby which only uses two subdependencies. maybe not outright switching to it but it could be an option once it gets more battle tested in other packages

I don't really have a problem with switching out the underlying library for globbing.
If we're not using any of the features globby adds and there isn't any visible change for users in terms of supported glob patterns -- then we're free to do whatever without a major release.

If we can make things faster and / or smaller without too much effort then happy for it to be done!

So we have #9518 and #9878.
Do we replace globby with tinyglobby or fastglob.
Is one better than the other? I don't have an opinion either way, personally.

cc @typescript-eslint/triage-team

Do we replace globby with tinyglobby or fastglob. Is one better than the other? I don't have an opinion either way, personally.

@bradzacher

tinyglobby is more lightweight than fast-glob, but I don't know which one is more performant.

Since finding the corresponding tsconfig.json file for the current linting file is a hotpath, we might wanna merge this one first since fast-glob is consistently faster and more predictable (the globby we want to replace is powered by fast-glob under the hood, hence the behavior match). We can investigate tinyglobby later.

@benmccann What do you think?

fast-glob has 17 dependencies whereas tinyglobby has 2. It varies based on the input, but from what I've seen tinyglobby is a bit faster than fast-glob

I've gotten the CI green now on #9878 based on including some of the changes from this PR. I think we could probably just merge that one since tinyglobby is both smaller and faster

I didn't include the change from #9518 (comment) since it was unrelated to switching glob libraries. I could update my PR to include it if desired or maybe that PR could be updated to just have that change or the change could be submitted as a new PR

fast-glob is very well established and it's very common usage across other heavily used packages likely makes the dependency point less relevant in practice (they will be deduped a lot). I would personally rather go for an established library here. Maybe we can revisit in the future if tinyglobby gains wider adoption (it was literally created during the lifecycle of this issue so it's as nascent as it gets right now)

While tinyglobby is pretty new, most of the logic is in more established libraries it uses as dependencies such as picomatch, which is also used by fast-glob under the covers. The tibyglobby code is so small there's little room for bugs in it. And it's already used well over 100,000 times/week. fast-glob would have to be used in about 90% of projects with none using tinyglobby for consumers to come out ahead from deduping since it has so many more dependencies. I actually have tinyglobby in my dependency tree multiple times already because a number of other libraries have switched. Nuxt just switched to it a few days ago: https://github.com/nuxt/nuxt/pull/28686/files

As a first step let's go to fast-glob as it's:

• a natural single-step progression downward
• is 100% known to handle the same cases as globby
• is a well-established library with 44m weekly DLs
  • As James mentions -- this means it's highly likely to already be in a project's dep tree.
  • I.e. we already have 9 references to it in our yarn.lock.

In future I'm open to revisiting this and switching to tinyglobby instead when it gains a bit broader adoption.
But yeah let's go with one step-at-a-time.