Breaking JS entrypoint when extracting all css chunks into 1 file

[octaharon]

Package version: 0.4.0
Node version: 6.8.0

So I've updated to webpack 4 and instantly run into extract-text-webpack-plugin incompatibility, and guys on stackoverflow insisted on switching in favor of this module. My use case is almost exactly as described in documentation with the difference being that there's sass-loader in the end of chain as well. All the rest is non-essential, the error is reproducable even with "zero" config.

My project is React-based, with a set of components each having it's own scss file, required inside each component individually, including the Root component - the one which is rendered to DOM inside my entry file (say /src/index.js, has require('index.scss')).

What happens on build stage is kinda in line with expectations - all the css got exported to style.css (despite it produces extra files like style.main.js for no obvious reason). The problem is that that my entrypoint javascript never got executed when the bundle is loaded. So there's no warnings or errors, everything compiles smoothly, the files (main.js and style.css) are delivered to the browser, but the code from index.js is not executed, so I just stare at a blank html template.

In the end I switched back to extract-text-webpack-plugin@next cause I couldn't overcome that issue. Any ideas what causes that?

[blakedietz]

I too was seeing an issue similar to this. Instead I was getting a third bundle created. For example if the bundle was named bundle.js I would see an output of 0.bundle.js, bundle.js, styles.css.

[alexander-akait]

Feel free to investigate and send PR.
Don't use extract-text-webpack-plugin@next it is break long term cache, output very large bundle and can raise problems in runtime code which very hard to find and fix.

[octaharon]

Sorry, I've realized that a link to documentation was missing in my original post, edited. That's quite important for understanding the problem.

Perhaps the issue with plural output files belongs to webpack itself, since its driven by optimization.splitChunks.cacheGroups config option, but the issue with "swallowing" the entrypoint of scripts is definitely coming from this plugin. If those are connected, than there's no better description

problems in runtime code which very hard to find and fix

Do you by chance know a repo with the aformentioned configuration in place? That could be a good starting point for investigation.

[dcousineau]

I don't have a public repo but I finally traced my problem with production builds in webpack-4 to this issue.

In development mode my optimization stanza is:

  optimization: {
    splitChunks: {
      chunks: 'all',
    },
    runtimeChunk: {
      name: 'manifest',
    },
  },

While in production mode I have

  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        styles: {
          name: 'styles',
          test: /\.css$/,
          chunks: 'all',
          enforce: true
        },
      },
    },
    runtimeChunk: {
      name: 'manifest',
    },
  },

Production properly spits out the correct singular bundled CSS file, however my entrypoint chunk no longer executes.

I played around with removing both instances of chunks: 'all' and this caused the entry to execute (however, obviously, all the styles are in separate files that I now have to chase down individually).

I also tried removing both chunks: 'all' as well as renaming the cacheGroup to "app" (which is my entrypoint's name) and the non-execution problem came back.

Note: I've tested permutations with and without the runtime chunk stuff and it had no effect
Additionally: Removing the first chunks: 'all' immediately under the optimization and above cacheGroups has no effect

[dcousineau]

In attempting to create a minimal reproduction case, it appears if you don't include the outputted styles.js bundle generated via the cacheGroup the application won't execute at all. I was using the HTML Webpack Plugin which automatically inserted the styles.js as a script tag, when removing it the application ceases to function.

While this description is not 100% accurate, it feels like MiniCSSExtractPlugin is accidentally stealing 'entrypoint' responsibilities from the actual entry point and investing it in the very tiny styles.js file it generates in the process of extracting the styles imported.

[dcousineau]

Please see https://github.com/dcousineau/mini-css-extract-plugin-reproduction for a demonstration of how, even though the styles.js is effectively empty it prevents the entrypoint from executing.

[dcousineau]

I think the ideal behavior would be the app.js entry bundle would be capable of loading the styles.js bundle itself, or anything that comes from the import statement (e.g. classNames when using css modules) would get inlined or included in the app bundle itself (no generated styles.js bundle)

[octaharon]

Good job with locating the repo, man! I support the idea of avoiding generating extra js files when we extract css only, that's somewhat not semantical and user-friendly at all. That configuration, as it says in the documentation, should behave pretty much the same as the extract-text-plugin in this case. Which is, by the way, working perfectly for me so far in couple with optimize-css-assets-plugin. Other option would be auto-injecting the style.js into one of entries by providing entryName or something in plugin config, declarative style, or even detecting the 'target' setting of webpack itself.

[coltonw]

I would like to point out that this problem is doubly bad for javascript/css libraries trying to use mini-css-extract-plugin. Users of the library will have to not only import the library code and css, but also this generated style.js file or the library simply won't work.

[rzcoder]

Can't update to webpack 4 cus this bug

[emilomir]

I have the same problem. Did someone figured this out?

[melissa-hong]

In case it helps, a "workaround" I've found is to inline the contents of the extra js file generated using html-webpack-plugin (got the idea from @octaharon's suggestion). E.g:

Add the html-webpack-plugin to list of plugins in webpack config (you need to be using the alpha html-webpack-plugin version with webpack 4):

new HtmlWebpackPlugin({
    filename: "../../tmpl/my-css-prod.html",
    hash: false,
    inject: false,
    template: "my-css-tmpl.html"
})

Create a template that will inline the css of the extra js file e.g my-css-tmpl.html:

<% for (var css in htmlWebpackPlugin.files.css) { %>
  <link href="<%= htmlWebpackPlugin.files.css[css].path.substr(htmlWebpackPlugin.files.publicPath.length) %>" rel="stylesheet">
  <script type="text/javascript">
    <%=
        compilation.assets[htmlWebpackPlugin.files.css[css].path
        .substr(htmlWebpackPlugin.files.publicPath.length).match(/([a-z-]+)\.css/)[1] + ".js"]
        .source()
    %>
  </script>
<% } %>

I then import this generated html file into my head (in place of my manual css imports). The generated html file looks something like this:

<link href="../styles-a.css" rel="stylesheet">
<script type="text/javascript">
    (window.webpackJsonp=window.webpackJsonp||[]).push([[0],[]]);
</script>
<link href="../styles-b.css" rel="stylesheet">
<script type="text/javascript">
    (window.webpackJsonp=window.webpackJsonp||[]).push([[46],[]]);
</script>

With this the css and js loads correctly - however I'm still having issues getting the import order of my css correct but I'm leaving that for another day...

Hope it helps - this has been stumping me for awhile! Any other ideas - let me know!

[thuanmb]

+1

[newmanw]

+1

Any updates?

[flylixiaolong]

+1