phated
commented
7 years ago Haven't reviewed the list but want to include @erikkemperman on the thread, as he's been interested in a node-glob replacement.
Open jonschlinkert opened 7 years ago
phated
commented
7 years ago Haven't reviewed the list but want to include @erikkemperman on the thread, as he's been interested in a node-glob replacement.
erikkemperman
commented
7 years ago Well, I was actually thinking of forking node-glob and minimatch to address some minor (and some not so minor) issues, but otherwise keep it close to upstream as much as possible. Unfortunately Isaac doesn't seem to get around to dealing with issues and pull requests very often.
Specific things I thought might be useful, in particular relevant for some ideas I was having for vinyl-fs:
lstat: https://github.com/isaacs/node-glob/pull/336But reviewing the list above this seems like a much more radical departure from node-glob... I think it might well end up being a much nicer library to work with, so I'll keep an eye on it!
Would it make sense to allow interacting with caches, like node-glob does? And how about including results of fs.stat/lstat calls on the file objects?
jonschlinkert
commented
7 years ago @erikkemperman, thanks for the feedback. we'd love to have your continuing feedback and support in building a great globbing library that meets all of our needs. I'll make sure that all of your bullets are addressed too.
Fwiw, to your point about being a radical departure, despite what it sounds like in the checklist, IMHO the new glob-fs API won't be too radical of a departure (from node-glob). There will be a couple of differences, and we're going to expose additional methods, but we're still going to try to make it easy for users to switch without having to think about it too much.
Would it make sense to allow interacting with caches, like node-glob does? And how about including results of fs.stat/lstat calls on the file objects?
We were just talking about this, I think this is a no-brainer. I'm big on caching in general.
I exposed the cache as a non-enumerable property on the returned files array in matched. I haven't looked at that code in a while so I don't remember details, but I'm pretty sure that's the cache you're referring to, correct? edit: that was just an aside... we'll do caching differently here
johnmanko
commented
6 years ago What's the status of this project?
jonschlinkert
commented
6 years ago What's the status of this project?
Tough question to answer. I was going to say "slower than I'd like it to be", but I looked at your profile a minute ago, and now I think this project is absolutely brimming with activity. You know, relatively.
Please see https://github.com/jonschlinkert/idiomatic-contributing#dont.
Locking this issue to collaborators only to prevent more off topic discussion.
This is the tracking issue for v1.0.0, which will be a total re-write from the ground up.
The following wishlist is based on feedback and discussion with @doowb, @phated and others in the community. Please feel welcome to add your thoughts in a comment below.
Checklist
.gitignore, ignoringnode_modulesby default, and so on). This will allow us to keep the core code base focused on fs and matching accuracy and performance, without having to create a huge API surface and dozens of options to cover every edge case.File objects
The following properties will be included (listing these here because I expect the path-related logic to be the most challenging, and I want to make sure we have consensus on what the values of these properties should be):
path: absolute file pathcwd: the "original" cwd that was supplied by the user, or process.cwd()base: the glob "parent"relative: path relative tocwdThe following might be included, and if so might be non-enumerable. Not sure yet.
astthe AST for the glob pattern, created by micromatchsourcemap(whenoptions.sourcemapis true) no idea what these would be used for with globs, but they are provided by micromatch (via snapdragon)