title: How to resolve dependency hell in NPM with peerDependencies
body: <h1>Setup:</h1>
  
  <p>Given the following points</p>
  
  <ul>
  <li><em>my_library</em> makes extensive runtime use of <strong>jquery</strong>.</li>
  <li>in <em>my_library</em> the <strong>jquery</strong> required via <strong>npm</strong> is <code>^3.3.1</code> by default (because of security fixes in it). However it is compatible also with <strong>jquery >=2.2.0</strong> (but is not specified in <code>package.json</code>, yet)</li>
  <li>the <em>my_library</em> is used in a <em>custom_project</em> via <strong>npm</strong>.</li>
  <li>the <em>custom_project</em> requires also <em>outer_library</em>, that is using different &amp; conflicting <strong>jquery</strong> versions (e.g. let's say <strong>jquery 1.7.3</strong>).</li>
  <li>the <em>custom_project_2</em> instead just requires <em>my_library</em> in <code>dependencies</code>.</li>
  </ul>
  
  <h1>Problems:</h1>
  
  <ul>
  <li>installing <em>custom_project</em> will provoke duplicate dependencies, messing up <strong>jquery</strong> for one of the two libraries.</li>
  <li>the <strong>jquery</strong> version in <em>my_library</em> <code>dependencies</code> specifies a suggested version (in order to avoid critical vulnerabilities) but doesn't say anything about which <strong>jquery</strong> minimum version is compatible with <em>my_library</em></li>
  </ul>
  
  <h1>Eventual solution:</h1>
  
  <p>To avoid <strong>jquery</strong> dependency duplication (1.7.3 for <em>outer_library</em> and 3.3.1 for <em>my_library</em>) I could move my <strong>jquery ^3.3.1</strong> from <code>dependencies</code> to <code>devDependencies</code>, so I'll get the <strong>3.3.1</strong> on development while it won't be installed on production (<code>npm install --only=prod</code>) and just <strong>jquery 1.7.3</strong> will be installed.</p>
  
  <p>But this:</p>
  
  <ul>
  <li>doesn't guarantees that <em>my_library</em> will get a compatible <strong>jquery</strong> version, so <em>my_library</em> could easily break.</li>
  <li><ul>
  <li>adding <code>jquery@&gt;=2.2.0</code> inside <em>my_library</em> <code>peerDependencies</code> will at least raise a <em>WARN</em> asking to resolve the conflict manually installing a specific version in <em>custom_project</em> (even though probably it can't be solved).</li>
  </ul></li>
  <li><p>feels wrong to me since <strong>jquery</strong> is a runtime <code>dependency</code> and shouldn't go into <code>devDependencies</code> (with unit-testing tools, etc.). In fact <strong>jquery</strong> won't be installed in the <em>custom_project_2</em>, when installing on <em>production</em> (so <em>my_library</em> will break)</p></li>
  </ul>
  
  <h1>Questions</h1>
  
  <ol>
  <li><p>How can I manage to satisfy both use cases of dependency by <em>my_library</em>?</p></li>
  <li><p>(A) In case the <em>outer_library</em> would require a <strong>jquery</strong> compatible with my <code>peerDependencies</code> definition (<code>&gt;=2.0.0</code>), would I STILL need to install <strong>jquery</strong> manually? Or <strong>npm</strong> will resolve a common version?</p></li>
  <li><p>(B) Are there cases where <code>peerDependencies</code> doesn't complain and doesn't require to install anything manually? (as long as semvers are honoured?)</p></li>
  <li><p>(A) Does it make sense to put a dependency like <strong>jquery</strong> (high probability of conflicts) <strong>either</strong> inside <code>peerDependencies</code> (with an as loose as possible <em>semver</em>) <strong>and</strong> inside <code>dependencies</code> with the recommended version?</p></li>
  <li><p>(B) Would that work correctly in every setup <strong>and</strong> with <em>NPM</em> version <code>&lt;3</code> (peerDependencies automatically installed) and <code>&gt;=3</code> (manual installation needed)?</p></li>
  </ol>
  
  <p>Appreciated if you can answer even to a part of the questions </p>