This code snippet is not behaving how I would expect.

var dotignore = require('dotignore')
var matcher = dotignore.createMatcher('tmp/\n')
console.log(matcher.shouldIgnore('tmp/myfile.js')) // incorrectly returns `false`

This differs from how git handles the same string. If you put tmp/ in a line of a .gitignore file, you'll see that everything inside the tmp folder is ignored.

I believe this line (

Can we fix the behavior to match what git does?

I ran into an unexpected issue using standard-version, which relies on this package, where a line comment in the .gitignore file caused an unexpected behavior.

File System
package.json

.gitignore (auto-generated for my projects with something akin to the following

## TODO: If the tool you use a package structure, uncomment the next line
# !package

From my initial investigation, dotignore will modify the second line from # !package to !package in the code block below.

var commentLine = line[0] === '#'; // true
var negatedLine == line[0] === '!'; // false since the comment character is still in the initial position
if (negatedLine || commentLine || rootedLine) {
      line = line.substring(1);
}

Although it passes the commentLine boolean via the options object to the minimatch RegularExpression creator, that value is never used inside the minimatch method. Instead, the minimatch.make method repeats a similar check pattern.charAt(0) to suppress including comment lines from the regular expression set. There's some interesting interplay between the # character already having been removed and negatedLine not correctly evaluating to true--the character isn't at the zero index position in this example. At the end, the ignore pattern looks like package, which doesn't seem like the desired behavior for a commented line.

I have a local test case that confirms a potential solution, i.e., removing commentLine from the list of conditions that will substring the source string.

See conventional-changelog/standard-version#230 (comment)

In order to use this library in a Windows-friendly way, you have to change the default delimiter value. Seems like it would be better to default to require('path').sep instead, so that matching against os-specific paths would work cross-platform out of the box.

I'd love to use this library in standard-version to parse the .gitignore, but it looks like minimatch has a security vulnerability.

 deprecated [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

If you don't get to it first, I'll submit a patch ASAP.