Is it not possible to test .npmignore using this library? about node-ignore HOT 6 CLOSED

I noticed that the docs say:

• Exactly according to gitignore man page, fixes some known matching issues of fstream-ignore, such as:
  • '/*.js' should only match 'a.js', but not 'abc/a.js'.
  • '**/foo' should match 'foo' anywhere.
  • Prevent re-including a file if a parent directory of that file is excluded.
  • Handle trailing whitespaces:
    • 'a '(one space) should not match 'a '(two spaces).
    • 'a \ ' matches 'a '
  • All test cases are verified with the result of git check-ignore.

That's great and everything about better accuracy for .gitignore files. Perhaps NPM deviates somewhat from this standard, by using fstream-ignore. But is there an option to simulate NPM's behavior?

If not, please document more clearly that this library is useless with .npmignore files, because I just wasted an hour trying to debug why there are weird inaccuracies in the selection results. :-)

from node-ignore.

.npmignore does NOT follow the gitignore rules.

fstream-ignore depends on minimatch which basicly follows fnmatch(3) and its specific rules.

So the answer is NO (, it is not possible).

PS: I suggest to always use field package.json.files instead of .npmignore, because we only know which files should be included in the npm tarball

from node-ignore.

Would you consider implementing support for NPM rules as an option? Maybe it is not a difficult enhancement to make.

Alternatively, perhaps the README.md could have a disclaimer making this limitation more clear?

from node-ignore.

PS: I suggest to always use field package.json.files instead of .npmignore, because we only know which files should be included in the npm tarball

This problem is easily solved by inverting the ignore expressions. Our files generally look like this:

# Ignore everything by default
**

# Use negative patterns to bring back the specific things we want to publish
!/bin/**
!/lib/**
!/dist/**

This same solution also works for other files like .prettierignore and .eslintignore, since they were also mistakenly designed as "ignore" lists instead of "include" lists.

The package.json files setting is NOT a good approach. It has a couple downsides:

• Adding project settings to package.json makes that file larger, which hurts installation performance. The NPM registry REST protocol inexplicably transmits the full package.json contents for every historical version of a package. During installation, this HTTP GET frequently has a larger payload than the actual tarball being installed.
• You cannot put code comments in the JSON file. Code comments are a pretty important requirement for a professional scenario such as package publishing.

from node-ignore.

Would you consider implementing support for NPM rules as an option? Maybe it is not a difficult enhancement to make.

If you read the .gitignore spec carefully, you will figure out that npmignore is completely a different story. For npmignore, you could use minimatch (for just pattern parsing) or fstream-ignore (with file system)

Alternatively, perhaps the README.md could have a disclaimer making this limitation more clear?

Yes

from node-ignore.

👍 Thanks!

from node-ignore.