<h3 dir="auto">What:</h3>
<p dir="auto">When a user specifies multiple chunks as output report a numeric statistic about the amount of bundle duplication across chunks.</p>
<p dir="auto">For example:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="*chunks*
  * 124124.js ~ 10% duplication
  * 213412.js ~ 50% duplication
  * 545634.js ~ 25% duplication

run build -- -bundle-stats-viz to explore duplication"><pre class="notranslate"><code class="notranslate">*chunks*
  * 124124.js ~ 10% duplication
  * 213412.js ~ 50% duplication
  * 545634.js ~ 25% duplication

run build -- -bundle-stats-viz to explore duplication
</code></pre></div>
<h3 dir="auto">Why:</h3>
<p dir="auto">When multiple chunks are output the volume of duplication is non-obvious and actually quite hard to know without using external tools.  (see this post to understand the full implications <a href="http://www.susielu.com/data-viz/bundle-buddy" rel="nofollow">http://www.susielu.com/data-viz/bundle-buddy</a>) Since this "duplication" number is critical to ensuring good bundle chunk settings these values should be reported to the user so that they can better tweak their splitting process to minimize duplicaiton.</p>
<p dir="auto">Inspired by the work here<br>
<a href="https://github.com/samccone/bundle-buddy">https://github.com/samccone/bundle-buddy</a></p>
<h3 dir="auto">How:</h3>
<p dir="auto">The current approach used in bundle buddy uses source maps to build up a mapping of source lines to final bundle outputs, reusing this code should be possible if we keep using source maps as the backing data store.</p>
<p dir="auto">Thanks.</p>
<h2 dir="auto">Feature request</h2>





<p dir="auto"><strong>What is the expected behavior?</strong><br>
There should be a function that allow entrypoint to be changed after the compiler is created, but before compilation has started.</p>
<p dir="auto"><strong>What is motivation or use case for adding/changing the behavior?</strong><br>
See <a href="https://github.com/webpack-contrib/webpack-serve/issues/156#issuecomment-393177870" data-hovercard-type="issue" data-hovercard-url="/webpack-contrib/webpack-serve/issues/156/hovercard">this issue in webpack-serve</a>. In short, iterating entrypoints from a compiler, process, and calling <code class="notranslate">compiler.hooks.entryOption</code> with the new value does not works well with <code class="notranslate">runtimeChunk: single</code> as the old entrypoint plugin will still exists.</p>
<p dir="auto"><strong>How should this be implemented in your opinion?</strong></p>
<ul dir="auto">
<li>Plan A: Creating a registry of active entrypoint plugin instances (MultiEntryPlugin/SingleEntryPlugin/DynamicEntryPlugin), then when EntryOptionPlugin trigger again:
<ul dir="auto">
<li>A: Ask the old instance of the same entrypoint to deregister.</li>
<li>B: Recreate all instances. This allow entrypoints to be removed, but caller now has to send list of ALL entrypoints which is a breaking change.</li>
</ul>
</li>
<li>Plan B: Investigate in why RuntimeChunkPlugin does not work with duplicated entrypoints. This might resolve this issue, but could run into more issues in the future.</li>
</ul>
<p dir="auto"><strong>Are you willing to work on this yourself?</strong><br>
If I have some guideline.</p>