main.css no longer in UMD build at v0.23.0

[tnrich]

Hey there @insin

I'm just wondering, I noticed that the main.css file is no longer in the UMD build at v0.23.0 (not sure when this was introduced but sometime after v0.21.5). It appears to now be appended with some random uuid now like main.61ade1d7.css

Do you know why this might be? Please reach out if you need any more info. Thanks!

v0.21.5:

v0.23.0

Let me add that the reason this is important to me is that I and others are linking to the main.css file from unpkg in demo pages and those pages now do not have a way of pointing to the most recently built version.

[insin]

That's because the default config for webpack.extractCSS puts a contenthash in the filename for production builds and we now always run UMD builds in production mode because Webpack 4's new mode defaults produce code in development mode which isn't suitable for publishing as a UMD build.

You can disable the contenthash by overriding the extractCSS.filename config:

module.exports = {
  webpack: {
    extractCSS: {
      filename: '[name].css'
    }
  }
}

Note: creation of extracted CSS files as part of UMD builds has always been a complete accident 🐱

[tnrich]

Hey @insin thanks for getting back to me. I implemented your extractCSS option

module.exports = {
  webpack: {
    extractCSS: {
      filename: '[name].css'
    }
  }
}

and a main.css is now being made. I am just wondering, it appears the UMD build is outputting 2 main.css's with the same name:

Do you know what that is about? Is one supposed to be minified and the other not?

[tnrich]

Also, is the reason for the default of having a content hash in production but not during dev to allow for browser caching to work out of the box?

process.env.NODE_ENV === 'production' ? [name].[contenthash:8].css : '[name].css'

[insin]

Do you know what that is about? Is one supposed to be minified and the other not?

It's the combined output of 2 set of Webpack stats for which checking if there were duplicates was never a consideration.

Also, is the reason for the default of having a content hash in production but not during dev to allow for browser caching to work out of the box?

Yes. this is the the intended use case when using nwb to build apps - the content hash in the filename should only change when the file's contents change.

The config for this was just never turned off when using nwb's Webpack config generation to generate config for creating UMD builds.