What goes in .npmignore?
This posts comes out of a question I answered at StackOverflow.
The asker goes on to ask: What should you really put in your
.npmignore file? The answer, surprisingly, isn’t entirely obvious, at least form an official documentation perspective.
Many people don’t even use it as everything in your
.gitignore is ignored in npm by default if
.npmignore doesn’t exist. Additionally, many files are already ignored by default regardless of settings and some files are always excluded from being ignored, as outlined in the link above.
There is not much official on what always should be there because it is basically a subset of
.gitignore, but from what I gather from using node for 5-ish years, here’s what I’ve come up with.
Note: By production I mean any time where your module is used by someone and not to develop on the mdoule itself.
Pre-release cross-compiled sources
.coffeefiles in your package but keep tracking them in your git repository.
Build file leftovers
- Pros: People using things like
node-gypmight have object files that get generated during a build that never should go into the package.
- Cons: This should always go into the
.gitignoreanyway. You must place these things inside here if you are using a
.npmignorefile already as it overrides
.gitignorefrom npm’s point of view
- Pros: Less baggage in your production code.
- Cons: You cannot run tests on live environments in the slim chace there is a system-specific failure, such as an out of date version of node running that causes a test to fail.
Continuous integration settings/Meta files
- Pros: Again, less baggage. Things such as
.travis.ymlare not required for using, testing, or viewing the code.
Non-readme docs and code examples
- Pros: Less baggage. Some people exist in the school-of-thought where if you cannot express at least minimum viable functionality in your Readme, your module is too big.
- Cons: People cannot see exhaustive documentation and code examples on their own file system. They would have to visit the repository (which also requires an internet connection).
- Pros: You certainly don’t need to litter your releases with
CNAMEfiles or placeholder
index.htmls if you use your module serves double-duty as a
gh-pagesbranch as well.
bower.json and friends
- Pros: If you decide to build in your dependencies prior to release, you don’t need the end-user to install bower then install more things with that. I would, personally, keep that stuff in the package. When I do an
npm install, I should only be relying on npm and no other external sources.
Basically, you should ever use it if there is something you wish to keep out of your npm package but not out of your npm repository. It’s not a long list of items, but npm would rather build in the functionality than having people stuck with irrelevant objects in their package.
When making your NPM package, just remember to only include things that people will need to use it.
(From My Answer)