what is this?

[jonschlinkert]

After creating and maintaining a number of different globbing/matching libraries, and having dealt with a number of matching-related issues and edge cases, it has become apparent that the biggest challenge in providing users with a consistent experience is that we don't have a specification for how matches should be performed.

If you maintain a globbing library, you will have dealt with at least a few issues related to the following:

• negation / ignoring
• windows paths
• escaping
• directory matching
• dotfile matching
• multiple pattern matching
  • inclusive vs exclusive matching
  • depth-first vs breadth-first matching
• absolute vs relative paths

  Is a spec really needed?

I think it is, given that:

1. globbing has become an indispensable part of our tooling, not just in node.js but well-beyond the world of Bash.
2. Some things that make sense in Bash make no sense at all in node.js, and vice versa
3. there is no established standard for how matching should be done outside of Bash, and not everyone agrees on the details
4. What we think of as "globbing" is actually a mashup of several different glob specifications, including
   • bash pathname expansion (or "filename expansion")
   • bash brace expansion
   • tilde expansion
   • POSIX character classes
   • extglobs (extended globs)
   • kleene stars
   • ksh
   • wildmatch (git)
   • regular expressions

Moreover, none of these different specifications (aside from regex) are complete to the point of resolving conflict on edge cases, and where they are specific they don't always agree on what the resolution should be.

Moving forward

Phase 1

We can begin by looking across the existing specifications and attempting to identify both common ground and areas of uniqueness where no conflicts in feature-functionality exist, and from there a new specification that incorporates these things will begin to take shape. This will represent "Phase 1".

Phase 2

Next, we will focus on areas of conflict between the specs and work to resolve them through consensus with maintainers, and feedback from the community.

Phase 3

We will address any new feature-functionality that is not sufficiently covered (or covered at all) in any existing specifications.

cc @phated @doowb @es128 (in case you're interested in being involved or providing feedback on this. I will work on this as I have time, so we can use it to guide decisions and documentation on our own projects. feel free to loop others into the convo)

[phated]

Thanks @jonschlinkert! I'll definitely be following this. I don't have much to add currently.