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