Reputation: 20249
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?
Upvotes: 65
Views: 62545
Reputation: 446
I can add something to this discussion from much trial and error. What files
property does is locating the directories to be npm pack
-aged.
So if you are creating a component library, for example, then files
should point to the dist
or lib
folder which it creates after npm run build
.
Upvotes: 3
Reputation: 12800
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 filesBoth options are useful in different scenarios in my mind.
Upvotes: 72
Reputation: 1639
Not really, you can do everything using .npmignore
because all files are added unless otherwise stated.
You can see more here
Upvotes: 30
Reputation: 1323
This article makes a good argument for using the files property (a whitelist, as F Lekschas said), instead of using .npmignore. Reasons include:
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.
Upvotes: 18
Reputation: 1561
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.
Upvotes: 12