1--- 2section: configuring-npm 3title: package.json 4description: Specifics of npm's package.json handling 5--- 6 7# package.json(5) 8 9## Specifics of npm's package.json handling 10 11### Description 12 13This document is all you need to know about what's required in your package.json 14file. It must be actual JSON, not just a JavaScript object literal. 15 16A lot of the behavior described in this document is affected by the config 17settings described in [`config`](/using-npm/config). 18 19### name 20 21If you plan to publish your package, the *most* important things in your 22package.json are the name and version fields as they will be required. The name 23and version together form an identifier that is assumed to be completely unique. 24Changes to the package should come along with changes to the version. If you don't 25plan to publish your package, the name and version fields are optional. 26 27The name is what your thing is called. 28 29Some rules: 30 31* The name must be less than or equal to 214 characters. This includes the scope for 32 scoped packages. 33* The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope. 34* New packages must not have uppercase letters in the name. 35* The name ends up being part of a URL, an argument on the command line, and a 36 folder name. Therefore, the name can't contain any non-URL-safe characters. 37 38Some tips: 39 40* Don't use the same name as a core Node module. 41* Don't put "js" or "node" in the name. It's assumed that it's js, since you're 42 writing a package.json file, and you can specify the engine using the "engines" 43 field. (See below.) 44* The name will probably be passed as an argument to require(), so it should 45 be something short, but also reasonably descriptive. 46* You may want to check the npm registry to see if there's something by that name 47 already, before you get too attached to it. <https://www.npmjs.com/> 48 49A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See 50[`scope`](/using-npm/scope) for more detail. 51 52### version 53 54If you plan to publish your package, the *most* important things in your 55package.json are the name and version fields as they will be required. The name 56and version together form an identifier that is assumed to be completely unique. 57Changes to the package should come along with changes to the version. If you don't 58plan to publish your package, the name and version fields are optional. 59 60Version must be parseable by 61[node-semver](https://github.com/isaacs/node-semver), which is bundled 62with npm as a dependency. (`npm install semver` to use it yourself.) 63 64More on version numbers and ranges at [semver](/using-npm/semver). 65 66### description 67 68Put a description in it. It's a string. This helps people discover your 69package, as it's listed in `npm search`. 70 71### keywords 72 73Put keywords in it. It's an array of strings. This helps people 74discover your package as it's listed in `npm search`. 75 76### homepage 77 78The url to the project homepage. 79 80Example: 81 82```json 83"homepage": "https://github.com/owner/project#readme" 84``` 85 86### bugs 87 88The url to your project's issue tracker and / or the email address to which 89issues should be reported. These are helpful for people who encounter issues 90with your package. 91 92It should look like this: 93 94```json 95{ "url" : "https://github.com/owner/project/issues" 96, "email" : "project@hostname.com" 97} 98``` 99 100You can specify either one or both values. If you want to provide only a url, 101you can specify the value for "bugs" as a simple string instead of an object. 102 103If a url is provided, it will be used by the `npm bugs` command. 104 105### license 106 107You should specify a license for your package so that people know how they are 108permitted to use it, and any restrictions you're placing on it. 109 110If you're using a common license such as BSD-2-Clause or MIT, add a 111current SPDX license identifier for the license you're using, like this: 112 113```json 114{ "license" : "BSD-3-Clause" } 115``` 116 117You can check [the full list of SPDX license IDs](https://spdx.org/licenses/). 118Ideally you should pick one that is 119[OSI](https://opensource.org/licenses/alphabetical) approved. 120 121If your package is licensed under multiple common licenses, use an [SPDX license 122expression syntax version 2.0 string](https://www.npmjs.com/package/spdx), like this: 123 124```json 125{ "license" : "(ISC OR GPL-3.0)" } 126``` 127If you are using a license that hasn't been assigned an SPDX identifier, or if 128you are using a custom license, use a string value like this one: 129 130```json 131{ "license" : "SEE LICENSE IN <filename>" } 132``` 133Then include a file named `<filename>` at the top level of the package. 134 135Some old packages used license objects or a "licenses" property containing an 136array of license objects: 137 138```json 139// Not valid metadata 140{ "license" : 141 { "type" : "ISC" 142 , "url" : "https://opensource.org/licenses/ISC" 143 } 144} 145 146// Not valid metadata 147{ "licenses" : 148 [ 149 { "type": "MIT" 150 , "url": "https://www.opensource.org/licenses/mit-license.php" 151 } 152 , { "type": "Apache-2.0" 153 , "url": "https://opensource.org/licenses/apache2.0.php" 154 } 155 ] 156} 157``` 158 159Those styles are now deprecated. Instead, use SPDX expressions, like this: 160 161```json 162{ "license": "ISC" } 163 164{ "license": "(MIT OR Apache-2.0)" } 165``` 166 167Finally, if you do not wish to grant others the right to use a private or 168unpublished package under any terms: 169 170```json 171{ "license": "UNLICENSED" } 172``` 173Consider also setting `"private": true` to prevent accidental publication. 174 175### people fields: author, contributors 176 177The "author" is one person. "contributors" is an array of people. A "person" 178is an object with a "name" field and optionally "url" and "email", like this: 179 180```json 181{ "name" : "Barney Rubble" 182, "email" : "b@rubble.com" 183, "url" : "http://barnyrubble.tumblr.com/" 184} 185``` 186 187Or you can shorten that all into a single string, and npm will parse it for you: 188 189```json 190"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)" 191``` 192 193Both email and url are optional either way. 194 195npm also sets a top-level "maintainers" field with your npm user info. 196 197### funding 198 199You can specify an object containing an URL that provides up-to-date 200information about ways to help fund development of your package, or 201a string URL, or an array of these: 202 203 "funding": { 204 "type" : "individual", 205 "url" : "http://example.com/donate" 206 } 207 208 "funding": { 209 "type" : "patreon", 210 "url" : "https://www.patreon.com/my-account" 211 } 212 213 "funding": "http://example.com/donate" 214 215 "funding": [ 216 { 217 "type" : "individual", 218 "url" : "http://example.com/donate" 219 }, 220 "http://example.com/donateAlso", 221 { 222 "type" : "patreon", 223 "url" : "https://www.patreon.com/my-account" 224 } 225 ] 226 227 228Users can use the `npm fund` subcommand to list the `funding` URLs of all 229dependencies of their project, direct and indirect. A shortcut to visit each 230funding url is also available when providing the project name such as: 231`npm fund <projectname>` (when there are multiple URLs, the first one will be 232visited) 233 234### files 235 236The optional `files` field is an array of file patterns that describes 237the entries to be included when your package is installed as a 238dependency. File patterns follow a similar syntax to `.gitignore`, but 239reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such) 240will make it so that file is included in the tarball when it's packed. Omitting 241the field will make it default to `["*"]`, which means it will include all files. 242 243Some special files and directories are also included or excluded regardless of 244whether they exist in the `files` array (see below). 245 246You can also provide a `.npmignore` file in the root of your package or 247in subdirectories, which will keep files from being included. At the 248root of your package it will not override the "files" field, but in 249subdirectories it will. The `.npmignore` file works just like a 250`.gitignore`. If there is a `.gitignore` file, and `.npmignore` is 251missing, `.gitignore`'s contents will be used instead. 252 253Files included with the "package.json#files" field _cannot_ be excluded 254through `.npmignore` or `.gitignore`. 255 256Certain files are always included, regardless of settings: 257 258* `package.json` 259* `README` 260* `CHANGES` / `CHANGELOG` / `HISTORY` 261* `LICENSE` / `LICENCE` 262* `NOTICE` 263* The file in the "main" field 264 265`README`, `CHANGES`, `LICENSE` & `NOTICE` can have any case and extension. 266 267Conversely, some files are always ignored: 268 269* `.git` 270* `CVS` 271* `.svn` 272* `.hg` 273* `.lock-wscript` 274* `.wafpickle-N` 275* `.DS_Store` 276* `npm-debug.log` 277* `.npmrc` 278* `node_modules` 279* `config.gypi` 280* `package-lock.json` (use shrinkwrap instead) 281* All files containing a `*` character (incompatible with Windows) 282 283### main 284 285The main field is a module ID that is the primary entry point to your program. 286That is, if your package is named `foo`, and a user installs it, and then does 287`require("foo")`, then your main module's exports object will be returned. 288 289This should be a module ID relative to the root of your package folder. 290 291For most modules, it makes the most sense to have a main script and often not 292much else. 293 294### browser 295 296If your module is meant to be used client-side the browser field should be 297used instead of the main field. This is helpful to hint users that it might 298rely on primitives that aren't available in Node.js modules. (e.g. `window`) 299 300### bin 301 302A lot of packages have one or more executable files that they'd like to 303install into the PATH. npm makes this pretty easy (in fact, it uses this 304feature to install the "npm" executable.) 305 306To use this, supply a `bin` field in your package.json which is a map of 307command name to local file name. On install, npm will symlink that file into 308`prefix/bin` for global installs, or `./node_modules/.bin/` for local 309installs. 310 311 312For example, myapp could have this: 313 314```json 315{ "bin" : { "myapp" : "./cli.js" } } 316``` 317 318So, when you install myapp, it'll create a symlink from the `cli.js` script to 319`/usr/local/bin/myapp`. 320 321If you have a single executable, and its name should be the name 322of the package, then you can just supply it as a string. For example: 323 324```json 325{ "name": "my-program" 326, "version": "1.2.5" 327, "bin": "./path/to/program" } 328``` 329 330would be the same as this: 331 332```json 333{ "name": "my-program" 334, "version": "1.2.5" 335, "bin" : { "my-program" : "./path/to/program" } } 336``` 337 338Please make sure that your file(s) referenced in `bin` starts with 339`#!/usr/bin/env node`, otherwise the scripts are started without the node 340executable! 341 342### man 343 344Specify either a single file or an array of filenames to put in place for the 345`man` program to find. 346 347If only a single file is provided, then it's installed such that it is the 348result from `man <pkgname>`, regardless of its actual filename. For example: 349 350```json 351{ "name" : "foo" 352, "version" : "1.2.3" 353, "description" : "A packaged foo fooer for fooing foos" 354, "main" : "foo.js" 355, "man" : "./man/doc.1" 356} 357``` 358 359would link the `./man/doc.1` file in such that it is the target for `man foo` 360 361If the filename doesn't start with the package name, then it's prefixed. 362So, this: 363 364```json 365{ "name" : "foo" 366, "version" : "1.2.3" 367, "description" : "A packaged foo fooer for fooing foos" 368, "main" : "foo.js" 369, "man" : [ "./man/foo.1", "./man/bar.1" ] 370} 371``` 372 373will create files to do `man foo` and `man foo-bar`. 374 375Man files must end with a number, and optionally a `.gz` suffix if they are 376compressed. The number dictates which man section the file is installed into. 377 378```json 379{ "name" : "foo" 380, "version" : "1.2.3" 381, "description" : "A packaged foo fooer for fooing foos" 382, "main" : "foo.js" 383, "man" : [ "./man/foo.1", "./man/foo.2" ] 384} 385``` 386will create entries for `man foo` and `man 2 foo` 387 388### directories 389 390The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a 391few ways that you can indicate the structure of your package using a `directories` 392object. If you look at [npm's package.json](https://registry.npmjs.org/npm/latest), 393you'll see that it has directories for doc, lib, and man. 394 395In the future, this information may be used in other creative ways. 396 397#### directories.lib 398 399Tell people where the bulk of your library is. Nothing special is done 400with the lib folder in any way, but it's useful meta info. 401 402#### directories.bin 403 404If you specify a `bin` directory in `directories.bin`, all the files in 405that folder will be added. 406 407Because of the way the `bin` directive works, specifying both a 408`bin` path and setting `directories.bin` is an error. If you want to 409specify individual files, use `bin`, and for all the files in an 410existing `bin` directory, use `directories.bin`. 411 412#### directories.man 413 414A folder that is full of man pages. Sugar to generate a "man" array by 415walking the folder. 416 417#### directories.doc 418 419Put markdown files in here. Eventually, these will be displayed nicely, 420maybe, someday. 421 422#### directories.example 423 424Put example scripts in here. Someday, it might be exposed in some clever way. 425 426#### directories.test 427 428Put your tests in here. It is currently not exposed, but it might be in the 429future. 430 431### repository 432 433Specify the place where your code lives. This is helpful for people who 434want to contribute. If the git repo is on GitHub, then the `npm docs` 435command will be able to find you. 436 437Do it like this: 438 439```json 440"repository": { 441 "type" : "git", 442 "url" : "https://github.com/npm/cli.git" 443} 444 445"repository": { 446 "type" : "svn", 447 "url" : "https://v8.googlecode.com/svn/trunk/" 448} 449``` 450 451The URL should be a publicly available (perhaps read-only) url that can be handed 452directly to a VCS program without any modification. It should not be a url to an 453html project page that you put in your browser. It's for computers. 454 455For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same 456shortcut syntax you use for `npm install`: 457 458```json 459"repository": "npm/npm" 460 461"repository": "github:user/repo" 462 463"repository": "gist:11081aaa281" 464 465"repository": "bitbucket:user/repo" 466 467"repository": "gitlab:user/repo" 468``` 469 470If the `package.json` for your package is not in the root directory (for example 471if it is part of a monorepo), you can specify the directory in which it lives: 472 473```json 474"repository": { 475 "type" : "git", 476 "url" : "https://github.com/facebook/react.git", 477 "directory": "packages/react-dom" 478} 479``` 480 481### scripts 482 483The "scripts" property is a dictionary containing script commands that are run 484at various times in the lifecycle of your package. The key is the lifecycle 485event, and the value is the command to run at that point. 486 487See [`scripts`](/using-npm/scripts) to find out more about writing package scripts. 488 489### config 490 491A "config" object can be used to set configuration parameters used in package 492scripts that persist across upgrades. For instance, if a package had the 493following: 494 495```json 496{ "name" : "foo" 497, "config" : { "port" : "8080" } } 498``` 499 500and then had a "start" command that then referenced the 501`npm_package_config_port` environment variable, then the user could 502override that by doing `npm config set foo:port 8001`. 503 504See [`config`](/using-npm/config) and [`scripts`](/using-npm/scripts) for more on package 505configs. 506 507### dependencies 508 509Dependencies are specified in a simple object that maps a package name to a 510version range. The version range is a string which has one or more 511space-separated descriptors. Dependencies can also be identified with a 512tarball or git URL. 513 514**Please do not put test harnesses or transpilers in your 515`dependencies` object.** See `devDependencies`, below. 516 517See [semver](/using-npm/semver) for more details about specifying version ranges. 518 519* `version` Must match `version` exactly 520* `>version` Must be greater than `version` 521* `>=version` etc 522* `<version` 523* `<=version` 524* `~version` "Approximately equivalent to version" See [semver](/using-npm/semver) 525* `^version` "Compatible with version" See [semver](/using-npm/semver) 526* `1.2.x` 1.2.0, 1.2.1, etc., but not 1.3.0 527* `http://...` See 'URLs as Dependencies' below 528* `*` Matches any version 529* `""` (just an empty string) Same as `*` 530* `version1 - version2` Same as `>=version1 <=version2`. 531* `range1 || range2` Passes if either range1 or range2 are satisfied. 532* `git...` See 'Git URLs as Dependencies' below 533* `user/repo` See 'GitHub URLs' below 534* `tag` A specific version tagged and published as `tag` See [`npm dist-tag`](/cli-commands/npm-dist-tag) 535* `path/path/path` See [Local Paths](#local-paths) below 536 537For example, these are all valid: 538 539```json 540{ "dependencies" : 541 { "foo" : "1.0.0 - 2.9999.9999" 542 , "bar" : ">=1.0.2 <2.1.2" 543 , "baz" : ">1.0.2 <=2.3.4" 544 , "boo" : "2.0.1" 545 , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" 546 , "asd" : "http://asdf.com/asdf.tar.gz" 547 , "til" : "~1.2" 548 , "elf" : "~1.2.3" 549 , "two" : "2.x" 550 , "thr" : "3.3.x" 551 , "lat" : "latest" 552 , "dyl" : "file:../dyl" 553 } 554} 555``` 556 557#### URLs as Dependencies 558 559You may specify a tarball URL in place of a version range. 560 561This tarball will be downloaded and installed locally to your package at 562install time. 563 564#### Git URLs as Dependencies 565 566Git urls are of the form: 567 568```bash 569<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>] 570``` 571 572`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or 573`git+file`. 574 575If `#<commit-ish>` is provided, it will be used to clone exactly that 576commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can 577be any valid semver range or exact version, and npm will look for any tags 578or refs matching that range in the remote repository, much as it would for a 579registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is 580specified, then `master` is used. 581 582Examples: 583 584```bash 585git+ssh://git@github.com:npm/cli.git#v1.0.27 586git+ssh://git@github.com:npm/cli#semver:^5.0 587git+https://isaacs@github.com/npm/cli.git 588git://github.com/npm/cli.git#v1.0.27 589``` 590 591#### GitHub URLs 592 593As of version 1.1.65, you can refer to GitHub urls as just "foo": 594"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be 595included. For example: 596 597```json 598{ 599 "name": "foo", 600 "version": "0.0.0", 601 "dependencies": { 602 "express": "expressjs/express", 603 "mocha": "mochajs/mocha#4727d357ea", 604 "module": "user/repo#feature\/branch" 605 } 606} 607``` 608 609#### Local Paths 610 611As of version 2.0.0 you can provide a path to a local directory that contains a 612package. Local paths can be saved using `npm install -S` or 613`npm install --save`, using any of these forms: 614 615```bash 616../foo/bar 617~/foo/bar 618./foo/bar 619/foo/bar 620``` 621 622in which case they will be normalized to a relative path and added to your 623`package.json`. For example: 624 625```json 626{ 627 "name": "baz", 628 "dependencies": { 629 "bar": "file:../foo/bar" 630 } 631} 632``` 633 634This feature is helpful for local offline development and creating 635tests that require npm installing where you don't want to hit an 636external server, but should not be used when publishing packages 637to the public registry. 638 639### devDependencies 640 641If someone is planning on downloading and using your module in their 642program, then they probably don't want or need to download and build 643the external test or documentation framework that you use. 644 645In this case, it's best to map these additional items in a `devDependencies` 646object. 647 648These things will be installed when doing `npm link` or `npm install` 649from the root of a package, and can be managed like any other npm 650configuration param. See [`config`](/using-npm/config) for more on the topic. 651 652For build steps that are not platform-specific, such as compiling 653CoffeeScript or other languages to JavaScript, use the `prepare` 654script to do this, and make the required package a devDependency. 655 656For example: 657 658```json 659{ "name": "ethopia-waza", 660 "description": "a delightfully fruity coffee varietal", 661 "version": "1.2.3", 662 "devDependencies": { 663 "coffee-script": "~1.6.3" 664 }, 665 "scripts": { 666 "prepare": "coffee -o lib/ -c src/waza.coffee" 667 }, 668 "main": "lib/waza.js" 669} 670``` 671 672The `prepare` script will be run before publishing, so that users 673can consume the functionality without requiring them to compile it 674themselves. In dev mode (ie, locally running `npm install`), it'll 675run this script as well, so that you can test it easily. 676 677### peerDependencies 678 679In some cases, you want to express the compatibility of your package with a 680host tool or library, while not necessarily doing a `require` of this host. 681This is usually referred to as a *plugin*. Notably, your module may be exposing 682a specific interface, expected and specified by the host documentation. 683 684For example: 685 686```json 687{ 688 "name": "tea-latte", 689 "version": "1.3.5", 690 "peerDependencies": { 691 "tea": "2.x" 692 } 693} 694``` 695 696This ensures your package `tea-latte` can be installed *along* with the second 697major version of the host package `tea` only. `npm install tea-latte` could 698possibly yield the following dependency graph: 699 700```bash 701├── tea-latte@1.3.5 702└── tea@2.2.0 703``` 704 705**NOTE: npm versions 1 and 2 will automatically install `peerDependencies` if 706they are not explicitly depended upon higher in the dependency tree. In the 707next major version of npm (npm@3), this will no longer be the case. You will 708receive a warning that the peerDependency is not installed instead.** The 709behavior in npms 1 & 2 was frequently confusing and could easily put you into 710dependency hell, a situation that npm is designed to avoid as much as possible. 711 712Trying to install another plugin with a conflicting requirement will cause an 713error. For this reason, make sure your plugin requirement is as broad as 714possible, and not to lock it down to specific patch versions. 715 716Assuming the host complies with [semver](https://semver.org/), only changes in 717the host package's major version will break your plugin. Thus, if you've worked 718with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express 719this. If you depend on features introduced in 1.5.2, use `">= 1.5.2 < 2"`. 720 721### bundledDependencies 722 723This defines an array of package names that will be bundled when publishing 724the package. 725 726In cases where you need to preserve npm packages locally or have them 727available through a single file download, you can bundle the packages in a 728tarball file by specifying the package names in the `bundledDependencies` 729array and executing `npm pack`. 730 731For example: 732 733If we define a package.json like this: 734 735```json 736{ 737 "name": "awesome-web-framework", 738 "version": "1.0.0", 739 "bundledDependencies": [ 740 "renderized", "super-streams" 741 ] 742} 743``` 744we can obtain `awesome-web-framework-1.0.0.tgz` file by running `npm pack`. 745This file contains the dependencies `renderized` and `super-streams` which 746can be installed in a new project by executing `npm install 747awesome-web-framework-1.0.0.tgz`. Note that the package names do not include 748any versions, as that information is specified in `dependencies`. 749 750If this is spelled `"bundleDependencies"`, then that is also honored. 751 752### optionalDependencies 753 754If a dependency can be used, but you would like npm to proceed if it cannot be 755found or fails to install, then you may put it in the `optionalDependencies` 756object. This is a map of package name to version or url, just like the 757`dependencies` object. The difference is that build failures do not cause 758installation to fail. Running `npm install --no-optional` will prevent these 759dependencies from being installed. 760 761It is still your program's responsibility to handle the lack of the 762dependency. For example, something like this: 763 764```js 765try { 766 var foo = require('foo') 767 var fooVersion = require('foo/package.json').version 768} catch (er) { 769 foo = null 770} 771if ( notGoodFooVersion(fooVersion) ) { 772 foo = null 773} 774 775// .. then later in your program .. 776 777if (foo) { 778 foo.doFooThings() 779} 780``` 781 782Entries in `optionalDependencies` will override entries of the same name in 783`dependencies`, so it's usually best to only put in one place. 784 785### engines 786 787You can specify the version of node that your stuff works on: 788 789```json 790{ "engines" : { "node" : ">=0.10.3 <0.12" } } 791``` 792 793And, like with dependencies, if you don't specify the version (or if you 794specify "\*" as the version), then any version of node will do. 795 796If you specify an "engines" field, then npm will require that "node" be 797somewhere on that list. If "engines" is omitted, then npm will just assume 798that it works on node. 799 800You can also use the "engines" field to specify which versions of npm 801are capable of properly installing your program. For example: 802 803```json 804{ "engines" : { "npm" : "~1.0.20" } } 805``` 806 807Unless the user has set the `engine-strict` config flag, this 808field is advisory only and will only produce warnings when your package is installed as a dependency. 809 810### engineStrict 811 812**This feature was removed in npm 3.0.0** 813 814Prior to npm 3.0.0, this feature was used to treat this package as if the 815user had set `engine-strict`. It is no longer used. 816 817### os 818 819You can specify which operating systems your 820module will run on: 821 822```json 823"os" : [ "darwin", "linux" ] 824``` 825 826You can also blacklist instead of whitelist operating systems, 827just prepend the blacklisted os with a '!': 828 829```json 830"os" : [ "!win32" ] 831``` 832 833The host operating system is determined by `process.platform` 834 835It is allowed to both blacklist, and whitelist, although there isn't any 836good reason to do this. 837 838### cpu 839 840If your code only runs on certain cpu architectures, 841you can specify which ones. 842 843```json 844"cpu" : [ "x64", "ia32" ] 845``` 846 847Like the `os` option, you can also blacklist architectures: 848 849```json 850"cpu" : [ "!arm", "!mips" ] 851``` 852 853The host architecture is determined by `process.arch` 854 855### preferGlobal 856 857**DEPRECATED** 858 859This option used to trigger an npm warning, but it will no longer warn. It is 860purely there for informational purposes. It is now recommended that you install 861any binaries as local devDependencies wherever possible. 862 863### private 864 865If you set `"private": true` in your package.json, then npm will refuse 866to publish it. 867 868This is a way to prevent accidental publication of private repositories. If 869you would like to ensure that a given package is only ever published to a 870specific registry (for example, an internal registry), then use the 871`publishConfig` dictionary described below to override the `registry` config 872param at publish-time. 873 874### publishConfig 875 876This is a set of config values that will be used at publish-time. It's 877especially handy if you want to set the tag, registry or access, so that 878you can ensure that a given package is not tagged with "latest", published 879to the global public registry or that a scoped module is private by default. 880 881Any config values can be overridden, but only "tag", "registry" and "access" 882probably matter for the purposes of publishing. 883 884See [`config`](/using-npm/config) to see the list of config options that can be 885overridden. 886 887### DEFAULT VALUES 888 889npm will default some values based on package contents. 890 891* `"scripts": {"start": "node server.js"}` 892 893 If there is a `server.js` file in the root of your package, then npm 894 will default the `start` command to `node server.js`. 895 896* `"scripts":{"install": "node-gyp rebuild"}` 897 898 If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will 899 default the `install` command to compile using node-gyp. 900 901* `"contributors": [...]` 902 903 If there is an `AUTHORS` file in the root of your package, npm will 904 treat each line as a `Name <email> (url)` format, where email and url 905 are optional. Lines which start with a `#` or are blank, will be 906 ignored. 907 908### SEE ALSO 909 910* [semver](/using-npm/semver) 911* [npm init](/cli-commands/npm-init) 912* [npm version](/cli-commands/npm-version) 913* [npm config](/cli-commands/npm-config) 914* [npm help](/cli-commands/npm-help) 915* [npm install](/cli-commands/npm-install) 916* [npm publish](/cli-commands/npm-publish) 917* [npm uninstall](/cli-commands/npm-uninstall) 918