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 · .*.swp
280 · .DS_Store
282 · ._*
284 · npm-debug.log
286 · .npmrc
288 · node_modules
290 · config.gypi
292 · *.orig
294 · package-lock.json (use shrinkwrap instead)
296 main
299 The main field is a module ID that is the primary entry point to your
300 program. That is, if your package is named foo, and a user installs
301 it, and then does require("foo"), then your main module's exports
302 object will be returned.
303 This should be a module ID relative to the root of your package folder.
305 For most modules, it makes the most sense to have a main script and
307 often not much else.
308 browser
310 If your module is meant to be used client-side the browser field should
311 be used instead of the main field. This is helpful to hint users that
312 it might rely on primitives that aren't available in Node.js modules.
313 (e.g. window)
314 bin
316 A lot of packages have one or more executable files that they'd like to
317 install into the PATH. npm makes this pretty easy (in fact, it uses
318 this feature to install the "npm" executable.)
319 To use this, supply a bin field in your package.json which is a map of
321 command name to local file name. On install, npm will symlink that file
322 into prefix/bin for global installs, or ./node_modules/.bin/ for local
323 installs.
324 For example, myapp could have this:
326 { "bin" : { "myapp" : "./cli.js" } }
328 So, when you install myapp, it'll create a symlink from the cli.js
330 script to /usr/local/bin/myapp.
331 If you have a single executable, and its name should be the name of the
333 package, then you can just supply it as a string. For example:
334 { "name": "my-program"
336 , "version": "1.2.5"
337 , "bin": "./path/to/program" }
338 would be the same as this:
340 { "name": "my-program"
342 , "version": "1.2.5"
343 , "bin" : { "my-program" : "./path/to/program" } }
344 Please make sure that your file(s) referenced in bin starts with
346 #!/usr/bin/env node, otherwise the scripts are started without the node
347 executable!
348 man
350 Specify either a single file or an array of filenames to put in place
351 for the man program to find.
352 If only a single file is provided, then it's installed such that it is
354 the result from man <pkgname>, regardless of its actual filename. For
355 example:
356 { "name" : "foo"
358 , "version" : "1.2.3"
359 , "description" : "A packaged foo fooer for fooing foos"
360 , "main" : "foo.js"
361 , "man" : "./man/doc.1"
362 }
363 would link the ./man/doc.1 file in such that it is the target for man
365 foo
366 If the filename doesn't start with the package name, then it's pre‐
368 fixed. So, this:
369 { "name" : "foo"
371 , "version" : "1.2.3"
372 , "description" : "A packaged foo fooer for fooing foos"
373 , "main" : "foo.js"
374 , "man" : [ "./man/foo.1", "./man/bar.1" ]
375 }
376 will create files to do man foo and man foo-bar.
378 Man files must end with a number, and optionally a .gz suffix if they
380 are compressed. The number dictates which man section the file is
381 installed into.
382 { "name" : "foo"
384 , "version" : "1.2.3"
385 , "description" : "A packaged foo fooer for fooing foos"
386 , "main" : "foo.js"
387 , "man" : [ "./man/foo.1", "./man/foo.2" ]
388 }
389 will create entries for man foo and man 2 foo
391 directories
393 The CommonJS Packages http://wiki.commonjs.org/wiki/Packages/1.0 spec
394 details a few ways that you can indicate the structure of your package
395 using a directories object. If you look at npm's package.json
396 https://registry.npmjs.org/npm/latest, you'll see that it has directo‐
397 ries for doc, lib, and man.
398 In the future, this information may be used in other creative ways.
400 directories.lib
402 Tell people where the bulk of your library is. Nothing special is done
403 with the lib folder in any way, but it's useful meta info.
404 directories.bin
406 If you specify a bin directory in directories.bin, all the files in
407 that folder will be added.
408 Because of the way the bin directive works, specifying both a bin path
410 and setting directories.bin is an error. If you want to specify indi‐
411 vidual files, use bin, and for all the files in an existing bin direc‐
412 tory, use directories.bin.
413 directories.man
415 A folder that is full of man pages. Sugar to generate a "man" array by
416 walking the folder.
417 directories.doc
419 Put markdown files in here. Eventually, these will be displayed
420 nicely, maybe, someday.
421 directories.example
423 Put example scripts in here. Someday, it might be exposed in some
424 clever way.
425 directories.test
427 Put your tests in here. It is currently not exposed, but it might be in
428 the future.
429 repository
431 Specify the place where your code lives. This is helpful for people who
432 want to contribute. If the git repo is on GitHub, then the npm docs
433 command will be able to find you.
434 Do it like this:
436 "repository": {
438 "type" : "git",
439 "url" : "https://github.com/npm/cli.git"
440 }
441 "repository": {
443 "type" : "svn",
444 "url" : "https://v8.googlecode.com/svn/trunk/"
445 }
446 The URL should be a publicly available (perhaps read-only) url that can
448 be handed directly to a VCS program without any modification. It
449 should not be a url to an html project page that you put in your
450 browser. It's for computers.
451 For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use
453 the same shortcut syntax you use for npm install:
454 "repository": "npm/npm"
456 "repository": "github:user/repo"
458 "repository": "gist:11081aaa281"
460 "repository": "bitbucket:user/repo"
462 "repository": "gitlab:user/repo"
464 If the package.json for your package is not in the root directory (for
466 example if it is part of a monorepo), you can specify the directory in
467 which it lives:
468 "repository": {
470 "type" : "git",
471 "url" : "https://github.com/facebook/react.git",
472 "directory": "packages/react-dom"
473 }
474 scripts
476 The "scripts" property is a dictionary containing script commands that
477 are run at various times in the lifecycle of your package. The key is
478 the lifecycle event, and the value is the command to run at that point.
479 See npm help scripts to find out more about writing package scripts.
481 config
483 A "config" object can be used to set configuration parameters used in
484 package scripts that persist across upgrades. For instance, if a pack‐
485 age had the following:
486 { "name" : "foo"
488 , "config" : { "port" : "8080" } }
489 and then had a "start" command that then referenced the npm_pack‐
491 age_config_port environment variable, then the user could override that
492 by doing npm config set foo:port 8001.
493 See npm help config and npm help scripts for more on package configs.
495 dependencies
497 Dependencies are specified in a simple object that maps a package name
498 to a version range. The version range is a string which has one or more
499 space-separated descriptors. Dependencies can also be identified with
500 a tarball or git URL.
501 Please do not put test harnesses or transpilers in your dependencies
503 object. See devDependencies, below.
504 See npm help semver for more details about specifying version ranges.
506 · version Must match version exactly
508 · >version Must be greater than version
510 · >=version etc
512 · <version
514 · <=version
516 · ~version "Approximately equivalent to version" See npm help semver
518 · ^version "Compatible with version" See npm help semver
520 · 1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
522 · http://... See 'URLs as Dependencies' below
524 · * Matches any version
526 · "" (just an empty string) Same as *
528 · version1 - version2 Same as >=version1 <=version2.
530 · range1 || range2 Passes if either range1 or range2 are satisfied.
532 · git... See 'Git URLs as Dependencies' below
534 · user/repo See 'GitHub URLs' below
536 · tag A specific version tagged and published as tag See npm help
538 dist-tag
539 · path/path/path See Local Paths #local-paths below
541 For example, these are all valid:
544 { "dependencies" :
546 { "foo" : "1.0.0 - 2.9999.9999"
547 , "bar" : ">=1.0.2 <2.1.2"
548 , "baz" : ">1.0.2 <=2.3.4"
549 , "boo" : "2.0.1"
550 , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
551 , "asd" : "http://asdf.com/asdf.tar.gz"
552 , "til" : "~1.2"
553 , "elf" : "~1.2.3"
554 , "two" : "2.x"
555 , "thr" : "3.3.x"
556 , "lat" : "latest"
557 , "dyl" : "file:../dyl"
558 }
559 }
560 URLs as Dependencies
562 You may specify a tarball URL in place of a version range.
563 This tarball will be downloaded and installed locally to your package
565 at install time.
566 Git URLs as Dependencies
568 Git urls are of the form:
569 <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
571 <protocol> is one of git, git+ssh, git+http, git+https, or git+file.
573 If #<commit-ish> is provided, it will be used to clone exactly that
575 commit. If the commit-ish has the format #semver:<semver>, <semver> can
576 be any valid semver range or exact version, and npm will look for any
577 tags or refs matching that range in the remote repository, much as it
578 would for a registry dependency. If neither #<commit-ish> or
579 #semver:<semver> is specified, then master is used.
580 Examples:
582 git+ssh://git@github.com:npm/cli.git#v1.0.27
584 git+ssh://git@github.com:npm/cli#semver:^5.0
585 git+https://isaacs@github.com/npm/cli.git
586 git://github.com/npm/cli.git#v1.0.27
587 GitHub URLs
589 As of version 1.1.65, you can refer to GitHub urls as just "foo":
590 "user/foo-project". Just as with git URLs, a commit-ish suffix can be
591 included. For example:
592 {
594 "name": "foo",
595 "version": "0.0.0",
596 "dependencies": {
597 "express": "expressjs/express",
598 "mocha": "mochajs/mocha#4727d357ea",
599 "module": "user/repo#feature\/branch"
600 }
601 }
602 Local Paths
604 As of version 2.0.0 you can provide a path to a local directory that
605 contains a package. Local paths can be saved using npm install -S or
606 npm install --save, using any of these forms:
607 ../foo/bar
609 ~/foo/bar
610 ./foo/bar
611 /foo/bar
612 in which case they will be normalized to a relative path and added to
614 your package.json. For example:
615 {
617 "name": "baz",
618 "dependencies": {
619 "bar": "file:../foo/bar"
620 }
621 }
622 This feature is helpful for local offline development and creating
624 tests that require npm installing where you don't want to hit an exter‐
625 nal server, but should not be used when publishing packages to the pub‐
626 lic registry.
627 devDependencies
629 If someone is planning on downloading and using your module in their
630 program, then they probably don't want or need to download and build
631 the external test or documentation framework that you use.
632 In this case, it's best to map these additional items in a devDependen‐
634 cies object.
635 These things will be installed when doing npm link or npm install from
637 the root of a package, and can be managed like any other npm configura‐
638 tion param. See npm help config for more on the topic.
639 For build steps that are not platform-specific, such as compiling Cof‐
641 feeScript or other languages to JavaScript, use the prepare script to
642 do this, and make the required package a devDependency.
643 For example:
645 { "name": "ethopia-waza",
647 "description": "a delightfully fruity coffee varietal",
648 "version": "1.2.3",
649 "devDependencies": {
650 "coffee-script": "~1.6.3"
651 },
652 "scripts": {
653 "prepare": "coffee -o lib/ -c src/waza.coffee"
654 },
655 "main": "lib/waza.js"
656 }
657 The prepare script will be run before publishing, so that users can
659 consume the functionality without requiring them to compile it them‐
660 selves. In dev mode (ie, locally running npm install), it'll run this
661 script as well, so that you can test it easily.
662 peerDependencies
664 In some cases, you want to express the compatibility of your package
665 with a host tool or library, while not necessarily doing a require of
666 this host. This is usually referred to as a plugin. Notably, your mod‐
667 ule may be exposing a specific interface, expected and specified by the
668 host documentation.
669 For example:
671 {
673 "name": "tea-latte",
674 "version": "1.3.5",
675 "peerDependencies": {
676 "tea": "2.x"
677 }
678 }
679 This ensures your package tea-latte can be installed along with the
681 second major version of the host package tea only. npm install
682 tea-latte could possibly yield the following dependency graph:
683 ├── tea-latte@1.3.5
685 └── tea@2.2.0
686 NOTE: npm versions 1 and 2 will automatically install peerDependencies
688 if they are not explicitly depended upon higher in the dependency tree.
689 In the next major version of npm (npm@3), this will no longer be the
690 case. You will receive a warning that the peerDependency is not
691 installed instead. The behavior in npms 1 & 2 was frequently confusing
692 and could easily put you into dependency hell, a situation that npm is
693 designed to avoid as much as possible.
694 Trying to install another plugin with a conflicting requirement will
696 cause an error. For this reason, make sure your plugin requirement is
697 as broad as possible, and not to lock it down to specific patch ver‐
698 sions.
699 Assuming the host complies with semver https://semver.org/, only
701 changes in the host package's major version will break your plugin.
702 Thus, if you've worked with every 1.x version of the host package, use
703 "^1.0" or "1.x" to express this. If you depend on features introduced
704 in 1.5.2, use ">= 1.5.2 < 2".
705 bundledDependencies
707 This defines an array of package names that will be bundled when pub‐
708 lishing the package.
709 In cases where you need to preserve npm packages locally or have them
711 available through a single file download, you can bundle the packages
712 in a tarball file by specifying the package names in the bundledDepen‐
713 dencies array and executing npm pack.
714 For example:
716 If we define a package.json like this:
718 {
720 "name": "awesome-web-framework",
721 "version": "1.0.0",
722 "bundledDependencies": [
723 "renderized", "super-streams"
724 ]
725 }
726 we can obtain awesome-web-framework-1.0.0.tgz file by running npm pack.
728 This file contains the dependencies renderized and super-streams which
729 can be installed in a new project by executing npm install awe‐
730 some-web-framework-1.0.0.tgz. Note that the package names do not
731 include any versions, as that information is specified in dependencies.
732 If this is spelled "bundleDependencies", then that is also honored.
734 optionalDependencies
736 If a dependency can be used, but you would like npm to proceed if it
737 cannot be found or fails to install, then you may put it in the option‐
738 alDependencies object. This is a map of package name to version or
739 url, just like the dependencies object. The difference is that build
740 failures do not cause installation to fail. Running npm install
741 --no-optional will prevent these dependencies from being installed.
742 It is still your program's responsibility to handle the lack of the
744 dependency. For example, something like this:
745 try {
747 var foo = require('foo')
748 var fooVersion = require('foo/package.json').version
749 } catch (er) {
750 foo = null
751 }
752 if ( notGoodFooVersion(fooVersion) ) {
753 foo = null
754 }
755 // .. then later in your program ..
757 if (foo) {
759 foo.doFooThings()
760 }
761 Entries in optionalDependencies will override entries of the same name
763 in dependencies, so it's usually best to only put in one place.
764 engines
766 You can specify the version of node that your stuff works on:
767 { "engines" : { "node" : ">=0.10.3 <0.12" } }
769 And, like with dependencies, if you don't specify the version (or if
771 you specify "*" as the version), then any version of node will do.
772 If you specify an "engines" field, then npm will require that "node" be
774 somewhere on that list. If "engines" is omitted, then npm will just
775 assume that it works on node.
776 You can also use the "engines" field to specify which versions of npm
778 are capable of properly installing your program. For example:
779 { "engines" : { "npm" : "~1.0.20" } }
781 Unless the user has set the engine-strict config flag, this field is
783 advisory only and will only produce warnings when your package is
784 installed as a dependency.
785 engineStrict
787 This feature was removed in npm 3.0.0
788 Prior to npm 3.0.0, this feature was used to treat this package as if
790 the user had set engine-strict. It is no longer used.
791 os
793 You can specify which operating systems your module will run on:
794 "os" : [ "darwin", "linux" ]
796 You can also blacklist instead of whitelist operating systems, just
798 prepend the blacklisted os with a '!':
799 "os" : [ "!win32" ]
801 The host operating system is determined by process.platform
803 It is allowed to both blacklist, and whitelist, although there isn't
805 any good reason to do this.
806 cpu
808 If your code only runs on certain cpu architectures, you can specify
809 which ones.
810 "cpu" : [ "x64", "ia32" ]
812 Like the os option, you can also blacklist architectures:
814 "cpu" : [ "!arm", "!mips" ]
816 The host architecture is determined by process.arch
818 preferGlobal
820 DEPRECATED
821 This option used to trigger an npm warning, but it will no longer warn.
823 It is purely there for informational purposes. It is now recommended
824 that you install any binaries as local devDependencies wherever possi‐
825 ble.
826 private
828 If you set "private": true in your package.json, then npm will refuse
829 to publish it.
830 This is a way to prevent accidental publication of private reposito‐
832 ries. If you would like to ensure that a given package is only ever
833 published to a specific registry (for example, an internal registry),
834 then use the publishConfig dictionary described below to override the
835 registry config param at publish-time.
836 publishConfig
838 This is a set of config values that will be used at publish-time. It's
839 especially handy if you want to set the tag, registry or access, so
840 that you can ensure that a given package is not tagged with "latest",
841 published to the global public registry or that a scoped module is pri‐
842 vate by default.
843 Any config values can be overridden, but only "tag", "registry" and
845 "access" probably matter for the purposes of publishing.
846 See npm help config to see the list of config options that can be over‐
848 ridden.
849 DEFAULT VALUES
851 npm will default some values based on package contents.
852 · "scripts": {"start": "node server.js"} If there is a server.js file
854 in the root of your package, then npm will default the start command
855 to node server.js.
856 · "scripts":{"install": "node-gyp rebuild"} If there is a binding.gyp
858 file in the root of your package and you have not defined an install
859 or preinstall script, npm will default the install command to compile
860 using node-gyp.
861 · "contributors": [...] If there is an AUTHORS file in the root of
863 your package, npm will treat each line as a Name <email> (url) for‐
864 mat, where email and url are optional. Lines which start with a # or
865 are blank, will be ignored.
866 SEE ALSO
869 · npm help semver
870 · npm help init
872 · npm help version
874 · npm help config
876 · npm help help
878 · npm help install
880 · npm help publish
882 · npm help uninstall
884 March 2020 PACKAGE.JSON(5)