-
-
+If you like our work, check out our Redux-based router redux-first-router or its sucessor which, Rudy
# extract-css-chunks-webpack-plugin
@@ -9,7 +6,7 @@
-
+
@@ -29,359 +26,594 @@
πΎπΎπΎIt's our absolute pleasure to announce Webpack 4 Support πππ
-> **HEADLINES (May 2018): Now Independently supports Webpack 4:** -Yep that's right. The universal family is now fully Webpack 4. Thank you to all our users for your loyalty and patience! If you love Universal, then you are gonna fall head over heels when we bring out the main course! +> **HEADLINES (May 2018): Now Independently supports Webpack 4:** +> Yep that's right. The universal family is now fully Webpack 4. Thank you to all our users for your loyalty and patience! If you love Universal, then you are gonna fall head over heels when we bring out the main course! -So... why did we rebuild `extract-css-chunks`? What does it offer? +So... why did we rebuild `extract-css-chunks-webpack-plugin`? What does it offer? -It's got all the goodness of `mini-css-extract-plugin` but with 2 gleaming, sought after benefits. +It's got all the goodness of `mini-css-extract-plugin` but with 2 gleaming, sought after benefits. Compared to the existing loaders, we are offering a single solution as opposed to needing to depend on multiple loaders to cater for different features: ## Perks -* **HMR:** It also has first-class support for **Hot Module Replacement** across ALL those css files/chunks!!! -* cacheable stylesheets -* smallest total bytes sent compared to "render-path" css-in-js solutions that include your CSS definitions in JS -* Faster than the V2! -* Async loading -* No duplicate compilation (performance) -* Easier to use -* Specific to CSS -* SSR Friendly development build, focused on frontend DX -* Works seamlessly with the Universal family -* Works fantastically as a standalone style loader (You can use it for any webpack project! with no extra dependencies!) - -Additionally, if you are already a user of the universal family -- we will be waving goodbye to the mandatory ```window.__CSS_CHUNKS__```. + +- **HMR:** It also has first-class support for **Hot Module Replacement** across ALL those css files/chunks!!! +- cacheable stylesheets +- smallest total bytes sent compared to "render-path" css-in-js solutions that include your CSS definitions in JS +- Faster than the V2! +- Async loading +- No duplicate compilation (performance) +- Easier to use +- Specific to CSS +- SSR Friendly development build, focused on frontend DX +- Works seamlessly with the Universal family +- Works fantastically as a standalone style loader (You can use it for any webpack project! with no extra dependencies!) +- Async styles do not render block webkit browsers, if you use the `insert` option + +Additionally, if you are already a user of the universal family -- we will be waving goodbye to the mandatory `window.__CSS_CHUNKS__`. The functionality is still available to you via chunk flushing, and it can come in super handy when needing to easily resolve style assets as urls that might need to be passed to a third party. -## Webpack 4 Standalone Installation: +**webpack.config.js** -If you are just looking for something that works like `mini-css-extract-plugin` but with HMR, then look no further. +```js +const ExtractCssChunks = require('extract-css-chunks-webpack-plugin'); -NOTE: We have aligned out loader implementation to be the same as `mini-css-extract-plugin` +module.exports = { + plugins: [new ExtractCssChunks()], + module: { + rules: [ + { + test: /\.css$/i, + use: [ExtractCssChunks.loader, 'css-loader'], + }, + ], + }, +}; +``` -**If you already use `mini-css-extract-plugin`, then you can just change the `require` statement - it's that easy** +## Options -``` -yarn add --dev extract-css-chunks-webpack-plugin -``` +### `publicPath` + +Type: `String|Function` +Default: the `publicPath` in `webpackOptions.output` + +Specifies a custom public path for the target file(s). + +#### `String` + +**webpack.config.js** -*webpack.config.js:* ```js -const ExtractCssChunks = require("extract-css-chunks-webpack-plugin") +const ExtractCssChunks = require('extract-css-chunks-webpack-plugin'); module.exports = { + plugins: [ + new ExtractCssChunks({ + // Options similar to the same options in webpackOptions.output + // both options are optional + filename: '[name].css', + chunkFilename: '[id].css', + }), + ], module: { rules: [ { test: /\.css$/, use: [ - ExtractCssChunks.loader, - "css-loader" - ] - } - ] + { + loader: ExtractCssChunks.loader, + options: { + publicPath: '/public/path/to/', + }, + }, + 'css-loader', + ], + }, + ], }, - plugins: [ - new ExtractCssChunks( - { - // Options similar to the same options in webpackOptions.output - // both options are optional - filename: "[name].css", - chunkFilename: "[id].css", - hot: true, // if you want HMR - we try to automatically inject hot reloading but if it's not working, add it to the config - orderWarning: true, // Disable to remove warnings about conflicting order between imports - reloadAll: true, // when desperation kicks in - this is a brute force HMR flag - cssModules: true // if you use cssModules, this can help. - } - ), - ] -} +}; ``` -*webpack.server.config.js* +#### `Function` -The server needs to be handled differently, we still want one chunk. Luckily webpack 4 supports **LimitChunkCountPlugin** +**webpack.config.js** ```js -new webpack.optimize.LimitChunkCountPlugin({ - maxChunks: 1 -}) +const ExtractCssChunks = require('extract-css-chunks-webpack-plugin'); + +module.exports = { + plugins: [ + new ExtractCssChunks({ + // Options similar to the same options in webpackOptions.output + // both options are optional + filename: '[name].css', + chunkFilename: '[id].css', + }), + ], + module: { + rules: [ + { + test: /\.css$/, + use: [ + { + loader: ExtractCssChunks.loader, + options: { + publicPath: (resourcePath, context) => { + return path.relative(path.dirname(resourcePath), context) + '/'; + }, + }, + }, + 'css-loader', + ], + }, + ], + }, +}; ``` +### `esModule` -### What about Webpack 3? -This is a breaking change. The entire loader has been fundamentally rewritten specifically for Webpack 4. Aiming to support our existing user base, allowing them to upgrade their infrastructure to support Webpack 4 based universally code-split server-side rendered react applications. +Type: `Boolean` +Default: `false` -There have been some challenges along the way since the release of webpack 4. Ultimately the only remaining hurdle is code split, async style loading. +By default, `extract-css-chunks-webpack-plugin` generates JS modules that use the CommonJS modules syntax. +There are some cases in which using ES modules is beneficial, like in the case of [module concatenation](https://webpack.js.org/plugins/module-concatenation-plugin/) and [tree shaking](https://webpack.js.org/guides/tree-shaking/). -If you do need Webpack 3, make sure to stick with the latest `v2.x.x` release. `v3.x.x` is only intended for users with Webpack 4 +You can enable a ES module syntax using: +**webpack.config.js** +```js +const ExtractCssChunks = require('extract-css-chunks-webpack-plugin'); +module.exports = { + plugins: [new ExtractCssChunks()], + module: { + rules: [ + { + test: /\.css$/i, + use: [ + { + loader: ExtractCssChunks.loader, + options: { + esModule: true, + }, + }, + 'css-loader', + ], + }, + ], + }, +}; +``` -*Note: this is a companion package to:* -- [webpack-flush-chunks](https://github.com/faceyspacey/webpack-flush-chunks) -- [react-universal-component](https://github.com/faceyspacey/react-universal-component) -- [babel-plugin-universal-import](https://github.com/faceyspacey/babel-plugin-universal-import) ***or*** [babel-plugin-dual-import](https://github.com/faceyspacey/babel-plugin-dual-import) +## Examples +### Minimal example -## Recommended Installation For Universal -``` -yarn add react-universal-component webpack-flush-chunks -yarn add --dev extract-css-chunks-webpack-plugin babel-plugin-universal-import -``` +**webpack.config.js** -*.babelrc:* ```js -{ - "plugins": ["universal-import"] -} +const ExtractCssChunks = require('extract-css-chunks-webpack-plugin'); + +module.exports = { + plugins: [ + new ExtractCssChunks({ + // Options similar to the same options in webpackOptions.output + // all options are optional + filename: '[name].css', + chunkFilename: '[id].css', + ignoreOrder: false, // Enable to remove warnings about conflicting order + }), + ], + module: { + rules: [ + { + test: /\.css$/, + use: [ + { + loader: ExtractCssChunks.loader, + options: { + // you can specify a publicPath here + // by default it uses publicPath in webpackOptions.output + publicPath: '../', + hmr: process.env.NODE_ENV === 'development', + }, + }, + 'css-loader', + ], + }, + ], + }, +}; ``` -The main thing is you need to cater to the new chunking system of webpack! -With **webpack.optimize.CommonsChunkPlugin** plugin no longer part of Webpack 4, we need another way to define the code-splitting. Luckily we have `optimization` configs built into webpack now -> There are more aggressive ways to code split, thanks to webpack 4. Check out the RUC Readme if you are looking for a more aggressive code split optimization configuration. These are just examples, you should be able to configure them as you see fit +### The `publicPath` option as function + +**webpack.config.js** -*webpack.config.js:* ```js -const ExtractCssChunks = require("extract-css-chunks-webpack-plugin") +const ExtractCssChunks = require('extract-css-chunks-webpack-plugin'); module.exports = { + plugins: [ + new ExtractCssChunks({ + // Options similar to the same options in webpackOptions.output + // both options are optional + filename: '[name].css', + chunkFilename: '[id].css', + }), + ], module: { rules: [ { test: /\.css$/, use: [ - ExtractCssChunks.loader, { - loader: 'css-loader', + loader: ExtractCssChunks.loader, options: { - modules: true, - localIdentName: '[name]__[local]--[hash:base64:5]', + publicPath: (resourcePath, context) => { + // publicPath is the relative path of the resource to the context + // e.g. for ./css/admin/main.css the publicPath will be ../../ + // while for ./css/main.css the publicPath will be ../ + return path.relative(path.dirname(resourcePath), context) + '/'; + }, }, }, + 'css-loader', ], }, ], }, - optimization: { - // FOR PRODUCTION - minimizer: [ - new UglifyJSPlugin({ - uglifyOptions: { - output: { - comments: false, - ascii_only: true - }, - compress: { - comparisons: false - } - } - }) - ], - // END - // NEEDED BOTH IN PROD AND DEV BUILDS - runtimeChunk: { - name: 'bootstrap' - }, - splitChunks: { - chunks: 'initial', - cacheGroups: { - vendors: { - test: /[\\/]node_modules[\\/]/, - name: 'vendor' - } - } - } - }, - plugins: [ - new ExtractCssChunks({hot:true, cssModules: true}), //if you want HMR - we try to automatically inject hot reloading but if it's not working, add it to the config - ] }; ``` -## Desired Output -Here's the sort of CSS you can expect to serve: - -``` - - - - - - - - - - - - - - -``` +### Advanced configuration example -If you need to resolve your stylesheets on the client side, for whatever reason. +This plugin should be used only on `production` builds without `style-loader` in the loaders chain, especially if you want to have HMR in `development`. -[webpack-flush-chunks](https://github.com/faceyspacey/webpack-flush-chunks) will scoop up the exact stylesheets to embed in your response. It will give you an object which can be embedded on page +Here is an example to have both HMR in `development` and your styles extracted in a file for `production` builds. -Here's how you do it: +(Loaders options left out for clarity, adapt accordingly to your needs.) +**webpack.config.js** -*src/components/App.js:* ```js -const UniversalComponent = universal(props => import(`./${props.page}`)) - -${app}
-
- ${cssHash}
-
- ${js}
-
-
-`)
+module.exports = {
+ plugins: [
+ new ExtractCssChunks({
+ // Options similar to the same options in webpackOptions.output
+ // both options are optional
+ filename: devMode ? '[name].css' : '[name].[hash].css',
+ chunkFilename: devMode ? '[id].css' : '[id].[hash].css',
+ }),
+ ],
+ module: {
+ rules: [
+ {
+ test: /\.(sa|sc|c)ss$/,
+ use: [
+ {
+ loader: ExtractCssChunks.loader,
+ options: {
+ hmr: process.env.NODE_ENV === 'development',
+ },
+ },
+ 'css-loader',
+ 'postcss-loader',
+ 'sass-loader',
+ ],
+ },
+ ],
+ },
+};
```
-***As for asynchronous calls to `import()` on user navigation,*** [babel-plugin-universal-import](https://github.com/faceyspacey/babel-plugin-universal-import) is required if you're using [react-universal-component](https://github.com/faceyspacey/react-universal-component). And if you aren't, you must use: [babel-plugin-dual-import](https://github.com/faceyspacey/babel-plugin-dual-import).
+### Hot Module Reloading (HMR)
+The `extract-css-chunks-webpack-plugin` supports hot reloading of actual css files in development.
+Some options are provided to enable HMR of both standard stylesheets and locally scoped CSS or CSS modules.
+Below is an example configuration of `extract-css-chunks` for HMR use with CSS modules.
-These babel plugins request both your js + your css. *Very Nice!* This is the new feature of the 2.0. Read *Sokra's* (author of webpack) article on how [on how this is the future of CSS for webpack](https://medium.com/webpack/the-new-css-workflow-step-1-79583bd107d7). Use this and be in the future today.
+While we attempt to hmr css-modules. It is not easy to perform when code-splitting with custom chunk names.
+`reloadAll` is an option that should only be enabled if HMR isn't working correctly.
+The core challenge with css-modules is that when code-split, the chunk ids can and do end up different compared to the filename.
+**webpack.config.js**
-## API
-You can pass the same options as `mini-css-extract` to `new ExtractCssChunks`, such as:
+```js
+const ExtractCssChunks = require('extract-css-chunks-webpack-plugin');
-```javascript
-new ExtractCssChunk({
- filename: devMode ? '[name].css' : '[name].[hash].css',
- chunkFilename: devMode ? '[id].css' : '[id].[hash].css',
-})
+module.exports = {
+ plugins: [
+ new ExtractCssChunks({
+ // Options similar to the same options in webpackOptions.output
+ // both options are optional
+ filename: '[name].css',
+ chunkFilename: '[id].css',
+ }),
+ ],
+ module: {
+ rules: [
+ {
+ test: /\.css$/,
+ use: [
+ {
+ loader: ExtractCssChunks.loader,
+ options: {
+ // only enable hot in development
+ hmr: process.env.NODE_ENV === 'development',
+ // if hmr does not work, this is a forceful method.
+ reloadAll: true,
+ },
+ },
+ 'css-loader',
+ ],
+ },
+ ],
+ },
+};
```
->Keep in mind, by default `[name].css` is used when `process.env.NODE_ENV === 'development'` and `[name].[contenthash].css` during production, so you can likely forget about having to pass anything.
+### Minimizing For Production
+
+To minify the output, use a plugin like [optimize-css-assets-webpack-plugin](https://github.com/NMFR/optimize-css-assets-webpack-plugin).
+Setting `optimization.minimizer` overrides the defaults provided by webpack, so make sure to also specify a JS minimizer:
-### HMR Pitfall
+**webpack.config.js**
-The most common workflow when working with webpack is to write a "development" / "production" value in to the
-'process.env.NODE_ENV' namespace, typically, using webpack's built-in "DefinePlugin" plugin. e.g:
+```js
+const TerserJSPlugin = require('terser-webpack-plugin');
+const ExtractCssChunks = require('extract-css-chunks-webpack-plugin');
+const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin');
-```javascript
-new webpack.DefinePlugin( {
- 'process.env': {
- NODE_ENV: `"${config.devMode ? 'development' : 'production'}"`,
+module.exports = {
+ optimization: {
+ minimizer: [new TerserJSPlugin({}), new OptimizeCSSAssetsPlugin({})],
+ },
+ plugins: [
+ new ExtractCssChunks({
+ filename: '[name].css',
+ chunkFilename: '[id].css',
+ }),
+ ],
+ module: {
+ rules: [
+ {
+ test: /\.css$/,
+ use: [ExtractCssChunks.loader, 'css-loader'],
},
-} )
+ ],
+ },
+};
```
-The value set by the aforementioned plugin will only be available in the runtime ( when webpack's javascript output is executed ).
-In order for this plugin to work with hot module reloading, The npm script / gulp task / grunt task etc, should be invoked with the same environment variable as shown above.
-For example, when running the build using some form of npm script:
+### Using preloaded or inlined CSS
-```json
-{
- "scripts": {
- "build": "cross-env NODE_ENV=production babel src -d dist --ignore 'src/**/*.test.js' --copy-files"
- }
-}
+The runtime code detects already added CSS via `` or `
+
+
+
+
+
+ Initial CSS: Must be green
+
+
+
+ Hot Module Replacement
+RED
+ GREEN
+ BLUE
+
+
+ Hot Module Replacement + CSS modules
+RED
+ GREEN
+ BLUE
+
+
+ + Lazy CSS: Must be red, but turn green when + . +
++ But turn orange, when + . Additional + clicks have no effect. +
++ Refresh and press buttons in reverse order: This should turn green + instead. +
+
+
+ + Lazy CSS: Turn off the network and + . +
+An error should have appeared.
++ Now if you turn the network back on and click it again, it should turn + aqua. +
+
+
+ Preloaded CSS: Must be green.
++ displays + an alert and should turn red. +
+
+
+ Preloaded inlined CSS: Must be green.
++ displays + an alert and should turn red. +
+
+
+
+
+
+ zack
+CrossOriginLoading Option: Must be red.
++ loads chunks with crossorigin + attribute and should turn green. +
+