Closed atcastle closed 5 years ago
I increased the size limit back to 188, to account for some new conditionals I had to add, now that the build-manifest is blocking in granular chunks mode. These conditionals can be removed if granular chunks graduates to non-experimental, so we should be able to recoup the size increase.
So excited for this 🚀❤️
Hi,
Just wanted to ask, has anyone done any benchmark and see an improvement with this new config? I'd like to explore the same kind of setup for Gatsby, I guess the heuristics make sense for both Next and Gatsby (https://github.com/gatsbyjs/gatsby/issues/16661)
@slorber we are in the process of benchmarking the improvements against https://zeit.co. It will take a few more weeks to get that finished, but we're happy to share. @atcastle can you share the data you have so far?
@stubbornella Hi, any updates?
We tried this feature on our project and discovered some weird problem with css chunks. When loading the page via ssr everything works. When navigating to the page via csr we get following error unexpected token .
I checked and bot the name and content of the css chunks are the same in csr and ssr (_next/static/css/1whVq9IAqZiB1lomB8S8Pbp4uA=.14c83442.chunk.css) but chrome somehow complains about the css file when it is loaded via client side render
@abraxxas we think we cleared up this bug. If you see it in latest can you let @atcastle and I know?
@stubbornella just checked with 9.1.2-canary.7 still getting the same error as described above. Is there anything i can do to provide more information for you?
This PR implements the new Webpack SplitChunksPlugin configuration described in #7631 behind a new experimental flag called "granularChunks".
This also refactors the various SplitChunksPlugin configs out of the main config object, as it was getting unwieldy with the introduction of the large new config. However, without enabling the granularChunks flag, this change should have no effect at all on the build.