<h2 dir="auto">Request</h2>
<p dir="auto">I want to request an option to omit runtime dependencies when auditing dependencies using <code class="notranslate">npm audit</code>. I would expect it to work identically to <code class="notranslate">--omit dev</code>, <code class="notranslate">--omit optional</code>, and <code class="notranslate">--omit peer</code> but instead for dependencies required through the <code class="notranslate">"dependencies"</code> field of <code class="notranslate">package.json</code>.</p>
<h2 dir="auto">Reasoning</h2>
<p dir="auto">This may sound like a surprising request, but my reasoning is as follows:</p>
<p dir="auto">As a "library" - i.e. a package of code that is never run on it's own but only as part of a larger application, ex. <a href="https://www.npmjs.com/package/lodash" rel="nofollow">lodash</a> - maintainer I don't necessarily need to worry about vulnerabilities in runtime dependencies. In particular, say my library depends on some dependency and supports <code class="notranslate">^2.0.0</code> of that dependency. For most classes of vulnerabilities<sup><a href="#user-content-fn-1-d924e899ee6d5757ef0865035f2ae7e0" id="user-content-fnref-1-d924e899ee6d5757ef0865035f2ae7e0" data-footnote-ref="" aria-describedby="footnote-label">1</a></sup>, if there's a vulnerability in <code class="notranslate">2.1.0</code> of this dependency that is not relevant to me as a library maintainer. The library itself will never run the vulnerable code in an interesting setting and users of my library can safely upgrade to <code class="notranslate">2.1.1</code> of this dependency whenever they want.</p>
<p dir="auto">Now, as a library maintainer I could have <code class="notranslate">^2.0.0</code> in my manifest and depend on <code class="notranslate">2.1.1</code> in my lockfile. However, as a library maintainer I'd (personally) want to depend on exactly the minimum version that is support (<code class="notranslate">2.0.0</code> in this case) during development to ensure my library stays compatible with that version of the dependency. Additionally, I (personally) consider bumping the version of a runtime dependency, even within the <code class="notranslate">^2.0.0</code> range, a breaking change; <strong>EDIT</strong>: <a href="https://github.com/npm/cli/issues/5726#issuecomment-1284458338" data-hovercard-type="issue" data-hovercard-url="/npm/cli/issues/5726/hovercard">this statement is incorrect</a>.</p>
<p dir="auto">Considering all that, I think it should be possible to omit runtime dependencies from the <code class="notranslate">npm audit</code> results - because for library maintainers they may not be directly relevant.</p>
<p dir="auto">If there's anything incorrect about my assessment, please do point it out 🙂</p>
<section data-footnotes="" class="footnotes"><h2 id="footnote-label" class="sr-only" dir="auto">Footnotes</h2>
<ol dir="auto">
<li id="user-content-fn-1-d924e899ee6d5757ef0865035f2ae7e0">
<p dir="auto">Using a broad definition of "vulnerabilities" here, in line with what <code class="notranslate">npm audit</code> might report on. Things like malware in a dependency would constitute a problem even in the scenario I'm describing. <a href="#user-content-fnref-1-d924e899ee6d5757ef0865035f2ae7e0" data-footnote-backref="" aria-label="Back to reference 1" class="data-footnote-backref"><g-emoji class="g-emoji" alias="leftwards_arrow_with_hook" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/21a9.png">↩</g-emoji></a></p>
</li>
</ol>
</section>
<p dir="auto">16696 silly extract google-closure-compiler-java@20190415.0.0 extracted to /data/data/com.termux/files/home/craze/fir&gt;16697 http fetch GET 200 <a href="https://registry.npmjs.org/firebase/-/firebase-7.5.2.tgz" rel="nofollow">https://registry.npmjs.org/firebase/-/firebase-7.5.2.tgz</a> 336498ms                            16698 silly extract firebase@7.5.2 extracted to /data/data/com.termux/files/home/craze/firebaseui-web/node_modules/.s&gt;16699 http fetch GET 200 <a href="https://registry.npmjs.org/google-closure-compiler-linux/-/google-closure-compiler-linux-201%3E16700" rel="nofollow">https://registry.npmjs.org/google-closure-compiler-linux/-/google-closure-compiler-linux-201&gt;16700</a> silly extract google-closure-compiler-linux@20190415.0.0 extracted to /data/data/com.termux/files/home/craze/fi&gt;16701 http fetch GET 200 <a href="https://registry.npmjs.org/google-closure-library/-/google-closure-library-20190415.0.0.tgz" rel="nofollow">https://registry.npmjs.org/google-closure-library/-/google-closure-library-20190415.0.0.tgz</a> 316702 silly extract google-closure-library@20190415.0.0 extracted to /data/data/com.termux/files/home/craze/firebaseu&gt;16703 timing npm Completed in 397469ms                                                                                16704 error cb() never called!                                                                                        16705 error This is an error with npm itself. Please report this error at:                                            16706 error <a href="https://npm.community" rel="nofollow">https://npm.community</a></p>