title: Webpack recompiles unchanged files, slowing build times
body: <p>Relevant <a href="https://github.com/webpack/webpack/issues/1530" rel="noreferrer">webpack/webpack</a> issue.</p>
  
  <p>Using webpack in real projects slows down, in my experience, after you pile on a certain number of components and/or dependencies. I have <a href="https://github.com/tvararu/webpack-test" rel="noreferrer">a test repository</a> that seeks to demonstrate this with the following application:</p>
  
  <ul>
  <li>The entry point is <code>A.js</code>, which requires <code>B.js</code> and <code>C.js</code>.</li>
  <li><code>B.js</code> is tiny and doesn't have a lot of dependencies.</li>
  <li><code>C.js</code> is monolithic and has thousands of requires.</li>
  </ul>
  
  <p>My expectation is that when using <code>webpack-dev-server</code> in the test project, whenever I save <code>B.js</code>, webpack should recognize that <code>C.js</code> and none of its dependencies have been touched. It should compile <code>B.js</code> swiftly (in &lt;10ms), replace it in the cache, and output the compiled <code>A.js</code> using the cached version of <code>C.js</code> from the initial compile.</p>
  
  <p>However, webpack compiles <code>3002</code> hidden modules every time I save <code>B.js</code>, leading to a compile time of <code>960ms</code>. This isn't bad on its own, but spirals out of control if you add some loaders like <code>react-hot</code> and <code>babel</code>.</p>
  
  <p>I do have a solution: on the same test project there is a <code>dll</code> branch. On that branch, you can run <code>webpack --config webpack.dll.config.js</code> to generate two DLLs from <code>B.js</code> and <code>C.js</code> which will then get leveraged when compiling <code>A.js</code>. Afterwards, when using <code>webpack-dev-server</code>, whenever you save <code>B.js</code>, its DLL will get recompiled, <code>A.js</code> will notice that one of its DLLs has updated and it'll just take the old DLL of <code>C.js</code> and the new DLL of <code>B.js</code> and conjoin them together into one quick happy bundle.</p>
  
  <p>I could go further on that branch and do directory reads or dependency graph walks to generate a DLL for every component, an approach that could potentially be applied to every webpack project. That should in theory make compiling as fast as I would like it. But at that point it seems to me like I will have reimplemented (poorly) what the caching layer in webpack should do on its own, so what's going on here?</p>