Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to fast-glob? #317

Closed
phated opened this issue May 13, 2020 · 4 comments
Closed

Switch to fast-glob? #317

phated opened this issue May 13, 2020 · 4 comments

Comments

@phated
Copy link
Member

phated commented May 13, 2020

It looks like fast-glob implements something very similar to our glob-stream library. Should we switch to use it instead of maintaining that ourselves? Honestly, I'd like the glob stuff to live inside the gulpjs org because we've had so much problems with node-glob in the past.

Ref gulpjs/glob-parent#26 (comment)

cc @mrmlnc @coreyfarrell @erikkemperman

@terinjokes
Copy link

Honestly, I'd like the glob stuff to live inside the gulpjs org

I second this for the same reason; we keep being burned by external projects with no API stability guarantees.

@phated
Copy link
Member Author

phated commented May 14, 2020

Their docs also state:

⚠️ This package does not respect the order of patterns. First, all the negative patterns are applied, and only then the positive patterns. If you want to get a certain order of records, use sorting or split calls.

Which is functionality that gulp users rely on heavily, so that might be a problem.

@coreyfarrell
Copy link
Member

This idea is concerning due to globbing being a minefield of edge cases. I'm not saying it's a bad idea just that any action here is scary and almost guaranteed to produce bug reports from users. nodejs/tooling#38 is probably worth a look since it had some discussion comparing glob/minimatch vs fast-glob/micromatch.

One thing that would make me more comfortable would be a data set that can be iterated for compliance testing to be run against both modules (maybe minimatch vs micromatch instead of glob vs fast-glob). This is a big ask so I'm not expecting anyone to make this effort, just thinking out loud that movement between glob implementations would be easier if we could generate a report showing things that are expected to start or stop working. I don't think this effort would be worth while without buy-in from authors of both minimatch and micromatch, we'd want the data set to be structured so those modules could actually use it to generate large parts of their own test coverage.

@phated
Copy link
Member Author

phated commented Nov 21, 2022

I'm closing this out since we are going to stick with glob-stream which will be using a custom walkdir and anymatch (to align with chokidar's use of anymatch).

@phated phated closed this as completed Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants