"**/" pattern doesn't match "./" path part

[cowboy]

This seems like a bug to me, intuitively, but I don't see it addressed in the docs anywhere:

var minimatch = require("minimatch");

minimatch("foo/bar.js", "**/foo/**")     // true
minimatch("./foo/bar.js", "./**/foo/**") // true
minimatch("./foo/bar.js", "**/foo/**")   // false

Shouldn't the last example return true because **/ should match ./?

Ref. cowboy/node-globule#11

[corbanbrook]

This may be related to an issue i am having trying to match a file in a hidden dir.

minimatch("/Users/corban/.go/src/app.js", "**/app.js") // false

[Rich-Harris]

@corbanbrook I had a similar issue - #51 - and solved it by passing {dot: true} as the third argument to minimatch():

minimatch("/Users/corban/.go/src/app.js", "**/app.js", {dot: true}) // true

This doesn't fix @cowboy's case though:

minimatch("./foo/bar.js", "**/foo/**", {dot: true}) // false

[implico]

So, why don't we fix this? This also breaks such packages as gulp-filter functionality, also with patterns containing "../", what is sometimes quite essential.

[cb1kenobi]

+1. It would really be nice if minimatch supported .. so that gulp-filter worked. It just came up again the other day: sindresorhus/gulp-filter#67 (comment).

[Lucas-C]

👍

Actually hidden files NEVER match :

var minimatch = require('minimatch').Minimatch;

var matcher = minimatch('**');

console.log(matcher.match('bob')); // true
console.log(matcher.match('.bob')); // false

I tested this behaviour with minimatch v0.3.0, v2.0.7 & v3.0.2

[Lucas-C]

And yes, this affects any file with a directory starting with a dot anywhere in its full path.
E.g. /home/bob/.jenkins/jobs/HellowWorld/workspace/snafu.js will NEVER match any **-based pattern.

I think this is a major issue.

[Lucas-C]

Please disregard my previous comments: I found out about {dot: true}.

I think this really shoud be the default behaviour though.

[pospi]

Agree this should be default behaviour- if there's a directory named .somedir within a path, then it should still be matched by a directory wildcard (**), no?

Or is it a standard shell feature to ignore hidden folders, and that's the API you'd prefer to mirror? I can understand that, too.

[diogolessa]

I know this is an old issue, but I manage to fix my problem with matchBase option.
In my case, I wanted that all .scss files - regardless the folder level - were matched. Using **/.scss didn't solve the problem, but the matchBase: true did.

[FlorianWendelborn]

For anyone struggling with @diogolessa’s solution, use *.scss instead of **/*.scss. matchBase seems to work very well this way.

[isaacs]

** does not match . unless {dot:true} is set, and even if it is set, it does not ever match . or .. as path portions.

Paths starting with ./ and ../ never match a pattern that doesn't start explicitly with ./ or ../, even if {dot:true} is set.

This is by design, and matches the behavior of bash 4.3+.

[kimurakenshi]

I'm new to minimatch and I'm struggling exactly with this. By reading the last comment it seems there is no valid pattern to match a portion of a path when dots are present unless I specify all the possible combinations, right?

[isaacs]

As stated back in February, * and ** (and other wildcard patterns) do not match path portions starting with . unless {dot:true} is set, and ** will not never match . or .. as path portions. (Otherwise you'd have an infinite regress; if a/b/c exists, then a/./b/./c also exists, as does a/././b/././c etc. Should ** return an infinite list of entries?)

If you are receiving paths that may contain . or .. in them (for example, you have a pattern like a/b/c and the user can pass in a/./b/c, and expects a match), I recommend resolving those prior to passing them to minimatch. You can do this using the join or resolve methods in Node's built-in path module.

[kimurakenshi]

Thank you for your answer. I'm using eslint import plugin, specifically the order rule that allows you to define your own path groups and the pattern option uses minimatch. By reading your last comment it looks like minimatch is not the right solution here since there is no way I can predict all the possible patterns an import could have. It depends on whether you are importing a module from, so it might or might not have a dot or .. at the beginning. I will try the dot option and see how far I can get with that. Thank you again for your answer,there is nothing wrong with minimatch, I just wanted to provide more context about my use case.

[ljharb]

@kimurakenshi the import plugin has another rule that requires a normalized path; i suggest using that as well.

[kimurakenshi]

Thank you, I wasn't aware of that rule, I will check that out then. I appreciate the help on this.

[kimurakenshi]

@ljharb do you happen to remember which rule exactly requires normalizes paths in eslint-import? I tried https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-relative-packages.md but I don't think that is the one.
Thank you.

[ljharb]

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-useless-path-segments.md If you have further questions, please file them on eslint-plugin-import so we don't create more noise here.