Simple email application for Android. Original source code: https://framagit.org/dystopia-project/simple-email
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

155 lines
11 KiB

  1. <!doctype html>
  2. <html>
  3. <title>npm-package-locks</title>
  4. <meta charset="utf-8">
  5. <link rel="stylesheet" type="text/css" href="../../static/style.css">
  6. <link rel="canonical" href="https://www.npmjs.org/doc/files/npm-package-locks.html">
  7. <script async=true src="../../static/toc.js"></script>
  8. <body>
  9. <div id="wrapper">
  10. <h1><a href="../files/npm-package-locks.html">npm-package-locks</a></h1> <p>An explanation of npm lockfiles</p>
  11. <h2 id="description">DESCRIPTION</h2>
  12. <p>Conceptually, the &quot;input&quot; to <a href="../cli/npm-install.html">npm-install(1)</a> is a <a href="../files/package.json.html">package.json(5)</a>, while its
  13. &quot;output&quot; is a fully-formed <code>node_modules</code> tree: a representation of the
  14. dependencies you declared. In an ideal world, npm would work like a pure
  15. function: the same <code>package.json</code> should produce the exact same <code>node_modules</code>
  16. tree, any time. In some cases, this is indeed true. But in many others, npm is
  17. unable to do this. There are multiple reasons for this:</p>
  18. <ul>
  19. <li><p>different versions of npm (or other package managers) may have been used to install a package, each using slightly different installation algorithms.</p>
  20. </li>
  21. <li><p>a new version of a direct semver-range package may have been published since the last time your packages were installed, and thus a newer version will be used.</p>
  22. </li>
  23. <li><p>A dependency of one of your dependencies may have published a new version, which will update even if you used pinned dependency specifiers (<code>1.2.3</code> instead of <code>^1.2.3</code>)</p>
  24. </li>
  25. <li><p>The registry you installed from is no longer available, or allows mutation of versions (unlike the primary npm registry), and a different version of a package exists under the same version number now.</p>
  26. </li>
  27. </ul>
  28. <p>As an example, consider package A:</p>
  29. <pre><code>{
  30. &quot;name&quot;: &quot;A&quot;,
  31. &quot;version&quot;: &quot;0.1.0&quot;,
  32. &quot;dependencies&quot;: {
  33. &quot;B&quot;: &quot;&lt;0.1.0&quot;
  34. }
  35. }</code></pre><p>package B:</p>
  36. <pre><code>{
  37. &quot;name&quot;: &quot;B&quot;,
  38. &quot;version&quot;: &quot;0.0.1&quot;,
  39. &quot;dependencies&quot;: {
  40. &quot;C&quot;: &quot;&lt;0.1.0&quot;
  41. }
  42. }</code></pre><p>and package C:</p>
  43. <pre><code>{
  44. &quot;name&quot;: &quot;C&quot;,
  45. &quot;version&quot;: &quot;0.0.1&quot;
  46. }</code></pre><p>If these are the only versions of A, B, and C available in the
  47. registry, then a normal <code>npm install A</code> will install:</p>
  48. <pre><code>A@0.1.0
  49. `-- B@0.0.1
  50. `-- C@0.0.1</code></pre><p>However, if <a href="mailto:B@0.0.2">B@0.0.2</a> is published, then a fresh <code>npm install A</code> will
  51. install:</p>
  52. <pre><code>A@0.1.0
  53. `-- B@0.0.2
  54. `-- C@0.0.1</code></pre><p>assuming the new version did not modify B&#39;s dependencies. Of course,
  55. the new version of B could include a new version of C and any number
  56. of new dependencies. If such changes are undesirable, the author of A
  57. could specify a dependency on <a href="mailto:B@0.0.1">B@0.0.1</a>. However, if A&#39;s author and B&#39;s
  58. author are not the same person, there&#39;s no way for A&#39;s author to say
  59. that he or she does not want to pull in newly published versions of C
  60. when B hasn&#39;t changed at all.</p>
  61. <p>To prevent this potential issue, npm uses <a href="../files/package-lock.json.html">package-lock.json(5)</a> or, if present,
  62. n<a href="../files/pm-shrinkwrap.json.html">pm-shrinkwrap.json(5)</a>. These files are called package locks, or lockfiles.</p>
  63. <p>Whenever you run <code>npm install</code>, npm generates or updates your package lock,
  64. which will look something like this:</p>
  65. <pre><code>{
  66. &quot;name&quot;: &quot;A&quot;,
  67. &quot;version&quot;: &quot;0.1.0&quot;,
  68. ...metadata fields...
  69. &quot;dependencies&quot;: {
  70. &quot;B&quot;: {
  71. &quot;version&quot;: &quot;0.0.1&quot;,
  72. &quot;resolved&quot;: &quot;https://registry.npmjs.org/B/-/B-0.0.1.tgz&quot;,
  73. &quot;integrity&quot;: &quot;sha512-DeAdb33F+&quot;
  74. &quot;dependencies&quot;: {
  75. &quot;C&quot;: {
  76. &quot;version&quot;: &quot;git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4&quot;
  77. }
  78. }
  79. }
  80. }
  81. }</code></pre><p>This file describes an <em>exact</em>, and more importantly <em>reproducible</em>
  82. <code>node_modules</code> tree. Once it&#39;s present, any future installation will base its
  83. work off this file, instead of recalculating dependency versions off
  84. p<a href="../files/ackage.json.html">ackage.json(5)</a>.</p>
  85. <p>The presence of a package lock changes the installation behavior such that:</p>
  86. <ol>
  87. <li><p>The module tree described by the package lock is reproduced. This means
  88. reproducing the structure described in the file, using the specific files
  89. referenced in &quot;resolved&quot; if available, falling back to normal package resolution
  90. using &quot;version&quot; if one isn&#39;t.</p>
  91. </li>
  92. <li><p>The tree is walked and any missing dependencies are installed in the usual
  93. fashion.</p>
  94. </li>
  95. </ol>
  96. <p>If <code>preshrinkwrap</code>, <code>shrinkwrap</code> or <code>postshrinkwrap</code> are in the <code>scripts</code>
  97. property of the <code>package.json</code>, they will be executed in order. <code>preshrinkwrap</code>
  98. and <code>shrinkwrap</code> are executed before the shrinkwrap, <code>postshrinkwrap</code> is
  99. executed afterwards. These scripts run for both <code>package-lock.json</code> and
  100. <code>npm-shrinkwrap.json</code>. For example to run some postprocessing on the generated
  101. file:</p>
  102. <pre><code>&quot;scripts&quot;: {
  103. &quot;postshrinkwrap&quot;: &quot;json -I -e \&quot;this.myMetadata = $MY_APP_METADATA\&quot;&quot;
  104. }</code></pre><h3 id="using-locked-packages">Using locked packages</h3>
  105. <p>Using a locked package is no different than using any package without a package
  106. lock: any commands that update <code>node_modules</code> and/or <code>package.json</code>&#39;s
  107. dependencies will automatically sync the existing lockfile. This includes <code>npm
  108. install</code>, <code>npm rm</code>, <code>npm update</code>, etc. To prevent this update from happening,
  109. you can use the <code>--no-save</code> option to prevent saving altogether, or
  110. <code>--no-shrinkwrap</code> to allow <code>package.json</code> to be updated while leaving
  111. <code>package-lock.json</code> or <code>npm-shrinkwrap.json</code> intact.</p>
  112. <p>It is highly recommended you commit the generated package lock to source
  113. control: this will allow anyone else on your team, your deployments, your
  114. CI/continuous integration, and anyone else who runs <code>npm install</code> in your
  115. package source to get the exact same dependency tree that you were developing
  116. on. Additionally, the diffs from these changes are human-readable and will
  117. inform you of any changes npm has made to your <code>node_modules</code>, so you can notice
  118. if any transitive dependencies were updated, hoisted, etc.</p>
  119. <h3 id="resolving-lockfile-conflicts">Resolving lockfile conflicts</h3>
  120. <p>Occasionally, two separate npm install will create package locks that cause
  121. merge conflicts in source control systems. As of <a href="mailto:%60npm@5.7.0">`npm@5.7.0</a><code>, these conflicts
  122. can be resolved by manually fixing any</code>package.json<code>conflicts, and then
  123. running</code>npm install [--package-lock-only]<code>again. npm will automatically
  124. resolve any conflicts for you and write a merged package lock that includes all
  125. the dependencies from both branches in a reasonable tree. If</code>--package-lock-only<code>is provided, it will do this without also modifying your
  126. local</code>node_modules/`.</p>
  127. <p>To make this process seamless on git, consider installing
  128. <a href="https://npm.im/npm-merge-driver"><code>npm-merge-driver</code></a>, which will teach git how
  129. to do this itself without any user interaction. In short: <code>$ npx
  130. npm-merge-driver install -g</code> will let you do this, and even works with
  131. <a href="mailto:pre-%60npm@5.7.0">pre-`npm@5.7.0</a><code>versions of npm 5, albeit a bit more noisily. Note that if</code>package.json<code>itself conflicts, you will have to resolve that by hand and run</code>npm install` manually, even with the merge driver.</p>
  132. <h2 id="see-also">SEE ALSO</h2>
  133. <ul>
  134. <li><a href="https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527">https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527</a></li>
  135. <li><a href="../files/package.json.html">package.json(5)</a></li>
  136. <li><a href="../files/package-lock.json.html">package-lock.json(5)</a></li>
  137. <li><a href="../files/npm-shrinkwrap.json.html">npm-shrinkwrap.json(5)</a></li>
  138. <li><a href="../cli/npm-shrinkwrap.html">npm-shrinkwrap(1)</a></li>
  139. </ul>
  140. </div>
  141. <table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
  142. <tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18>&nbsp;</td></tr>
  143. <tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)">&nbsp;</td><td style="width:40px;height:10px;background:#fff" colspan=4>&nbsp;</td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4>&nbsp;</td><td style="width:40px;height:10px;background:#fff" colspan=4>&nbsp;</td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)">&nbsp;</td><td colspan=6 style="width:60px;height:10px;background:#fff">&nbsp;</td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4>&nbsp;</td></tr>
  144. <tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3>&nbsp;</td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3>&nbsp;</td><td style="width:10px;height:10px;background:#fff" rowspan=3>&nbsp;</td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2>&nbsp;</td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2>&nbsp;</td><td style="width:10px;height:10px;background:#fff" rowspan=3>&nbsp;</td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2>&nbsp;</td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3>&nbsp;</td><td style="width:10px;height:10px;background:#fff" rowspan=3>&nbsp;</td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3>&nbsp;</td></tr>
  145. <tr><td style="width:10px;height:10px;background:#fff" rowspan=2>&nbsp;</td></tr>
  146. <tr><td style="width:10px;height:10px;background:#fff">&nbsp;</td></tr>
  147. <tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6>&nbsp;</td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)">&nbsp;</td></tr>
  148. <tr><td colspan=5 style="width:50px;height:10px;background:#fff">&nbsp;</td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4>&nbsp;</td><td style="width:90px;height:10px;background:#fff" colspan=9>&nbsp;</td></tr>
  149. </table>
  150. <p id="footer">npm-package-locks &mdash; npm@6.4.1</p>