Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: Enabling sideEffects on style loaders (#1423)
**What kind of change does this PR introduce?** Bugfix / feature **Did you add tests for your changes?** Yes. Added a test to ensure that non-module CSS imported within a package that has `"sideEffects": false` would result in CSS being inlined in the head of the document. If the change to the style loader is reverted, the CSS import is ignored (skipped? not sure what it technically does) and the CSS will not end up being inlined. **Summary** Fixes #1411 I noticed this issue while building a component library. This library uses the Preact CLI to (mainly) run a development environment and Microbundle is used to the build/package the library itself. This is all well and fine. The issue that this PR fixes arose when I had decided that my dev environment looked good enough to toss up as demo of the library. The `sideEffects` field stops the Preact CLI from importing non-module CSS when set to `false` in a production build. This should not happen as `import 'x.css';` will always have a side effect. It's the very nature of that type of import. Reading through various threads led me to CRA's solution, which was to [enable sideEffects for their style loaders](https://github.com/facebook/create-react-app/blob/65d8eb23f28475716e7e9497215cd574c1bf0b6c/packages/react-scripts/config/webpack.config.js#L502). Doing something similar with our setup seems to work just as well. @developit had suggested something along the lines of the following which also would work with slight modification: ``` // in webpack.config.base.js module: { rules: [ { test: /\.m?[jt]sx?$/, exclude: nodeModules, sideEffects: true } ] } ``` Changing this to target CSS works just as well as what I did in this PR. I figured it's simpler to just add a field to the existing loader rather than add a new one. There might be a distinction between the two methods, but I'm not sure what that would be. **Does this PR introduce a breaking change?** Shouldn't be breaking. Co-authored-by: Ryan Christian <[email protected]> Co-authored-by: Ryan Christian <[email protected]>
- Loading branch information