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

NAME

6       package-lock.json - A manifestation of the manifest
7
8   Description
9       package-lock.json  is  automatically generated for any operations where
10       npm modifies either the node_modules  tree,  or  package.json.  It  de‐
11       scribes  the  exact  tree  that was generated, such that subsequent in‐
12       stalls are able to generate identical trees, regardless of intermediate
13       dependency updates.
14
15       This  file  is  intended  to be committed into source repositories, and
16       serves various purposes:
17
18       •   Describe a single representation of a  dependency  tree  such  that
19           teammates,  deployments,  and continuous integration are guaranteed
20           to install exactly the same dependencies.
21
22       •   Provide a facility for users to "time-travel" to previous states of
23           node_modules without having to commit the directory itself.
24
25       •   Facilitate  greater  visibility  of  tree  changes through readable
26           source control diffs.
27
28       •   Optimize the installation process by allowing npm to skip  repeated
29           metadata resolutions for previously-installed packages.
30
31       •   As  of  npm v7, lockfiles include enough information to gain a com‐
32           plete picture of the package tree, reducing the need to read  pack‐
33           age.json  files,  and allowing for significant performance improve‐
34           ments.
35
36
37   package-lock.json vs npm-shrinkwrap.json
38       Both of these files have the same format, and perform similar functions
39       in the root of a project.
40
41       The  difference  is  that package-lock.json cannot be published, and it
42       will be ignored if found in any place other than the root project.
43
44       In contrast, npm-shrinkwrap.json ⟨/configuring-npm/npm-shrinkwrap-json⟩
45       allows  publication, and defines the dependency tree from the point en‐
46       countered. This is not recommended unless deploying a CLI tool or  oth‐
47       erwise using the publication process for producing production packages.
48
49       If  both  package-lock.json  and npm-shrinkwrap.json are present in the
50       root of a project, npm-shrinkwrap.json will take precedence  and  pack‐
51       age-lock.json will be ignored.
52
53   Hidden Lockfiles
54       In order to avoid processing the node_modules folder repeatedly, npm as
55       of v7  uses  a  "hidden"  lockfile  present  in  node_modules/.package-
56       lock.json.  This  contains  information  about the tree, and is used in
57       lieu of reading the entire node_modules  hierarchy  provided  that  the
58       following conditions are met:
59
60       •   All package folders it references exist in the node_modules hierar‐
61           chy.
62
63       •   No package folders exist in the node_modules hierarchy that are not
64           listed in the lockfile.
65
66       •   The  modified  time of the file is at least as recent as all of the
67           package folders it references.
68
69
70       That is, the hidden lockfile will only be relevant if it was created as
71       part  of the most recent update to the package tree. If another CLI mu‐
72       tates the tree in any way, this will be detected, and the hidden  lock‐
73       file will be ignored.
74
75       Note  that  it is possible to manually change the contents of a package
76       in such a way that the modified time of the  package  folder  is  unaf‐
77       fected.  For example, if you add a file to node_modules/foo/lib/bar.js,
78       then the modified  time  on  node_modules/foo  will  not  reflect  this
79       change. If you are manually editing files in node_modules, it is gener‐
80       ally best to delete the file at node_modules/.package-lock.json.
81
82       As the hidden lockfile is ignored by older npm versions,  it  does  not
83       contain  the  backwards  compatibility  affordances present in "normal"
84       lockfiles. That is, it is lockfileVersion: 3, rather than  lockfileVer‐
85       sion: 2.
86
87   Handling Old Lockfiles
88       When  npm  detects  a lockfile from npm v6 or before during the package
89       installation process, it is automatically updated to fetch missing  in‐
90       formation  from  either  the node_modules tree or (in the case of empty
91       node_modules trees or very old lockfile formats) the npm registry.
92
93   File Format
94   name
95       The name of the package this is a package-lock  for.  This  will  match
96       what's in package.json.
97
98   version
99       The  version of the package this is a package-lock for. This will match
100       what's in package.json.
101
102   lockfileVersion
103       An integer version, starting at 1 with the version number of this docu‐
104       ment whose semantics were used when generating this package-lock.json.
105
106       Note  that the file format changed significantly in npm v7 to track in‐
107       formation that would have otherwise required looking in node_modules or
108       the  npm  registry.  Lockfiles  generated  by npm v7 will contain lock‐
109       fileVersion: 2.
110
111       •   No version provided: an "ancient" shrinkwrap file from a version of
112           npm prior to npm v5.
113
1141: The lockfile version used by npm v5 and v6.
115
1162: The lockfile version used by npm v7 and v8. Backwards compatible
117           to v1 lockfiles.
118
1193: The lockfile version used by npm v9 and above. Backwards compat‐
120           ible to npm v7.
121
122
123       npm  will always attempt to get whatever data it can out of a lockfile,
124       even if it is not a version that it was designed to support.
125
126   packages
127       This is an object that maps package locations to an  object  containing
128       the information about that package.
129
130       The  root  project  is typically listed with a key of "", and all other
131       packages are listed with their relative paths  from  the  root  project
132       folder.
133
134       Package descriptors have the following fields:
135
136       •   version: The version found in package.json
137
138       •   resolved:  The  place where the package was actually resolved from.
139           In the case of packages fetched from the registry, this will  be  a
140           url to a tarball. In the case of git dependencies, this will be the
141           full git url with commit sha. In the  case  of  link  dependencies,
142           this will be the location of the link target. registry.npmjs.org is
143           a magic value meaning "the currently configured registry".
144
145       •   integrity:  A  sha512  or  sha1  Standard   Subresource   Integrity
146           https://w3c.github.io/webappsec/specs/subresourceintegrity/
147           string for the artifact that was unpacked in this location.
148
149       •   link: A flag to indicate that this is a symbolic link. If  this  is
150           present,  no other fields are specified, since the link target will
151           also be included in the lockfile.
152
153       •   dev, optional, devOptional: If the package is strictly part of  the
154           devDependencies tree, then dev will be true. If it is strictly part
155           of the optionalDependencies tree, then optional will be set. If  it
156           is  both  a  dev dependency and an optional dependency of a non-dev
157           dependency, then devOptional will be set. (An  optional  dependency
158           of a dev dependency will have both dev and optional set.)
159
160       •   inBundle:  A  flag to indicate that the package is a bundled depen‐
161           dency.
162
163       •   hasInstallScript: A flag to indicate that the package has a  prein‐
164           stall, install, or postinstall script.
165
166       •   hasShrinkwrap:  A  flag  to  indicate  that the package has an npm-
167           shrinkwrap.json file.
168
169       •   bin, license, engines, dependencies,  optionalDependencies:  fields
170           from package.json
171
172
173   dependencies
174       Legacy data for supporting versions of npm that use lockfileVersion: 1.
175       This is a mapping of package names to dependency objects.  Because  the
176       object  structure  is strictly hierarchical, symbolic link dependencies
177       are somewhat challenging to represent in some cases.
178
179       npm v7 ignores this section entirely if a packages section is  present,
180       but  does  keep it up to date in order to support switching between npm
181       v6 and npm v7.
182
183       Dependency objects have the following fields:
184
185       •   version: a specifier that varies depending on  the  nature  of  the
186           package, and is usable in fetching a new copy of it.
187
188           •   bundled  dependencies:  Regardless of source, this is a version
189               number that is purely for informational purposes.
190
191           •   registry sources: This is a version number. (eg, 1.2.3)
192
193           •   git sources: This is a git specifier with resolved  committish.
194               (eg,                                          git+https://exam
195               ple.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e)
196
197           •   http tarball sources: This is the  URL  of  the  tarball.  (eg,
198               https://example.com/example-1.3.0.tgz)
199
200           •   local tarball sources: This is the file URL of the tarball. (eg
201               file:///opt/storage/example-1.3.0.tgz)
202
203           •   local link sources: This is the  file  URL  of  the  link.  (eg
204               file:libs/our-module)
205
206
207       •   integrity:   A   sha512  or  sha1  Standard  Subresource  Integrity
208           https://w3c.github.io/webappsec/specs/subresourceintegrity/
209           string for the artifact that was unpacked in this location. For git
210           dependencies, this is the commit sha.
211
212       •   resolved: For registry sources this is path of the tarball relative
213           to the registry URL. If the tarball URL isn't on the same server as
214           the registry URL then this is a complete URL. registry.npmjs.org is
215           a magic value meaning "the currently configured registry".
216
217       •   bundled:  If  true,  this is the bundled dependency and will be in‐
218           stalled by the parent module. When installing, this module will  be
219           extracted  from the parent module during the extract phase, not in‐
220           stalled as a separate dependency.
221
222       •   dev: If true then this dependency is either  a  development  depen‐
223           dency  ONLY  of  the top level module or a transitive dependency of
224           one. This is false for dependencies that are both a development de‐
225           pendency  of the top level and a transitive dependency of a non-de‐
226           velopment dependency of the top level.
227
228       •   optional: If true then this dependency is either an optional depen‐
229           dency  ONLY  of  the top level module or a transitive dependency of
230           one. This is false for dependencies that are both an  optional  de‐
231           pendency  of the top level and a transitive dependency of a non-op‐
232           tional dependency of the top level.
233
234       •   requires: This is a mapping of module name to version.  This  is  a
235           list  of  everything  this  module requires, regardless of where it
236           will be installed. The version should  match  via  normal  matching
237           rules  a dependency either in our dependencies or in a level higher
238           than us.
239
240       •   dependencies: The dependencies of this dependency,  exactly  as  at
241           the top level.
242
243
244   See also
245       •   npm help shrinkwrap
246
247npm-shrinkwrap.json ⟨/configuring-npm/npm-shrinkwrap-json⟩
248
249package.json ⟨/configuring-npm/package-json⟩
250
251       •   npm help install
252
253
254
255                                 November 2023            PACKAGE-LOCK.JSON(5)
Impressum