package-lock-json.5 11 KB

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