deps/npm/html/doc/files/npm-json.html

   1 <!doctype html>
   2 <html>
   3   <title>package.json</title>
   4   <meta http-equiv="content-type" value="text/html;utf-8">
   5   <link rel="stylesheet" type="text/css" href="../../static/style.css">
   6
   7   <body>
   8     <div id="wrapper">
   9 <h1><a href="../files/package.json.html">package.json</a></h1> <p>Specifics of npm&#39;s package.json handling</p>
  10
  11 <h2 id="DESCRIPTION">DESCRIPTION</h2>
  12
  13 <p>This document is all you need to know about what&#39;s required in your package.json
  14 file.  It must be actual JSON, not just a JavaScript object literal.</p>
  15
  16 <p>A lot of the behavior described in this document is affected by the config
  17 settings described in <code><a href="../misc/npm-config.html">npm-config(7)</a></code>.</p>
  18
  19 <h2 id="DEFAULT-VALUES">DEFAULT VALUES</h2>
  20
  21 <p>npm will default some values based on package contents.</p>
  22
  23 <ul><li><p><code>&quot;scripts&quot;: {&quot;start&quot;: &quot;node server.js&quot;}</code></p><p>If there is a <code>server.js</code> file in the root of your package, then npm
  24 will default the <code>start</code> command to <code>node server.js</code>.</p></li><li><p><code>&quot;scripts&quot;:{&quot;preinstall&quot;: &quot;node-waf clean || true; node-waf configure build&quot;}</code></p><p>If there is a <code>wscript</code> file in the root of your package, npm will
  25 default the <code>preinstall</code> command to compile using node-waf.</p></li><li><p><code>&quot;scripts&quot;:{&quot;preinstall&quot;: &quot;node-gyp rebuild&quot;}</code></p><p>If there is a <code>binding.gyp</code> file in the root of your package, npm will
  26 default the <code>preinstall</code> command to compile using node-gyp.</p></li><li><p><code>&quot;contributors&quot;: [...]</code></p><p>If there is an <code>AUTHORS</code> file in the root of your package, npm will
  27 treat each line as a <code>Name &lt;email&gt; (url)</code> format, where email and url
  28 are optional.  Lines which start with a <code>#</code> or are blank, will be
  29 ignored.</p></li></ul>
  30
  31 <h2 id="name">name</h2>
  32
  33 <p>The <em>most</em> important things in your package.json are the name and version fields.
  34 Those are actually required, and your package won&#39;t install without
  35 them.  The name and version together form an identifier that is assumed
  36 to be completely unique.  Changes to the package should come along with
  37 changes to the version.</p>
  38
  39 <p>The name is what your thing is called.  Some tips:</p>
  40
  41 <ul><li>Don&#39;t put &quot;js&quot; or &quot;node&quot; in the name.  It&#39;s assumed that it&#39;s js, since you&#39;re
  42 writing a package.json file, and you can specify the engine using the &quot;engines&quot;
  43 field.  (See below.)</li><li>The name ends up being part of a URL, an argument on the command line, and a
  44 folder name. Any name with non-url-safe characters will be rejected.
  45 Also, it can&#39;t start with a dot or an underscore.</li><li>The name will probably be passed as an argument to require(), so it should
  46 be something short, but also reasonably descriptive.</li><li>You may want to check the npm registry to see if there&#39;s something by that name
  47 already, before you get too attached to it.  http://registry.npmjs.org/</li></ul>
  48
  49 <h2 id="version">version</h2>
  50
  51 <p>The <em>most</em> important things in your package.json are the name and version fields.
  52 Those are actually required, and your package won&#39;t install without
  53 them.  The name and version together form an identifier that is assumed
  54 to be completely unique.  Changes to the package should come along with
  55 changes to the version.</p>
  56
  57 <p>Version must be parseable by
  58 <a href="https://github.com/isaacs/node-semver">node-semver</a>, which is bundled
  59 with npm as a dependency.  (<code>npm install semver</code> to use it yourself.)</p>
  60
  61 <p>More on version numbers and ranges at <a href="../misc/semver.html">semver(7)</a>.</p>
  62
  63 <h2 id="description">description</h2>
  64
  65 <p>Put a description in it.  It&#39;s a string.  This helps people discover your
  66 package, as it&#39;s listed in <code>npm search</code>.</p>
  67
  68 <h2 id="keywords">keywords</h2>
  69
  70 <p>Put keywords in it.  It&#39;s an array of strings.  This helps people
  71 discover your package as it&#39;s listed in <code>npm search</code>.</p>
  72
  73 <h2 id="homepage">homepage</h2>
  74
  75 <p>The url to the project homepage.</p>
  76
  77 <p><strong>NOTE</strong>: This is <em>not</em> the same as &quot;url&quot;.  If you put a &quot;url&quot; field,
  78 then the registry will think it&#39;s a redirection to your package that has
  79 been published somewhere else, and spit at you.</p>
  80
  81 <p>Literally.  Spit.  I&#39;m so not kidding.</p>
  82
  83 <h2 id="bugs">bugs</h2>
  84
  85 <p>The url to your project&#39;s issue tracker and / or the email address to which
  86 issues should be reported. These are helpful for people who encounter issues
  87 with your package.</p>
  88
  89 <p>It should look like this:</p>
  90
  91 <pre><code>{ &quot;url&quot; : &quot;http://github.com/owner/project/issues&quot;
  92 , &quot;email&quot; : &quot;project@hostname.com&quot;
  93 }</code></pre>
  94
  95 <p>You can specify either one or both values. If you want to provide only a url,
  96 you can specify the value for &quot;bugs&quot; as a simple string instead of an object.</p>
  97
  98 <p>If a url is provided, it will be used by the <code>npm bugs</code> command.</p>
  99
 100 <h2 id="license">license</h2>
 101
 102 <p>You should specify a license for your package so that people know how they are
 103 permitted to use it, and any restrictions you&#39;re placing on it.</p>
 104
 105 <p>The simplest way, assuming you&#39;re using a common license such as BSD-3-Clause
 106 or MIT, is to just specify the standard SPDX ID of the license you&#39;re using,
 107 like this:</p>
 108
 109 <pre><code>{ &quot;license&quot; : &quot;BSD-3-Clause&quot; }</code></pre>
 110
 111 <p>You can check <a href="https://spdx.org/licenses/">the full list of SPDX license IDs</a>.
 112 Ideally you should pick one that is
 113 <a href="http://opensource.org/licenses/alphabetical">OSI</a> approved.</p>
 114
 115 <p>If you have more complex licensing terms, or you want to provide more detail
 116 in your package.json file, you can use the more verbose plural form, like this:</p>
 117
 118 <pre><code>&quot;licenses&quot; : [
 119   { &quot;type&quot; : &quot;MyLicense&quot;
 120   , &quot;url&quot; : &quot;http://github.com/owner/project/path/to/license&quot;
 121   }
 122 ]</code></pre>
 123
 124 <p>It&#39;s also a good idea to include a license file at the top level in your package.</p>
 125
 126 <h2 id="people-fields-author-contributors">people fields: author, contributors</h2>
 127
 128 <p>The &quot;author&quot; is one person.  &quot;contributors&quot; is an array of people.  A &quot;person&quot;
 129 is an object with a &quot;name&quot; field and optionally &quot;url&quot; and &quot;email&quot;, like this:</p>
 130
 131 <pre><code>{ &quot;name&quot; : &quot;Barney Rubble&quot;
 132 , &quot;email&quot; : &quot;b@rubble.com&quot;
 133 , &quot;url&quot; : &quot;http://barnyrubble.tumblr.com/&quot;
 134 }</code></pre>
 135
 136 <p>Or you can shorten that all into a single string, and npm will parse it for you:</p>
 137
 138 <pre><code>&quot;Barney Rubble &lt;b@rubble.com&gt; (http://barnyrubble.tumblr.com/)</code></pre>
 139
 140 <p>Both email and url are optional either way.</p>
 141
 142 <p>npm also sets a top-level &quot;maintainers&quot; field with your npm user info.</p>
 143
 144 <h2 id="files">files</h2>
 145
 146 <p>The &quot;files&quot; field is an array of files to include in your project.  If
 147 you name a folder in the array, then it will also include the files
 148 inside that folder. (Unless they would be ignored by another rule.)</p>
 149
 150 <p>You can also provide a &quot;.npmignore&quot; file in the root of your package,
 151 which will keep files from being included, even if they would be picked
 152 up by the files array.  The &quot;.npmignore&quot; file works just like a
 153 &quot;.gitignore&quot;.</p>
 154
 155 <h2 id="main">main</h2>
 156
 157 <p>The main field is a module ID that is the primary entry point to your program.
 158 That is, if your package is named <code>foo</code>, and a user installs it, and then does
 159 <code>require(&quot;foo&quot;)</code>, then your main module&#39;s exports object will be returned.</p>
 160
 161 <p>This should be a module ID relative to the root of your package folder.</p>
 162
 163 <p>For most modules, it makes the most sense to have a main script and often not
 164 much else.</p>
 165
 166 <h2 id="bin">bin</h2>
 167
 168 <p>A lot of packages have one or more executable files that they&#39;d like to
 169 install into the PATH. npm makes this pretty easy (in fact, it uses this
 170 feature to install the &quot;npm&quot; executable.)</p>
 171
 172 <p>To use this, supply a <code>bin</code> field in your package.json which is a map of
 173 command name to local file name. On install, npm will symlink that file into
 174 <code>prefix/bin</code> for global installs, or <code>./node_modules/.bin/</code> for local
 175 installs.</p>
 176
 177 <p>For example, npm has this:</p>
 178
 179 <pre><code>{ &quot;bin&quot; : { &quot;npm&quot; : &quot;./cli.js&quot; } }</code></pre>
 180
 181 <p>So, when you install npm, it&#39;ll create a symlink from the <code>cli.js</code> script to
 182 <code>/usr/local/bin/npm</code>.</p>
 183
 184 <p>If you have a single executable, and its name should be the name
 185 of the package, then you can just supply it as a string.  For example:</p>
 186
 187 <pre><code>{ &quot;name&quot;: &quot;my-program&quot;
 188 , &quot;version&quot;: &quot;1.2.5&quot;
 189 , &quot;bin&quot;: &quot;./path/to/program&quot; }</code></pre>
 190
 191 <p>would be the same as this:</p>
 192
 193 <pre><code>{ &quot;name&quot;: &quot;my-program&quot;
 194 , &quot;version&quot;: &quot;1.2.5&quot;
 195 , &quot;bin&quot; : { &quot;my-program&quot; : &quot;./path/to/program&quot; } }</code></pre>
 196
 197 <h2 id="man">man</h2>
 198
 199 <p>Specify either a single file or an array of filenames to put in place for the
 200 <code>man</code> program to find.</p>
 201
 202 <p>If only a single file is provided, then it&#39;s installed such that it is the
 203 result from <code>man &lt;pkgname&gt;</code>, regardless of its actual filename.  For example:</p>
 204
 205 <pre><code>{ &quot;name&quot; : &quot;foo&quot;
 206 , &quot;version&quot; : &quot;1.2.3&quot;
 207 , &quot;description&quot; : &quot;A packaged foo fooer for fooing foos&quot;
 208 , &quot;main&quot; : &quot;foo.js&quot;
 209 , &quot;man&quot; : &quot;./man/doc.1&quot;
 210 }</code></pre>
 211
 212 <p>would link the <code>./man/doc.1</code> file in such that it is the target for <code>man foo</code></p>
 213
 214 <p>If the filename doesn&#39;t start with the package name, then it&#39;s prefixed.
 215 So, this:</p>
 216
 217 <pre><code>{ &quot;name&quot; : &quot;foo&quot;
 218 , &quot;version&quot; : &quot;1.2.3&quot;
 219 , &quot;description&quot; : &quot;A packaged foo fooer for fooing foos&quot;
 220 , &quot;main&quot; : &quot;foo.js&quot;
 221 , &quot;man&quot; : [ &quot;./man/foo.1&quot;, &quot;./man/bar.1&quot; ]
 222 }</code></pre>
 223
 224 <p>will create files to do <code>man foo</code> and <code>man foo-bar</code>.</p>
 225
 226 <p>Man files must end with a number, and optionally a <code>.gz</code> suffix if they are
 227 compressed.  The number dictates which man section the file is installed into.</p>
 228
 229 <pre><code>{ &quot;name&quot; : &quot;foo&quot;
 230 , &quot;version&quot; : &quot;1.2.3&quot;
 231 , &quot;description&quot; : &quot;A packaged foo fooer for fooing foos&quot;
 232 , &quot;main&quot; : &quot;foo.js&quot;
 233 , &quot;man&quot; : [ &quot;./man/foo.1&quot;, &quot;./man/foo.2&quot; ]
 234 }</code></pre>
 235
 236 <p>will create entries for <code>man foo</code> and <code>man 2 foo</code></p>
 237
 238 <h2 id="directories">directories</h2>
 239
 240 <p>The CommonJS <a href="http://wiki.commonjs.org/wiki/Packages/1.0">Packages</a> spec details a
 241 few ways that you can indicate the structure of your package using a <code>directories</code>
 242 hash. If you look at <a href="http://registry.npmjs.org/npm/latest">npm&#39;s package.json</a>,
 243 you&#39;ll see that it has directories for doc, lib, and man.</p>
 244
 245 <p>In the future, this information may be used in other creative ways.</p>
 246
 247 <h3 id="directories-lib">directories.lib</h3>
 248
 249 <p>Tell people where the bulk of your library is.  Nothing special is done
 250 with the lib folder in any way, but it&#39;s useful meta info.</p>
 251
 252 <h3 id="directories-bin">directories.bin</h3>
 253
 254 <p>If you specify a &quot;bin&quot; directory, then all the files in that folder will
 255 be used as the &quot;bin&quot; hash.</p>
 256
 257 <p>If you have a &quot;bin&quot; hash already, then this has no effect.</p>
 258
 259 <h3 id="directories-man">directories.man</h3>
 260
 261 <p>A folder that is full of man pages.  Sugar to generate a &quot;man&quot; array by
 262 walking the folder.</p>
 263
 264 <h3 id="directories-doc">directories.doc</h3>
 265
 266 <p>Put markdown files in here.  Eventually, these will be displayed nicely,
 267 maybe, someday.</p>
 268
 269 <h3 id="directories-example">directories.example</h3>
 270
 271 <p>Put example scripts in here.  Someday, it might be exposed in some clever way.</p>
 272
 273 <h2 id="repository">repository</h2>
 274
 275 <p>Specify the place where your code lives. This is helpful for people who
 276 want to contribute.  If the git repo is on github, then the <code>npm docs</code>
 277 command will be able to find you.</p>
 278
 279 <p>Do it like this:</p>
 280
 281 <pre><code>&quot;repository&quot; :
 282   { &quot;type&quot; : &quot;git&quot;
 283   , &quot;url&quot; : &quot;http://github.com/isaacs/npm.git&quot;
 284   }
 285
 286 &quot;repository&quot; :
 287   { &quot;type&quot; : &quot;svn&quot;
 288   , &quot;url&quot; : &quot;http://v8.googlecode.com/svn/trunk/&quot;
 289   }</code></pre>
 290
 291 <p>The URL should be a publicly available (perhaps read-only) url that can be handed
 292 directly to a VCS program without any modification.  It should not be a url to an
 293 html project page that you put in your browser.  It&#39;s for computers.</p>
 294
 295 <h2 id="scripts">scripts</h2>
 296
 297 <p>The &quot;scripts&quot; member is an object hash of script commands that are run
 298 at various times in the lifecycle of your package.  The key is the lifecycle
 299 event, and the value is the command to run at that point.</p>
 300
 301 <p>See <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code> to find out more about writing package scripts.</p>
 302
 303 <h2 id="config">config</h2>
 304
 305 <p>A &quot;config&quot; hash can be used to set configuration
 306 parameters used in package scripts that persist across upgrades.  For
 307 instance, if a package had the following:</p>
 308
 309 <pre><code>{ &quot;name&quot; : &quot;foo&quot;
 310 , &quot;config&quot; : { &quot;port&quot; : &quot;8080&quot; } }</code></pre>
 311
 312 <p>and then had a &quot;start&quot; command that then referenced the
 313 <code>npm_package_config_port</code> environment variable, then the user could
 314 override that by doing <code>npm config set foo:port 8001</code>.</p>
 315
 316 <p>See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> and <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code> for more on package
 317 configs.</p>
 318
 319 <h2 id="dependencies">dependencies</h2>
 320
 321 <p>Dependencies are specified with a simple hash of package name to
 322 version range. The version range is a string which has one or more
 323 space-separated descriptors.  Dependencies can also be identified with
 324 a tarball or git URL.</p>
 325
 326 <p><strong>Please do not put test harnesses or transpilers in your
 327 <code>dependencies</code> hash.</strong>  See <code>devDependencies</code>, below.</p>
 328
 329 <p>See <a href="../misc/semver.html">semver(7)</a> for more details about specifying version ranges.</p>
 330
 331 <ul><li><code>version</code> Must match <code>version</code> exactly</li><li><code>&gt;version</code> Must be greater than <code>version</code></li><li><code>&gt;=version</code> etc</li><li><code>&lt;version</code></li><li><code>&lt;=version</code></li><li><code>~version</code> &quot;Approximately equivalent to version&quot;  See <a href="../misc/semver.html">semver(7)</a></li><li><code>1.2.x</code> 1.2.0, 1.2.1, etc., but not 1.3.0</li><li><code>http://...</code> See &#39;URLs as Dependencies&#39; below</li><li><code>*</code> Matches any version</li><li><code>&quot;&quot;</code> (just an empty string) Same as <code>*</code></li><li><code>version1 - version2</code> Same as <code>&gt;=version1 &lt;=version2</code>.</li><li><code>range1 || range2</code> Passes if either range1 or range2 are satisfied.</li><li><code>git...</code> See &#39;Git URLs as Dependencies&#39; below</li><li><code>user/repo</code> See &#39;GitHub URLs&#39; below</li></ul>
 332
 333 <p>For example, these are all valid:</p>
 334
 335 <pre><code>{ &quot;dependencies&quot; :
 336   { &quot;foo&quot; : &quot;1.0.0 - 2.9999.9999&quot;
 337   , &quot;bar&quot; : &quot;&gt;=1.0.2 &lt;2.1.2&quot;
 338   , &quot;baz&quot; : &quot;&gt;1.0.2 &lt;=2.3.4&quot;
 339   , &quot;boo&quot; : &quot;2.0.1&quot;
 340   , &quot;qux&quot; : &quot;&lt;1.0.0 || &gt;=2.3.1 &lt;2.4.5 || &gt;=2.5.2 &lt;3.0.0&quot;
 341   , &quot;asd&quot; : &quot;http://asdf.com/asdf.tar.gz&quot;
 342   , &quot;til&quot; : &quot;~1.2&quot;
 343   , &quot;elf&quot; : &quot;~1.2.3&quot;
 344   , &quot;two&quot; : &quot;2.x&quot;
 345   , &quot;thr&quot; : &quot;3.3.x&quot;
 346   }
 347 }</code></pre>
 348
 349 <h3 id="URLs-as-Dependencies">URLs as Dependencies</h3>
 350
 351 <p>You may specify a tarball URL in place of a version range.</p>
 352
 353 <p>This tarball will be downloaded and installed locally to your package at
 354 install time.</p>
 355
 356 <h3 id="Git-URLs-as-Dependencies">Git URLs as Dependencies</h3>
 357
 358 <p>Git urls can be of the form:</p>
 359
 360 <pre><code>git://github.com/user/project.git#commit-ish
 361 git+ssh://user@hostname:project.git#commit-ish
 362 git+ssh://user@hostname/project.git#commit-ish
 363 git+http://user@hostname/project/blah.git#commit-ish
 364 git+https://user@hostname/project/blah.git#commit-ish</code></pre>
 365
 366 <p>The <code>commit-ish</code> can be any tag, sha, or branch which can be supplied as
 367 an argument to <code>git checkout</code>.  The default is <code>master</code>.</p>
 368
 369 <h2 id="GitHub-URLs">GitHub URLs</h2>
 370
 371 <p>As of version 1.1.65, you can refer to GitHub urls as just &quot;foo&quot;: &quot;user/foo-project&quot;. For example:</p>
 372
 373 <p><code>json
 374 {
 375   &quot;name&quot;: &quot;foo&quot;,
 376   &quot;version&quot;: &quot;0.0.0&quot;,
 377   &quot;dependencies&quot;: {
 378     &quot;express&quot;: &quot;visionmedia/express&quot;
 379   }
 380 }
 381 </code></p>
 382
 383 <h2 id="devDependencies">devDependencies</h2>
 384
 385 <p>If someone is planning on downloading and using your module in their
 386 program, then they probably don&#39;t want or need to download and build
 387 the external test or documentation framework that you use.</p>
 388
 389 <p>In this case, it&#39;s best to list these additional items in a
 390 <code>devDependencies</code> hash.</p>
 391
 392 <p>These things will be installed when doing <code>npm link</code> or <code>npm install</code>
 393 from the root of a package, and can be managed like any other npm
 394 configuration param.  See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> for more on the topic.</p>
 395
 396 <p>For build steps that are not platform-specific, such as compiling
 397 CoffeeScript or other languages to JavaScript, use the <code>prepublish</code>
 398 script to do this, and make the required package a devDependency.</p>
 399
 400 <p>For example:</p>
 401
 402 <p><code>json
 403 { &quot;name&quot;: &quot;ethopia-waza&quot;,
 404   &quot;description&quot;: &quot;a delightfully fruity coffee varietal&quot;,
 405   &quot;version&quot;: &quot;1.2.3&quot;,
 406   &quot;devDependencies&quot;: {
 407     &quot;coffee-script&quot;: &quot;~1.6.3&quot;
 408   },
 409   &quot;scripts&quot;: {
 410     &quot;prepublish&quot;: &quot;coffee -o lib/ -c src/waza.coffee&quot;
 411   },
 412   &quot;main&quot;: &quot;lib/waza.js&quot;
 413 }
 414 </code></p>
 415
 416 <p>The <code>prepublish</code> script will be run before publishing, so that users
 417 can consume the functionality without requiring them to compile it
 418 themselves.  In dev mode (ie, locally running <code>npm install</code>), it&#39;ll
 419 run this script as well, so that you can test it easily.</p>
 420
 421 <h2 id="bundledDependencies">bundledDependencies</h2>
 422
 423 <p>Array of package names that will be bundled when publishing the package.</p>
 424
 425 <p>If this is spelled <code>&quot;bundleDependencies&quot;</code>, then that is also honorable.</p>
 426
 427 <h2 id="optionalDependencies">optionalDependencies</h2>
 428
 429 <p>If a dependency can be used, but you would like npm to proceed if it
 430 cannot be found or fails to install, then you may put it in the
 431 <code>optionalDependencies</code> hash.  This is a map of package name to version
 432 or url, just like the <code>dependencies</code> hash.  The difference is that
 433 failure is tolerated.</p>
 434
 435 <p>It is still your program&#39;s responsibility to handle the lack of the
 436 dependency.  For example, something like this:</p>
 437
 438 <pre><code>try {
 439   var foo = require(&#39;foo&#39;)
 440   var fooVersion = require(&#39;foo/package.json&#39;).version
 441 } catch (er) {
 442   foo = null
 443 }
 444 if ( notGoodFooVersion(fooVersion) ) {
 445   foo = null
 446 }
 447
 448 // .. then later in your program ..
 449
 450 if (foo) {
 451   foo.doFooThings()
 452 }</code></pre>
 453
 454 <p>Entries in <code>optionalDependencies</code> will override entries of the same name in
 455 <code>dependencies</code>, so it&#39;s usually best to only put in one place.</p>
 456
 457 <h2 id="engines">engines</h2>
 458
 459 <p>You can specify the version of node that your stuff works on:</p>
 460
 461 <pre><code>{ &quot;engines&quot; : { &quot;node&quot; : &quot;&gt;=0.10.3 &lt;0.12&quot; } }</code></pre>
 462
 463 <p>And, like with dependencies, if you don&#39;t specify the version (or if you
 464 specify &quot;*&quot; as the version), then any version of node will do.</p>
 465
 466 <p>If you specify an &quot;engines&quot; field, then npm will require that &quot;node&quot; be
 467 somewhere on that list. If &quot;engines&quot; is omitted, then npm will just assume
 468 that it works on node.</p>
 469
 470 <p>You can also use the &quot;engines&quot; field to specify which versions of npm
 471 are capable of properly installing your program.  For example:</p>
 472
 473 <pre><code>{ &quot;engines&quot; : { &quot;npm&quot; : &quot;~1.0.20&quot; } }</code></pre>
 474
 475 <p>Note that, unless the user has set the <code>engine-strict</code> config flag, this
 476 field is advisory only.</p>
 477
 478 <h2 id="engineStrict">engineStrict</h2>
 479
 480 <p>If you are sure that your module will <em>definitely not</em> run properly on
 481 versions of Node/npm other than those specified in the <code>engines</code> hash,
 482 then you can set <code>&quot;engineStrict&quot;: true</code> in your package.json file.
 483 This will override the user&#39;s <code>engine-strict</code> config setting.</p>
 484
 485 <p>Please do not do this unless you are really very very sure.  If your
 486 engines hash is something overly restrictive, you can quite easily and
 487 inadvertently lock yourself into obscurity and prevent your users from
 488 updating to new versions of Node.  Consider this choice carefully.  If
 489 people abuse it, it will be removed in a future version of npm.</p>
 490
 491 <h2 id="os">os</h2>
 492
 493 <p>You can specify which operating systems your
 494 module will run on:</p>
 495
 496 <pre><code>&quot;os&quot; : [ &quot;darwin&quot;, &quot;linux&quot; ]</code></pre>
 497
 498 <p>You can also blacklist instead of whitelist operating systems,
 499 just prepend the blacklisted os with a &#39;!&#39;:</p>
 500
 501 <pre><code>&quot;os&quot; : [ &quot;!win32&quot; ]</code></pre>
 502
 503 <p>The host operating system is determined by <code>process.platform</code></p>
 504
 505 <p>It is allowed to both blacklist, and whitelist, although there isn&#39;t any
 506 good reason to do this.</p>
 507
 508 <h2 id="cpu">cpu</h2>
 509
 510 <p>If your code only runs on certain cpu architectures,
 511 you can specify which ones.</p>
 512
 513 <pre><code>&quot;cpu&quot; : [ &quot;x64&quot;, &quot;ia32&quot; ]</code></pre>
 514
 515 <p>Like the <code>os</code> option, you can also blacklist architectures:</p>
 516
 517 <pre><code>&quot;cpu&quot; : [ &quot;!arm&quot;, &quot;!mips&quot; ]</code></pre>
 518
 519 <p>The host architecture is determined by <code>process.arch</code></p>
 520
 521 <h2 id="preferGlobal">preferGlobal</h2>
 522
 523 <p>If your package is primarily a command-line application that should be
 524 installed globally, then set this value to <code>true</code> to provide a warning
 525 if it is installed locally.</p>
 526
 527 <p>It doesn&#39;t actually prevent users from installing it locally, but it
 528 does help prevent some confusion if it doesn&#39;t work as expected.</p>
 529
 530 <h2 id="private">private</h2>
 531
 532 <p>If you set <code>&quot;private&quot;: true</code> in your package.json, then npm will refuse
 533 to publish it.</p>
 534
 535 <p>This is a way to prevent accidental publication of private repositories.
 536 If you would like to ensure that a given package is only ever published
 537 to a specific registry (for example, an internal registry),
 538 then use the <code>publishConfig</code> hash described below
 539 to override the <code>registry</code> config param at publish-time.</p>
 540
 541 <h2 id="publishConfig">publishConfig</h2>
 542
 543 <p>This is a set of config values that will be used at publish-time.  It&#39;s
 544 especially handy if you want to set the tag or registry, so that you can
 545 ensure that a given package is not tagged with &quot;latest&quot; or published to
 546 the global public registry by default.</p>
 547
 548 <p>Any config values can be overridden, but of course only &quot;tag&quot; and
 549 &quot;registry&quot; probably matter for the purposes of publishing.</p>
 550
 551 <p>See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> to see the list of config options that can be
 552 overridden.</p>
 553
 554 <h2 id="SEE-ALSO">SEE ALSO</h2>
 555
 556 <ul><li><a href="../misc/semver.html">semver(7)</a></li><li><a href="../cli/npm-init.html">npm-init(1)</a></li><li><a href="../cli/npm-version.html">npm-version(1)</a></li><li><a href="../cli/npm-config.html">npm-config(1)</a></li><li><a href="../misc/npm-config.html">npm-config(7)</a></li><li><a href="../cli/npm-help.html">npm-help(1)</a></li><li><a href="../misc/npm-faq.html">npm-faq(7)</a></li><li><a href="../cli/npm-install.html">npm-install(1)</a></li><li><a href="../cli/npm-publish.html">npm-publish(1)</a></li><li><a href="../cli/npm-rm.html">npm-rm(1)</a></li></ul>
 557 </div>
 558 <p id="footer">package.json &mdash; npm@1.3.19</p>
 559 <script>
 560 ;(function () {
 561 var wrapper = document.getElementById("wrapper")
 562 var els = Array.prototype.slice.call(wrapper.getElementsByTagName("*"), 0)
 563   .filter(function (el) {
 564     return el.parentNode === wrapper
 565         && el.tagName.match(/H[1-6]/)
 566         && el.id
 567   })
 568 var l = 2
 569   , toc = document.createElement("ul")
 570 toc.innerHTML = els.map(function (el) {
 571   var i = el.tagName.charAt(1)
 572     , out = ""
 573   while (i > l) {
 574     out += "<ul>"
 575     l ++
 576   }
 577   while (i < l) {
 578     out += "</ul>"
 579     l --
 580   }
 581   out += "<li><a href='#" + el.id + "'>" +
 582     ( el.innerText || el.text || el.innerHTML)
 583     + "</a>"
 584   return out
 585 }).join("\n")
 586 toc.id = "toc"
 587 document.body.appendChild(toc)
 588 })()
 589 </script>