Why is npm not honoring user/global npmignore?

Question

My editor produces workspace files and backup folders which are of no interest to users of the software I write. In order to avoid having to list my editor-specific ignores in each project, I'm trying to tell npm to ignore them at the user or global level.

Unfortunately, I'm having no luck doing so. Running npm pack inside my project folder, even if I clear the npm cache first, includes both the workspace file and and two megabytes of backup files. (For a project with only ten kilobytes of code!) I've tried the ignore config setting, a per-user .npmignore, and a global npmignore, all to no effect.

Here's my output from npm config ls -l, snipped to relevant sections:

; userconfig C:\Users\benblank\.npmrc
ignore = "__history *.epp"

; builtin config undefined
prefix = "C:\\Users\\benblank\\AppData\\Roaming\\npm"

; default values
globalignorefile = "C:\\Users\\benblank\\AppData\\Roaming\\npm\\etc\\npmignore"
userignorefile = "C:\\Users\\benblank\\.npmignore"

And the (identical) contents of C:\Users\benblank\.npmignore and C:\Users\benblank\AppData\Roaming\npm\etc\npmignore:

__history
*.epp

What am I doing wrong? I'm running Windows 7, [email protected], and [email protected].

Answer 1

npm has some major outstanding issues related to npmignore files.

Thankfully there is an even better alternative! It is the package.json files property.

Here is an example from my delivr project.

"files": [
  "lib",
  "index.js"
]

Why is it better?

1. The internal machinery makes this mechanism more reliable.
2. It is a whitelist instead of a blacklist. Typically, assuming you use a lib folder (or similar), there are less files/directories you want included vs those you want excluded, so it is more succinct.
3. It is DRY. If a .npmignore file exists, npm will not consult .gitignore for ignore patterns, which often needs overlapping and repetitive info. This problem does not exist with a whitelist.
4. One less file in the repo. package.json is already a manifest that defines your package and it makes a ton of sense for this configuration to live there.