Is the "files" property necessary in package.json?

It looks like the package will include all files (that are not ignored), even if the package.json has no "files" array.

Is that property necessary?

4 Answers

You can think of the files property in package.json as an allowlist of all files that should be included in a npm release and .npmignore as a denylist of all files that should not be included.

As a rule of thumb, for my own projects I usually use:

• files when my project has lots of auxiliary files like build scripts, config files, etc., that do not need to be included in a npm release
• .npmignore when there are only a few such auxiliary files

Both options are useful in different scenarios in my mind.

Not really, you can do everything using .npmignore because all files are added unless otherwise stated.

You can see more here

This article makes a good argument for using the files property (a whitelist, as F Lekschas said), instead of using .npmignore. Reasons include:

• Using .npmignore causes .gitignore to be ignored, which may be unexpected by many developers.
• Often developers keep credentials in a package for development purposes, and they certainly don't want to include them in a production package. Using a whitelist technique greatly reduces the likelihood of accidently packaging stuff like this.

Note that some files are included even if you don't whitelist them. These include:

package.json
README
CHANGES / CHANGELOG / HISTORY
LICENSE / LICENCE
NOTICE
The file in the “main” field

Edited to address comment.

When there is no .npmignore file, the contents of .gitignore will be used. So be careful when adding generated directories like dist/to your .gitignore as they might end up not being in your production tarball. When that happens, you can use the "files" array in package.json to include them, as includes from that file will never be excluded.