You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+11-42Lines changed: 11 additions & 42 deletions
Original file line number
Diff line number
Diff line change
@@ -17,41 +17,45 @@
17
17
</p>
18
18
19
19
# extract-css-chunks-webpack-plugin
20
-
> TIP: remove `style-loader` from your dependencies. It's included in this package and must resolve to the correct *latest* version (June 2017).
20
+
> **UPDATE (July 7th):**[babel-plugin-dual-import](https://github.com/faceyspacey/babel-plugin-dual-import) is now required to asynchronously import both css + js. *Much Faster Builds!*
21
21
22
22
Like `extract-text-webpack-plugin`, but creates multiple css files (one per chunk). Then, as part of server side rendering, you can deliver just the css chunks needed by the current request. The result is the most minimal CSS initially served compared to emerging JS-in-CSS solutions.
If you use [webpack-flush-chunks](https://github.com/faceyspacey/webpack-flush-chunks), it will scoop up the exact stylesheets to embed in your response string for you.
48
51
52
+
[babel-plugin-dual-import](https://github.com/faceyspacey/babel-plugin-dual-import) is required for ascynchronous requests via `import()`. It requests both your js + your css. *Very Nice!* 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).
49
53
50
54
## Perks:
51
55
-**HMR:** It also has first-class support for **Hot Module Replacement** across ALL those css files/chunks!!!
52
-
53
-
-**2 VERSIONS OF YOUR JS CHUNKS:** In addition to generating CSS chunks, this plugin in fact creates 2 javascript chunks instead of 1. It leaves untouched your typical chunk that injects styles via `style-loader` and creates another chunk named `name.no_css.js`, which has all CSS removed, thereby greatly reducing its file size. This allows for future asynchronously-loaded bundles (which will be loaded *without* a css file) to also have their corresponding styles, ***while reducing the size of your initially served javascript chunks as much as possible*** 🤓
54
-
56
+
- cacheable stylesheets
57
+
-smallest total bytes sent compared to "render-path" css-in-js solutions that include your CSS definitions in JS
58
+
- Faster than V1!
55
59
56
60
57
61
## Installation
@@ -101,36 +105,6 @@ Keep in mind we've added sensible defaults, specifically: `[name].css` is used w
101
105
The 2 exceptions are: `allChunks` will no longer do anything, and `fallback` will no longer do anything when passed to to `extract`. Basically just worry about passing your `css-loader` string and `localIdentName` 🤓
102
106
103
107
104
-
105
-
## How It Works
106
-
107
-
Just like your JS, it moves all the the required CSS into corresponding css chunk files. So entry chunks might be named: `main.12345.css` and dynamic split chunks would be named: `0.123456.css`, `1.123456.css`, etc. You will however now have 2 files for each javascript chunk: `0.no_css.js` and `0.js`. The former is what you should serve in the initial request (and what [webpack-flush-chunks](https://github.com/faceyspacey/webpack-flush-chunks) in conjunction with [react-universal-component](https://github.com/faceyspacey/react-universal-component) will automatically serve). The latter, *which DOES contain css injection via style-loader*, is what will asyncronously be loaded in future async requests. This solves the fact that they otherwise would be missing CSS, since the webpack async loading mechanism isn't built to serve both a JS and CSS file. In total, 3 files are created for each named entry chunk and 3 files for each dynamically split chunk, e.g:
108
-
109
-
**entry chunk:**
110
-
-`main.js`
111
-
-`main.no.js`
112
-
-`main.css`
113
-
114
-
**dynamic chunks**:
115
-
116
-
*chunk 0:*
117
-
-`0.js`
118
-
-`0.no_css.js`
119
-
-`0.css`
120
-
121
-
*chunk 1:*
122
-
-`1.js`
123
-
-`1.no_css.js`
124
-
-`1.css`
125
-
126
-
*chunk 2:*
127
-
-`2.js`
128
-
-`2.no_css.js`
129
-
-`2.css`
130
-
131
-
As part of server-side rendering, you obviously should embed within the page the js files with the `no_css.js` extension. The `.js` files will be loaded by default when Webpack asyncronously requests them, *and you won't have to worry about embedding them in any response strings.*
132
-
133
-
134
108
## What about Aphrodite, Glamor, StyleTron, Styled-Components, Styled-Jsx, etc?
135
109
136
110
If you effectively use code-splitting, **Exract Css Chunks** can be a far better option than using emerging solutions like *StyleTron*, *StyledComponents*, and slightly older tools like *Aphrodite*, *Glamor*, etc. We aren't fans of either rounds of tools because of several issues, but particularly because they all have a runtime overhead. Every time your React component is rendered with those, CSS is generated and updated within the DOM. On the server, you're going to also see unnecessary cycles for flushing the CSS along the critical render path. *Next.js's*`styled-jsx`, by the way, doesn't even work on the server--*not so good when it comes to flash of unstyled content (FOUC).*
@@ -174,11 +148,6 @@ As an aside, so many apps share code between web and React Native--so the answer
174
148
**Long live the dream of Code Splitting Everywhere!**
175
149
176
150
177
-
## Notes on extract-text-webpack-plugin
178
-
179
-
Most the code comes from the original Extract Text Webpack Plugin--the goal is to merge this functionality back into that package at some point, though that process is not looking good. So that might be a while. Until then I'd feel totally comfortable just using this package. Though it took a while to make (and figure out how the original package worked), very little code has changed, and it won't be hard to keep in sync with upstream changes.
180
-
181
-
182
151
## Contributing
183
152
We use [commitizen](https://github.com/commitizen/cz-cli), so run `npm run cm` to make commits. A command-line form will appear, requiring you answer a few questions to automatically produce a nicely formatted commit. Releases, semantic version numbers, tags and changelogs will automatically be generated based on these commits thanks to [semantic-release](https://github.com/semantic-release/semantic-release). Be good.
0 commit comments