Go to main content

man pages section 1: User Commands

Exit Print View

Updated: Wednesday, February 9, 2022
 
 

npm-update (1)

Name

npm-update - Update packages Synopsis npm update [-g] [<pkg>...] aliases: up, upgrade Description This command will update all the packages listed to the latest version (specified by the tag config), respecting the semver constraints of both your package and its dependencies (if they also require the same package). It will also install missing packages. If the -g flag is specified, this command will update globally installed packages. If no package name is specified, all packages in the specified location (global or local) will be updated. Example For the examples below, assume that the current package is app and it depends on dependencies, dep1 (dep2, .. etc.). The published versions of dep1 are: { "dist-tags": { "latest": "1.2.2" }, "versions": [ "1.2.2", "1.2.1", "1.2.0", "1.1.2", "1.1.1", "1.0.0", "0.4.1", "0.4.0", "0.2.0" ] } Caret Dependencies If app's package.json contains: "dependencies": { "dep1": "^1.1.1" } Then npm update will install dep1@1.2.2, because 1.2.2 is latest and 1.2.2 satisfies ^1.1.1. Tilde Dependencies However, if app's package.json contains: "dependencies": { "dep1": "~1.1.1" } In this case, running npm update will install dep1@1.1.2. Even though the latest tag points to 1.2.2, this version do not satisfy ~1.1.1, which is equivalent to >=1.1.1 <1.2.0. So the highest-sorting version that satisfies ~1.1.1 is used, which is 1.1.2. Caret Dependencies below 1.0.0 Suppose app has a caret dependency on a version below 1.0.0, for exam- ple: "dependencies": { "dep1": "^0.2.0" } npm update will install dep1@0.2.0, because there are no other versions which satisfy ^0.2.0. If the dependence were on ^0.4.0: "dependencies": { "dep1": "^0.4.0" } Then npm update will install dep1@0.4.1, because that is the high- est-sorting version that satisfies ^0.4.0 (>= 0.4.0 <0.5.0) Subdependencies Suppose your app now also has a dependency on dep2 { "name": "my-app", "dependencies": { "dep1": "^1.0.0", "dep2": "1.0.0" } } and dep2 itself depends on this limited range of dep1 { "name": "dep2", "dependencies": { "dep1": "~1.1.1" } } Then npm update will install dep1@1.1.2 because that is the highest version that dep2 allows. npm will prioritize having a single version of dep1 in your tree rather than two when that single version can sat- isfy the semver requirements of multiple dependencies in your tree. In this case if you really did need your package to use a newer version you would need to use npm install. Updating Globally-Installed Packages npm update -g will apply the update action to each globally installed package that is outdated -- that is, has a version that is different from wanted. Note: Globally installed packages are treated as if they are installed with a caret semver range specified. So if you require to update to latest you may need to run npm install -g [<pkg>...] NOTE: If a package has been upgraded to a version newer than latest, it will be downgraded. Configuration <!-- AUTOGENERATED CONFIG DESCRIPTIONS START --> <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/defini- tions.js --> global o Default: false o Type: Boolean Operates in "global" mode, so that packages are installed into the pre- fix folder instead of the current working directory. See npm help fold- ers for more on the differences in behavior. o packages are installed into the {prefix}/lib/node_modules folder, instead of the current working directory. o bin files are linked to {prefix}/bin o man pages are linked to {prefix}/share/man <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> global-style o Default: false o Type: Boolean Causes npm to install the package into your local node_modules folder with the same layout it uses with the global node_modules folder. Only your direct dependencies will show in node_modules and everything they depend on will be flattened in their node_modules folders. This obvi- ously will eliminate some deduping. If used with legacy-bundling, legacy-bundling will be preferred. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> legacy-bundling o Default: false o Type: Boolean Causes npm to install the package such that versions of npm prior to 1.4, such as the one included with node 0.8, can install the package. This eliminates all automatic deduping. If used with global-style this option will be preferred. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> strict-peer-deps o Default: false o Type: Boolean If set to true, and --legacy-peer-deps is not set, then any conflicting peerDependencies will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships. By default, conflicting peerDependencies deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer depen- dency outside the range set in their package's peerDependencies object. When such and override is performed, a warning is printed, explaining the conflict and the packages involved. If --strict-peer-deps is set, then this warning is treated as a failure. <!-- automatically gener- ated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> package-lock o Default: true o Type: Boolean If set to false, then ignore package-lock.json files when installing. This will also prevent writing package-lock.json if save is true. When package package-locks are disabled, automatic pruning of extrane- ous modules will also be disabled. To remove extraneous modules with package-locks disabled use npm prune. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> omit o Default: 'dev' if the NODE_ENV environment variable is set to 'pro- duction', otherwise empty. o Type: "dev", "optional", or "peer" (can be set multiple times) Dependency types to omit from the installation tree on disk. Note that these dependencies are still resolved and added to the pack- age-lock.json or npm-shrinkwrap.json file. They are just not physically installed on disk. If a package type appears in both the --include and --omit lists, then it will be included. If the resulting omit list includes 'dev', then the NODE_ENV environ- ment variable will be set to 'production' for all lifecycle scripts. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> ignore-scripts o Default: false o Type: Boolean If true, npm does not run scripts specified in package.json files. Note that commands explicitly intended to run a particular script, such as npm start, npm stop, npm restart, npm test, and npm run-script will still run their intended script if ignore-scripts is set, but they will not run any pre- or post-scripts. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> audit o Default: true o Type: Boolean When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> bin-links o Default: true o Type: Boolean Tells npm to create symlinks (or .cmd shims on Windows) for package executables. Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on osten- sibly Unix systems. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> fund o Default: true o Type: Boolean When "true" displays the message at the end of each npm install acknowledging the number of dependencies looking for funding. See npm help npm fund for details. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> dry-run o Default: false o Type: Boolean Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, install, update, dedupe, uninstall, as well as pack and publish. Note: This is NOT honored by other network related commands, eg dist-tags, owner, etc. <!-- automatically generated, do not edit manu- ally --> <!-- see lib/utils/config/definitions.js --> workspace o Default: o Type: String (can be set multiple times) Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option. Valid values for the workspace config are either: o Workspace names o Path to a workspace directory o Path to a parent workspace directory (will result to selecting all of the nested workspaces) When set for the npm init command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project. This value is not exported to the environment for child processes. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> workspaces o Default: false o Type: Boolean Enable running a command in the context of all the configured workspaces. This value is not exported to the environment for child processes. <!-- automatically generated, do not edit manually --> <!-- see lib/utils/config/definitions.js --> <!-- AUTOGENERATED CONFIG DESCRIPTIONS END --> See Also o npm help install o npm help outdated o npm help shrinkwrap o npm help registry o npm help folders o npm help ls

Synopsis

Please see following description for synopsis

Description

NPM-UPDATE(1)                                                    NPM-UPDATE(1)



NAME
       npm-update - Update packages

   Synopsis
         npm update [-g] [<pkg>...]

         aliases: up, upgrade

   Description
       This  command will update all the packages listed to the latest version
       (specified by the tag config), respecting  the  semver  constraints  of
       both  your  package and its dependencies (if they also require the same
       package).

       It will also install missing packages.

       If the  -g  flag  is  specified,  this  command  will  update  globally
       installed packages.

       If no package name is specified, all packages in the specified location
       (global or local) will be updated.

   Example
       For the examples below, assume that the current package is app  and  it
       depends  on dependencies, dep1 (dep2, .. etc.).  The published versions
       of dep1 are:

         {
           "dist-tags": { "latest": "1.2.2" },
           "versions": [
             "1.2.2",
             "1.2.1",
             "1.2.0",
             "1.1.2",
             "1.1.1",
             "1.0.0",
             "0.4.1",
             "0.4.0",
             "0.2.0"
           ]
         }

   Caret Dependencies
       If app's package.json contains:

         "dependencies": {
           "dep1": "^1.1.1"
         }

       Then npm update will install dep1@1.2.2, because 1.2.2  is  latest  and
       1.2.2 satisfies ^1.1.1.

   Tilde Dependencies
       However, if app's package.json contains:

         "dependencies": {
           "dep1": "~1.1.1"
         }

       In  this case, running npm update will install dep1@1.1.2.  Even though
       the latest tag points to 1.2.2, this version  do  not  satisfy  ~1.1.1,
       which  is equivalent to >=1.1.1 <1.2.0.  So the highest-sorting version
       that satisfies ~1.1.1 is used, which is 1.1.2.

   Caret Dependencies below 1.0.0
       Suppose app has a caret dependency on a version below 1.0.0, for  exam-
       ple:

         "dependencies": {
           "dep1": "^0.2.0"
         }

       npm update will install dep1@0.2.0, because there are no other versions
       which satisfy ^0.2.0.

       If the dependence were on ^0.4.0:

         "dependencies": {
           "dep1": "^0.4.0"
         }

       Then npm update will install dep1@0.4.1,  because  that  is  the  high-
       est-sorting version that satisfies ^0.4.0 (>= 0.4.0 <0.5.0)

   Subdependencies
       Suppose your app now also has a dependency on dep2

         {
           "name": "my-app",
           "dependencies": {
               "dep1": "^1.0.0",
               "dep2": "1.0.0"
           }
         }

       and dep2 itself depends on this limited range of dep1

         {
         "name": "dep2",
           "dependencies": {
             "dep1": "~1.1.1"
           }
         }

       Then  npm  update  will  install dep1@1.1.2 because that is the highest
       version that dep2 allows.  npm will prioritize having a single  version
       of  dep1 in your tree rather than two when that single version can sat-
       isfy the semver requirements of multiple dependencies in your tree.  In
       this  case  if  you really did need your package to use a newer version
       you would need to use npm install.

   Updating Globally-Installed Packages
       npm update -g will apply the update action to each  globally  installed
       package  that  is  outdated -- that is, has a version that is different
       from wanted.

       Note: Globally installed packages are treated as if they are  installed
       with  a  caret  semver  range specified. So if you require to update to
       latest you may need to run npm install -g [<pkg>...]

       NOTE: If a package has been upgraded to a version newer than latest, it
       will be downgraded.

   Configuration
       <!--  AUTOGENERATED  CONFIG  DESCRIPTIONS  START --> <!-- automatically
       generated, do not edit manually --> <!--  see  lib/utils/config/defini-
       tions.js -->

   global
       o Default: false

       o Type: Boolean


       Operates in "global" mode, so that packages are installed into the pre-
       fix folder instead of the current working directory. See npm help fold-
       ers for more on the differences in behavior.

       o packages  are  installed  into  the {prefix}/lib/node_modules folder,
         instead of the current working directory.

       o bin files are linked to {prefix}/bin

       o man pages are linked to {prefix}/share/man

       <!-- automatically  generated,  do  not  edit  manually  -->  <!--  see
       lib/utils/config/definitions.js -->


   global-style
       o Default: false

       o Type: Boolean


       Causes  npm  to install the package into your local node_modules folder
       with the same layout it uses with the global node_modules folder.  Only
       your  direct dependencies will show in node_modules and everything they
       depend on will be flattened in their node_modules folders.  This  obvi-
       ously  will  eliminate  some  deduping.  If  used with legacy-bundling,
       legacy-bundling will be preferred.  <!--  automatically  generated,  do
       not edit manually --> <!-- see lib/utils/config/definitions.js -->


   legacy-bundling
       o Default: false

       o Type: Boolean


       Causes  npm  to  install the package such that versions of npm prior to
       1.4, such as the one included with node 0.8, can install  the  package.
       This  eliminates all automatic deduping. If used with global-style this
       option will be preferred.  <!-- automatically generated,  do  not  edit
       manually --> <!-- see lib/utils/config/definitions.js -->


   strict-peer-deps
       o Default: false

       o Type: Boolean


       If set to true, and --legacy-peer-deps is not set, then any conflicting
       peerDependencies will be treated as an install  failure,  even  if  npm
       could  reasonably  guess  the  appropriate resolution based on non-peer
       dependency relationships.

       By default, conflicting peerDependencies deep in the  dependency  graph
       will  be  resolved using the nearest non-peer dependency specification,
       even if doing so will result in some packages receiving a  peer  depen-
       dency outside the range set in their package's peerDependencies object.

       When  such  and override is performed, a warning is printed, explaining
       the conflict and the packages involved. If --strict-peer-deps  is  set,
       then  this  warning is treated as a failure.  <!-- automatically gener-
       ated, do not edit manually --> <!-- see lib/utils/config/definitions.js
       -->


   package-lock
       o Default: true

       o Type: Boolean


       If  set  to false, then ignore package-lock.json files when installing.
       This will also prevent writing package-lock.json if save is true.

       When package package-locks are disabled, automatic pruning of  extrane-
       ous  modules  will  also be disabled. To remove extraneous modules with
       package-locks disabled use npm prune.  <!-- automatically generated, do
       not edit manually --> <!-- see lib/utils/config/definitions.js -->


   omit
       o Default:  'dev'  if the NODE_ENV environment variable is set to 'pro-
         duction', otherwise empty.

       o Type: "dev", "optional", or "peer" (can be set multiple times)


       Dependency types to omit from the installation tree on disk.

       Note that these dependencies are still resolved and added to the  pack-
       age-lock.json or npm-shrinkwrap.json file. They are just not physically
       installed on disk.

       If a package type appears in both the --include and --omit lists,  then
       it will be included.

       If  the  resulting omit list includes 'dev', then the NODE_ENV environ-
       ment variable will be set to 'production' for  all  lifecycle  scripts.
       <!--  automatically  generated,  do  not  edit  manually  -->  <!-- see
       lib/utils/config/definitions.js -->


   ignore-scripts
       o Default: false

       o Type: Boolean


       If true, npm does not run scripts specified in package.json files.

       Note that commands explicitly intended to run a particular script, such
       as  npm start, npm stop, npm restart, npm test, and npm run-script will
       still run their intended script if ignore-scripts is set, but they will
       not run any pre- or post-scripts.  <!-- automatically generated, do not
       edit manually --> <!-- see lib/utils/config/definitions.js -->


   audit
       o Default: true

       o Type: Boolean


       When "true" submit audit reports alongside the current npm  command  to
       the  default registry and all registries configured for scopes. See the
       documentation for npm help audit for  details  on  what  is  submitted.
       <!--  automatically  generated,  do  not  edit  manually  -->  <!-- see
       lib/utils/config/definitions.js -->


   bin-links
       o Default: true

       o Type: Boolean


       Tells npm to create symlinks (or .cmd shims  on  Windows)  for  package
       executables.

       Set  to  false  to have it not do this. This can be used to work around
       the fact that some file systems don't support symlinks, even on  osten-
       sibly Unix systems.  <!-- automatically generated, do not edit manually
       --> <!-- see lib/utils/config/definitions.js -->


   fund
       o Default: true

       o Type: Boolean


       When "true" displays the  message  at  the  end  of  each  npm  install
       acknowledging  the  number of dependencies looking for funding. See npm
       help npm fund for details.  <!-- automatically generated, do  not  edit
       manually --> <!-- see lib/utils/config/definitions.js -->


   dry-run
       o Default: false

       o Type: Boolean


       Indicates  that  you  don't  want  npm  to make any changes and that it
       should only report what it would have done. This can be passed into any
       of  the  commands  that  modify  your  local installation, eg, install,
       update, dedupe, uninstall, as well as pack and publish.

       Note: This is  NOT  honored  by  other  network  related  commands,  eg
       dist-tags, owner, etc.  <!-- automatically generated, do not edit manu-
       ally --> <!-- see lib/utils/config/definitions.js -->


   workspace
       o Default:

       o Type: String (can be set multiple times)


       Enable running a command in the context of the configured workspaces of
       the  current  project  while  filtering  by running only the workspaces
       defined by this configuration option.

       Valid values for the workspace config are either:

       o Workspace names

       o Path to a workspace directory

       o Path to a parent workspace directory (will result to selecting all of
         the nested workspaces)


       When  set  for the npm init command, this may be set to the folder of a
       workspace which does not yet exist, to create the folder and set it  up
       as a brand new workspace within the project.

       This  value  is  not  exported  to the environment for child processes.
       <!-- automatically  generated,  do  not  edit  manually  -->  <!--  see
       lib/utils/config/definitions.js -->


   workspaces
       o Default: false

       o Type: Boolean


       Enable  running  a  command  in  the  context  of  all  the  configured
       workspaces.

       This value is not exported to  the  environment  for  child  processes.
       <!--  automatically  generated,  do  not  edit  manually  -->  <!-- see
       lib/utils/config/definitions.js -->

       <!-- AUTOGENERATED CONFIG DESCRIPTIONS END -->


   See Also
       o npm help install

       o npm help outdated

       o npm help shrinkwrap

       o npm help registry

       o npm help folders

       o npm help ls




ATTRIBUTES
       See attributes(7) for descriptions of the following attributes:


       +---------------+--------------------------+
       |ATTRIBUTE TYPE |     ATTRIBUTE VALUE      |
       +---------------+--------------------------+
       |Availability   | runtime/nodejs/nodejs-16 |
       +---------------+--------------------------+
       |Stability      | Pass-thru volatile       |
       +---------------+--------------------------+

NOTES
       Source code for open source software components in Oracle  Solaris  can
       be found at https://www.oracle.com/downloads/opensource/solaris-source-
       code-downloads.html.

       This    software    was    built    from    source     available     at
       https://github.com/oracle/solaris-userland.    The  original  community
       source   was   downloaded   from     https://github.com/nodejs/node/ar-
       chive/v16.11.1.zip.

       Further information about this software can be found on the open source
       community website at https://github.com/nodejs/node.



                                 October 2021                    NPM-UPDATE(1)