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

Future of minimatch considering path.matchesGlob() #240

Closed
voxpelli opened this issue Aug 22, 2024 · 1 comment
Closed

Future of minimatch considering path.matchesGlob() #240

voxpelli opened this issue Aug 22, 2024 · 1 comment

Comments

@voxpelli
Copy link

Following a discussion on Twitter regarding nodejs/node#52779 / nodejs/node#52881 and whether it (or fs.glob, nodejs/node#51912 / nodejs/node#40731) competes with, complements or helps existing projects such as minimatch I wanted to open an issue to get some kind of a public reference for it.

I can see no collaboration with @isaacs / minimatch on the path.matchesGlob() API, but I do see comments in the fs.glob issue (nodejs/node#40731 (comment)) and I do see that fs.glob (and as such path.matchesGlob()) wraps a bundled minimatch.

For existing users of minimatch: Would the recommendation be to stick with minimatch or to migrate to path.matchesGlob()?

@isaacs
Copy link
Owner

isaacs commented Aug 22, 2024

As I understand it, the path.matchesGlob() implementation is using minimatch more or less as-is from this repo. As it's very stable and hasn't gottten much changes except chores in quite a while that seems perfectly fine.

I don't intend to migrate the glob package (minimatch's most important consumer), for the simple reason that node core doesn't expose all of the Minimatch features that glob uses. And that's fine. I also still use rimraf and mkdirp in many places. (Mkdirp I've been gradually replacing with mkdir(path, { recursive: true }), but the rimraf package is quite a bit more robust at this point than node's rm(path, { recursive: true, force: true }).)

Glob and minimatch also support many node versions that did not include a minimatch implementation. But it might make sense for minimatch to use the built-in if it's available.

So, really, I don't have a strong feeling about it. Use whatever you like. If you have minimatch already in your tree, for some reason, for example because you're using glob, then it's fine to keep using it. fs.glob() is really not suitable for anything more than the most basic small-N use-cases, due to how it's implemented (as you saw me comment in the PR you linked to, no doubt). But if you want to save a dep, I mean, that's totally reasonable.

I see this question less as some sort of "debate" with an "answer" and more as just a shrug. Do whatever you like, it's OSS, it's fine. No reason to worry much one way or another about it.

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

2 participants