fix: Enabling sideEffects on style loaders #1423
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: 4dc6675 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
rschristian
changed the title
rschristian
commented
Sep 15, 2020
Comment on lines
+272
to
+275
| // Don't consider CSS imports dead code even if the | ||
| // containing package claims to have no side effects. | ||
| // Remove this when webpack adds a warning or an error for this. | ||
| // See https://github.com/webpack/webpack/issues/6571 |
There was a problem hiding this comment.
Comment taken right from CRA, I felt that having an explanation in the source is useful.
|
Something that may be awkward is how to handle users who want to disable CSS modules. Besides disabling the modules option they might also need to know to add the side effects field. Not sure what the best way to handle that is though. Maybe just keep it in mind if anyone runs into issues? |
rschristian
force-pushed
the
fix/sideEffects
branch
from
8a4819e to
4dc6675
Compare
ForsakenHarmony
approved these changes
Mar 8, 2021
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Mar 8, 2021
**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]>
|
bors retry |
bors bot
pushed a commit
that referenced
this pull request
Mar 9, 2021
**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]>
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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": falsewould 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
sideEffectsfield stops the Preact CLI from importing non-module CSS when set tofalsein a production build. This should not happen asimport '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. 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:
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.