1PACKAGE.JSON(5)                                                PACKAGE.JSON(5)
2
3
4

NAME

6       package.json - Specifics of npm's package.json handling
7
8   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
13       A  lot  of  the  behavior described in this document is affected by the
14       config settings described in npm help config.
15
16   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
24       The name is what your thing is called.
25
26       Some rules:
27
28       · The  name must be less than or equal to 214 characters. This includes
29         the scope for scoped packages.
30
31       · The names of scoped packages can begin with a dot or  an  underscore.
32         This is not permitted without a scope.
33
34       · New packages must not have uppercase letters in the name.
35
36       · 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
40
41       Some tips:
42
43       · Don't use the same name as a core Node module.
44
45       · 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
49       · The  name  will probably be passed as an argument to require(), so it
50         should be something short, but also reasonably descriptive.
51
52       · 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
56
57       A name can be optionally prefixed by a  scope,  e.g.  @myorg/mypackage.
58       See npm help scope for more detail.
59
60   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
68       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
72       More on version numbers and ranges at npm help semver.
73
74   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
78   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
82   homepage
83       The url to the project homepage.
84
85       Example:
86
87         "homepage": "https://github.com/owner/project#readme"
88
89   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
94       It should look like this:
95
96         { "url" : "https://github.com/owner/project/issues"
97         , "email" : "project@hostname.com"
98         }
99
100       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
104       If a url is provided, it will be used by the npm bugs command.
105
106   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
111       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
115         { "license" : "BSD-3-Clause" }
116
117       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
121       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
125         { "license" : "(ISC OR GPL-3.0)" }
126
127       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
131         { "license" : "SEE LICENSE IN <filename>" }
132
133       Then include a file named <filename> at the top level of the package.
134
135       Some old packages used license objects or a  "licenses"  property  con‐
136       taining an array of license objects:
137
138         // Not valid metadata
139         { "license" :
140           { "type" : "ISC"
141           , "url" : "https://opensource.org/licenses/ISC"
142           }
143         }
144
145         // 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
157       Those  styles  are  now deprecated. Instead, use SPDX expressions, like
158       this:
159
160         { "license": "ISC" }
161
162         { "license": "(MIT OR Apache-2.0)" }
163
164       Finally, if you do not wish to grant others the right to use a  private
165       or unpublished package under any terms:
166
167         { "license": "UNLICENSED" }
168
169       Consider  also  setting  "private": true to prevent accidental publica‐
170       tion.
171
172   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
177         { "name" : "Barney Rubble"
178         , "email" : "b@rubble.com"
179         , "url" : "http://barnyrubble.tumblr.com/"
180         }
181
182       Or you can shorten that all into a single string, and npm will parse it
183       for you:
184
185         "Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
186
187       Both email and url are optional either way.
188
189       npm also sets a top-level "maintainers" field with your npm user info.
190
191   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
196         "funding": {
197           "type" : "individual",
198           "url" : "http://example.com/donate"
199         }
200
201         "funding": {
202           "type" : "patreon",
203           "url" : "https://www.patreon.com/my-account"
204         }
205
206         "funding": "http://example.com/donate"
207
208         "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
220       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
226   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
235       Some  special  files  and  directories  are  also  included or excluded
236       regardless of whether they exist in the files array (see below).
237
238       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
245       Files  included  with the "package.json#files" field cannot be excluded
246       through .npmignore or .gitignore.
247
248       Certain files are always included, regardless of settings:
249
250       · package.json
251
252       · README
253
254       · CHANGES / CHANGELOG / HISTORY
255
256       · LICENSE / LICENCE
257
258       · NOTICE
259
260       · The file in the "main" field
261
262
263       README, CHANGES, LICENSE & NOTICE can have any case and extension.
264
265       Conversely, some files are always ignored:
266
267       · .git
268
269       · CVS
270
271       · .svn
272
273       · .hg
274
275       · .lock-wscript
276
277       · .wafpickle-N
278
279       · .DS_Store
280
281       · npm-debug.log
282
283       · .npmrc
284
285       · node_modules
286
287       · config.gypi
288
289       · package-lock.json (use shrinkwrap instead)
290
291       · All files containing a * character (incompatible with Windows)
292
293
294   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
300       This should be a module ID relative to the root of your package folder.
301
302       For  most  modules,  it  makes the most sense to have a main script and
303       often not much else.
304
305   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
311   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
316       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
321       For example, myapp could have this:
322
323         { "bin" : { "myapp" : "./cli.js" } }
324
325       So, when you install myapp, it'll create  a  symlink  from  the  cli.js
326       script to /usr/local/bin/myapp.
327
328       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
331         { "name": "my-program"
332         , "version": "1.2.5"
333         , "bin": "./path/to/program" }
334
335       would be the same as this:
336
337         { "name": "my-program"
338         , "version": "1.2.5"
339         , "bin" : { "my-program" : "./path/to/program" } }
340
341       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
345   man
346       Specify either a single file or an array of filenames to put  in  place
347       for the man program to find.
348
349       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
353         { "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
360       would  link  the ./man/doc.1 file in such that it is the target for man
361       foo
362
363       If the filename doesn't start with the package  name,  then  it's  pre‐
364       fixed.  So, this:
365
366         { "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
373       will create files to do man foo and man foo-bar.
374
375       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
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
386       will create entries for man foo and man 2 foo
387
388   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
395       In the future, this information may be used in other creative ways.
396
397   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
401   directories.bin
402       If you specify a bin directory in directories.bin,  all  the  files  in
403       that folder will be added.
404
405       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
410   directories.man
411       A folder that is full of man pages.  Sugar to generate a "man" array by
412       walking the folder.
413
414   directories.doc
415       Put  markdown  files  in  here.   Eventually,  these  will be displayed
416       nicely, maybe, someday.
417
418   directories.example
419       Put example scripts in here.  Someday, it  might  be  exposed  in  some
420       clever way.
421
422   directories.test
423       Put your tests in here. It is currently not exposed, but it might be in
424       the future.
425
426   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
431       Do it like this:
432
433         "repository": {
434           "type" : "git",
435           "url" : "https://github.com/npm/cli.git"
436         }
437
438         "repository": {
439           "type" : "svn",
440           "url" : "https://v8.googlecode.com/svn/trunk/"
441         }
442
443       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
448       For  GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use
449       the same shortcut syntax you use for npm install:
450
451         "repository": "npm/npm"
452
453         "repository": "github:user/repo"
454
455         "repository": "gist:11081aaa281"
456
457         "repository": "bitbucket:user/repo"
458
459         "repository": "gitlab:user/repo"
460
461       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
465         "repository": {
466           "type" : "git",
467           "url" : "https://github.com/facebook/react.git",
468           "directory": "packages/react-dom"
469         }
470
471   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
476       See npm help scripts to find out more about writing package scripts.
477
478   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
483         { "name" : "foo"
484         , "config" : { "port" : "8080" } }
485
486       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
490       See npm help config and npm help scripts for more on package configs.
491
492   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
498       Please  do  not  put test harnesses or transpilers in your dependencies
499       object.  See devDependencies, below.
500
501       See npm help semver for more details about specifying version ranges.
502
503       · version Must match version exactly
504
505       · >version Must be greater than version
506
507       · >=version etc
508
509       · <version
510
511       · <=version
512
513       · ~version "Approximately equivalent to version"  See npm help semver
514
515       · ^version "Compatible with version"  See npm help semver
516
517       · 1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
518
519       · http://... See 'URLs as Dependencies' below
520
521       · * Matches any version
522
523       · "" (just an empty string) Same as *
524
525       · version1 - version2 Same as >=version1 <=version2.
526
527       · range1 || range2 Passes if either range1 or range2 are satisfied.
528
529       · git... See 'Git URLs as Dependencies' below
530
531       · user/repo See 'GitHub URLs' below
532
533       · tag A specific version tagged and published  as  tag   See  npm  help
534         dist-tag
535
536       · path/path/path See Local Paths #local-paths below
537
538
539       For example, these are all valid:
540
541         { "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
557   URLs as Dependencies
558       You may specify a tarball URL in place of a version range.
559
560       This  tarball  will be downloaded and installed locally to your package
561       at install time.
562
563   Git URLs as Dependencies
564       Git urls are of the form:
565
566         <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
567
568       <protocol> is one of git, git+ssh, git+http, git+https, or git+file.
569
570       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
577       Examples:
578
579         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
584   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
589         {
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
599   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
604         ../foo/bar
605         ~/foo/bar
606         ./foo/bar
607         /foo/bar
608
609       in  which  case they will be normalized to a relative path and added to
610       your package.json. For example:
611
612         {
613           "name": "baz",
614           "dependencies": {
615             "bar": "file:../foo/bar"
616           }
617         }
618
619       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
624   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
629       In this case, it's best to map these additional items in a devDependen‐
630       cies object.
631
632       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
636       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
640       For example:
641
642         { "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
654       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
659   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
666       For example:
667
668         {
669           "name": "tea-latte",
670           "version": "1.3.5",
671           "peerDependencies": {
672             "tea": "2.x"
673           }
674         }
675
676       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
680         ├── tea-latte@1.3.5
681         └── tea@2.2.0
682
683       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
691       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
696       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
702   bundledDependencies
703       This defines an array of package names that will be bundled  when  pub‐
704       lishing the package.
705
706       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
711       For example:
712
713       If we define a package.json like this:
714
715         {
716           "name": "awesome-web-framework",
717           "version": "1.0.0",
718           "bundledDependencies": [
719             "renderized", "super-streams"
720           ]
721         }
722
723       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
729       If this is spelled "bundleDependencies", then that is also honored.
730
731   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
739       It  is  still  your  program's responsibility to handle the lack of the
740       dependency.  For example, something like this:
741
742         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
752         // .. then later in your program ..
753
754         if (foo) {
755           foo.doFooThings()
756         }
757
758       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
761   engines
762       You can specify the version of node that your stuff works on:
763
764         { "engines" : { "node" : ">=0.10.3 <0.12" } }
765
766       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
769       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
773       You can also use the "engines" field to specify which versions  of  npm
774       are capable of properly installing your program.  For example:
775
776         { "engines" : { "npm" : "~1.0.20" } }
777
778       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
782   engineStrict
783       This feature was removed in npm 3.0.0
784
785       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
788   os
789       You can specify which operating systems your module will run on:
790
791         "os" : [ "darwin", "linux" ]
792
793       You can also blacklist instead of  whitelist  operating  systems,  just
794       prepend the blacklisted os with a '!':
795
796         "os" : [ "!win32" ]
797
798       The host operating system is determined by process.platform
799
800       It  is  allowed  to both blacklist, and whitelist, although there isn't
801       any good reason to do this.
802
803   cpu
804       If your code only runs on certain cpu architectures,  you  can  specify
805       which ones.
806
807         "cpu" : [ "x64", "ia32" ]
808
809       Like the os option, you can also blacklist architectures:
810
811         "cpu" : [ "!arm", "!mips" ]
812
813       The host architecture is determined by process.arch
814
815   preferGlobal
816       DEPRECATED
817
818       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
823   private
824       If you set "private": true in your package.json, then npm  will  refuse
825       to publish it.
826
827       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
833   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
840       Any  config  values  can  be overridden, but only "tag", "registry" and
841       "access" probably matter for the purposes of publishing.
842
843       See npm help config to see the list of config options that can be over‐
844       ridden.
845
846   DEFAULT VALUES
847       npm will default some values based on package contents.
848
849       · "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
853       · "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
858       · "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
863
864   SEE ALSO
865       · npm help semver
866
867       · npm help init
868
869       · npm help version
870
871       · npm help config
872
873       · npm help help
874
875       · npm help install
876
877       · npm help publish
878
879       · npm help uninstall
880
881
882
883
884                                 February 2021                 PACKAGE.JSON(5)
Impressum