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