<h1 dir="auto">Feature request</h1>
<h2 dir="auto">Is your feature request related to a problem? Please describe.</h2>
<p dir="auto">The current Webpack chunking strategy in Next.js is based around a ratio-based heuristic for including modules in a single "commons" chunk. Because there is very little granularity, a lot of code is either downloaded unnecessarily (because the commons chunk includes a lot of code that's not actually required for a particular route) or duplicated across multiple page bundles (because it was included in less than half of all pages).</p>
<p dir="auto">Because these two problems are in opposition, simply adjusting the ratio will always make one better and one worse.</p>
<h2 dir="auto">Describe the solution you'd like</h2>
<p dir="auto">I suggest adopting a SplitChunksPlugin configuration such as the following:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="cacheGroups: {
    default: false,
    vendors: false,
    framework: {
        name: 'framework',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/,
        priority: 40
    },
    lib: {
        test(module) {
            return module.size() &gt; 160000
        },
        name(module) {
            return /node_modules\/(.*)/.exec(module.identifier())[1]
                .replace(/\/|\\/g, &quot;_&quot;)
        },
        priority: 30,
        minChunks: 1,
        reuseExistingChunk: true
    },
    commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages,
        priority: 20
    },
    shared: {
	name: false,
        priority: 10,
        minChunks: 2,
        reuseExistingChunk: true
    }               
},
maxInitialRequests: 20"><pre class="notranslate"><code class="notranslate">cacheGroups: {
    default: false,
    vendors: false,
    framework: {
        name: 'framework',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/,
        priority: 40
    },
    lib: {
        test(module) {
            return module.size() &gt; 160000
        },
        name(module) {
            return /node_modules\/(.*)/.exec(module.identifier())[1]
                .replace(/\/|\\/g, "_")
        },
        priority: 30,
        minChunks: 1,
        reuseExistingChunk: true
    },
    commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages,
        priority: 20
    },
    shared: {
	name: false,
        priority: 10,
        minChunks: 2,
        reuseExistingChunk: true
    }               
},
maxInitialRequests: 20
</code></pre></div>
<p dir="auto">That configuration was designed with these considerations:</p>
<h3 dir="auto">Greater granularity</h3>
<p dir="auto">The problems with the current chunking strategy arise from the low granularity of the page-chunk/commons-chunk paradigm. We can easily reduce code duplication by allowing SplitChunksPlugin to create more chunks. In the case of the library shared across 5 entry points, SplitChunksPlugin could simply create a chunk that only contains code shared across those 5 libraries.</p>
<p dir="auto">Note that SplitChunksPlugin has configuration options to prevent runaway granularity, such as a situation where every module ends up in its own chunk, and the user has to download 100 chunks just to render a route. In particular, in the config above, I'm using the maxInitialRequests option to prevent the number of bundles from skyrocketing.</p>
<h3 dir="auto">Cache efficiency</h3>
<p dir="auto">It should be a priority to ensure that shared modules get chunked in a way that causes minimum unnecessary cache invalidation. For an example of this principle, consider an application with 20 entry point chunks. Chunk A and Chunk B both depend on a large library and several small modules. The default SplitChunksPlugin behavior would create a single shared chunk for the intersection of Chunk A and Chunk B, containing the library and modules.</p>
<p dir="auto">However, in this scenario, all of the following would cache-invalidate the entire chunk, including the large library:</p>
<ol dir="auto">
<li>Adding a new module depended on by A and B exclusively (adds module to the chunk)</li>
<li>Adding a new dependency from a different entry point to one of the modules or the library (module moves out of the chunk)</li>
<li>Any change to any of the small modules shared between A and B.</li>
</ol>
<p dir="auto">For a sufficiently large library, it makes sense to bundle it all by itself to avoid potential cache invalidations, and the code sample above does exactly that.</p>
<h3 dir="auto">A framework chunk</h3>
<p dir="auto">Some modules will be required for every entry point, because they are functionally part of the framework itself, such as React and React-dom. These chunks should be put into a framework chunk, which should be independent from any code introduced by the application developers--even if that code is depended on by 100% of entry points. This is because the frameworks libraries tend to be fairly large, and we know that they generally will not change except when the app developers update the version of Next.js itself. By isolating the framework code we ensure that it will not be cache-invalidated by irrelevant changes made to application code.</p>
<h2 dir="auto">Describe alternatives you've considered</h2>
<p dir="auto">I've considered smaller values for maxInitialRequests, but for Next.js applications with a very large number of pages (100+) that can cause a size regression. At 20 that issue goes away. I believe that even at maxInitialRequests 20, the majority of NextJS sites will still have initial requests in the single digits. It's also not clear to me that even if it the initial requests went up to 20 that it would cause any performance degradation for users on modern browsers.</p>
<h2 dir="auto">Additional context</h2>
<p dir="auto">In my initial testing on some small and medium sized Next.js apps, this enhanced webpack configuration reduces KB of total JS required for initial page load by as much as <strong>20%</strong>. For particularly-poorly optimized sites, I think the improvement could be even greater.</p>
<h1 dir="auto">Bug report</h1>
<p dir="auto">duplicate component, weird render.<br>
packages:<br>
<code class="notranslate">"babel-polyfill": "^6.26.0", "metamask-logo": "^2.1.4", "next": "^6.0.3", "react": "^16.4.1", "react-countdown-now": "^1.3.0", "react-dom": "^16.4.1", "semantic-ui-css": "^2.3.2", "semantic-ui-react": "^0.81.2", "solc": "^0.4.24", "truffle-contract": "^3.0.6", "truffle-hdwallet-provider": "^0.0.5", "web3": "^1.0.0-beta.34"</code></p>
<h2 dir="auto">Describe the bug</h2>
<p dir="auto">Duplicate component, weird render.<br>
While i add the components in the index.js page, i see duplicated renders of the components</p>
<p dir="auto">My index.js looks like:<br>
<code class="notranslate">export default () =&gt; { return ( &lt;span&gt; &lt;HeadPage /&gt; &lt;HomeFirstSection /&gt; &lt;HomeWhatIsThis /&gt; &lt;/span&gt; ); };</code><br>
HomeWhatIsThis component renders twice:<br>
<code class="notranslate">import React, { Component } from 'react'; import { Grid, Segment, Image } from 'semantic-ui-react'; class HomeWhatIsThis extends Component { render() { return( html ); } } export default HomeWhatIsThis;</code></p>
<h2 dir="auto">System information</h2>
<ul dir="auto">
<li>OS: macOS</li>
<li>Browser (if applies): chrome, safari, brave - the same pb, indicating is a server side render issue.</li>
<li>Version of Next.js: 6.0.3</li>
</ul>