-
-
Notifications
You must be signed in to change notification settings - Fork 290
Description
At the moment, if developers want to test a path against multiple minimatch patterns at once, there's not really a good option to both maximise correctness and performance - the two options I can see are:
- Create a minimatch instance for each pattern, and run
matchwith the path on each of them. This is the most correct/compatible method, but comes with a lot of overhead inmatchrelated to repeating the same pre-processing of the path into the split path. - Extract the pre-processing code from
match, generate the split path array manually, and then extractthis.setfrom each instance and runmatchOneagainst the parse results. This is more performant, but requires poking at internals and copying code that may well change in future versions.
I'd like to suggest adding an API surface to handle the (I would expect pretty common) case of needing to match paths against multiple patterns at once.
My initial thoughts of what this could look like would be to add either-or-both some simple static helper methods to Minimatch, or go all out and create an explicit MinimatchSet (or similar) class that encapsulates multiple patterns together, and could in the future be potentially expanded to do more optimization among the multiple patterns (e.g. if multiple patterns have a shared prefix, they could be partially combined)
Thoughts on potential API shape:
class Minimatch {
public static matchAll(path: string, patterns: Minimatch[], partial: boolean): boolean;
public static matchAny(path: string, patterns: Minimatch[], partial: boolean): boolean;
}class MinimatchSet {
public constructor(patterns: string[], , options: MinimatchOptions = {});
public matchAll(path: string): boolean;
public matchAny(path: string): boolean;
public getFirstMatchingPattern(path: string): string;
public getMatchingPatterns(path: string): string[];
}I'm happy to put some time into fleshing this out if it's something you'd like to pursue adding to the library 😄