Modern Full-Stack Development

optionalDependencies – If your package has dependencies and 
NPM can’t install them, then it will fail the installation of your 
package. If, however, you want to specify that some dependencies 
are okay to be missing and that NPM should go ahead with the 
installation anyway, then optionalDependencies is where you can 
list them.
• 
os – Just like cpu, if your package only works on certain OSs, then this 
element is where you can have an array of strings naming those it 
runs on.
• 
peerDependencies – Sometimes, a package will function as a plugin 
to others, and so you’ll need a way to define what other packages 
yours is compatible with. The peerDependencies element allows you 
to do that.
• 
private – If you want to ensure that you can’t accidentally publish 
your package, then set private to false, and NPM will refuse to publish 
it (more to come on publishing in the next section).
• 
publishConfig – This element is an object that defines many pieces 
of metadata that come into play with publishing your package to the 
NPM registry. This includes things like tags and such. This can get 
fairly involved, and we won’t (for the most part) be worrying about 
any of it in this book beyond a few words in the next section, so I’ll 
leave this one to the NPM documentation if and when you need it.
• 
repository – If you’d like to specify where the code for your package 
lives, whether GitHub or something else, whether public or private, 
the repository element is where you do that.
Chapter 2   a Few More words: advanCed node and npM

---

25
• 
scripts – As mentioned in the previous chapter, the scripts element 
allows you to specify a dictionary of commands that can be run at 
various points in the lifecycle of your package for various purposes. 
Like publishConfig, this can get a bit involved, so I defer to the NPM 
docs for details.
• 
version – This is the version of your module, and it must use SemVer 
as discussed in Chapter 
1
. The name and version values together 
form a unique “coordinate” to your package, an identifier that 
is assumed to be completely unique. If you plan to publish your 
package, then name and version are the most important elements 
in package.json (if you don’t publish it, then they’re a bit less 
important, but for your own sanity, you should probably make them 
meaningful anyway!).
You know, I said a few times that I’m deferring to the NPM docs on a few things, but 
that’s true of all of those! This isn’t meant to be a reference guide detailing every option; 
it’s just meant to be a survey of the elements, so you have a rough idea what’s available. 
If and when you need to use these, at least for the ones that aren’t simple, single values, 
then the NPM docs at 
docs.npmjs.com
 are where you’ll need to visit. There’s a section 
dedicated to the contents of package.json that goes over every last detail you could 
need or want.