Why do you want to disable code splitting?
@Atinux My client need all js/css in a single file to integrate in their repo. It's not the best solution but the Nuxt app is a part of a larger app.
I also need this option. Suitable for small applications and in my case will be used on mobile devices with bad internet connection, so I want to load all js/css at start, not when user clicking some link and waiting about 5 seconds to load appropriate page files.
@vinjegaard TypeError exists in webpack 3.11. You can downgrade to 3.10 and error will disappear. But it will generate not 1 file, but 3 - manifest, common, app.
This'll be fun with webpack 4
The minimum maxChunks which doesn't crash is 4. This generates manifest.js, common.js, apps.js and layouts/default.js (which also includes all other pages' scripts).
Unfortunately, maxChunks: 4 also breaks extracting inline CSS from components. Instead of going into common.css, component styles are injected inline into the resulting HTML. Disappointing. Now I need to move all my component styles back to separate CSS files.
@pi0 could you take a quick look at it please? He is the Webpack expert in the core team :)
With webpack 4 we removed CommonChunks plugin. Code splitting can be disabled using performance.* options. Will keep you informed.
Interestingly, I bisected the problematic change to webpack 3.11.0.
Adding this to package.json:
"resolutions": {
"webpack": "3.10.0"
}
and re-running yarn fixes the issue.
It apparently has nothing to do with recent changes in Nuxt itself. Nuxt 1.0.0-rc11 with webpack 3.11 crashes the same way, and Nuxt 1.3.0 with webpack 3.10.0 doesn't crash.
Should we close this or track the "disable code splitting" feature with webpack 4 here?
@qm3ster Disabling code splitting for page chunks can be considered as a feature independent of webpack version.
But I don't think we really need this. Using prefetch/preload (which is enabled by default) more chunks will be loaded in the background and it is a better practice than disabling it at all even for offline-first mobile applications because loading everything at initial load is much more CPU consuming.
/cc @Atinux @clarkdo
Yeah, loading upfront and not splitting are very different approaches, and none of the usecases in this thread seem like they demand it.
Will be available with #3060.
Available when using nuxt-edge. It's based on webpack-4s optimization now. See the docs
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.