1.0.0 tracking

[jonschlinkert]

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

• cross platform support (better windows support!)
• stream support
• async support
• promise support
• sync support
• micromatch 3.0.0 will be used for glob matching
• Files will be returned as objects by default
• negation support (where subsequent inclusive patterns may not re-include a pattern that has already been excluded)
• optional "ordered negation" support (where subsequent inclusive patterns may re-include a pattern that has already been excluded. similar to wildmatch, with gitignore)
• support for custom fs adapters
• plugin support (so that plugins can be used for things like reading .gitignore, ignoring node_modules by 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 path
• cwd: the "original" cwd that was supplied by the user, or process.cwd()
• base: the glob "parent"
• relative: path relative to cwd

The following might be included, and if so might be non-enumerable. Not sure yet.

• ast the AST for the glob pattern, created by micromatch
• sourcemap (when options.sourcemap is true) no idea what these would be used for with globs, but they are provided by micromatch (via snapdragon)

[phated]

Haven't reviewed the list but want to include @erikkemperman on the thread, as he's been interested in a node-glob replacement.

[erikkemperman]

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:

• Make minimatch and node-glob mutually consistent regarding path separators: Proposal: major release to adopt forward slash, same as node-glob? isaacs/minimatch#109
• Support custom FS adapter: Allow custom fs adapter to be passed as option (#280) isaacs/node-glob#285
• Fix Appveyor tests: Fix win32 test failure isaacs/node-glob#303
• Option to not resolve symbolic links as returned by lstat: Add option to cache lstat results instead of stat isaacs/node-glob#336

But 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]

@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]

What's the status of this project?

[jonschlinkert]

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.