react-scripts@next drops css import in production build #5140

Activity

1. gaearon

   added

   issue: bug

   on Sep 27, 2018
2. gaearon

   added this to the 2.0.0 milestone on Sep 27, 2018
3. edmorley commented on Sep 27, 2018

   

   edmorley

   on Sep 27, 2018

   Last edited by edmorley

   More actions

   Hi @cdaringe :-)

   The react-octagon package has set sideEffects: false in their package.json:
   https://github.com/Tripwire/octagon/blob/v15.1.2/package.json#L98

   As such when mode is 'production' webpack 4's improved tree shaking drops the import by design.

   From the webpack tree shaking docs:

   Note that any imported file is subject to tree shaking. This means if you use something like css-loader in your project and import a CSS file, it needs to be added to the side effect list so it will not be unintentionally dropped in production mode:

   Therefore react-octagon's package.json needs to instead use something like:

     "sideEffects": [
       "*.css"
     ],

   👍React with 👍3Reacted by Aidar Ibatullin, Ian Sutherland and Joe Haddad
4. 01dr commented on Sep 27, 2018

   

   01dr

   on Sep 27, 2018

   Last edited by 01dr

   More actions

   This is it. I tried this case with a other library, and everything works correctly
5. cdaringe

   closed this as completedon Sep 28, 2018
6. cdaringe commented on Sep 28, 2018

   

   cdaringe

   on Sep 28, 2018

   Last edited by cdaringe

   Author

   More actions

   cool, thanks all. it was because of side effects indeed, but just to clarify, i don't think the prescribed solution is the ideal solution. the root cause is really that i simply didn't use that import.

   // works.
   import * as css from 'react-octagon/lib/styles/semantic.css'
   console.log(css) // can't shake me now, i'm used!

   thus, because my code didn't use the css, it was shaken. i would think in my CRA project (not my dependencies) i would declare sideEffects: [ <css glob > ] to make webpack hold onto any css file. this does not work for the aforementioned example, but IMHO matches the language used in the webpack docs.

   having the whole thing work by declaring css sideEffects inreact-octagon seems off. from react-octagon's perspective, a css file doesn't fit the definition of a sideEffect--it's a logicless asset.

   what perspective am i missing here? maybe this conversation is better suited for the webpack repo :)
7. edmorley commented on Sep 28, 2018

   

   edmorley

   on Sep 28, 2018

   Last edited by edmorley

   More actions

   @cdaringe it's valid to have imports that are not assigned to anything.

   The issue here is that webpack 4 created a new way for packages to declare "none/some/all of the files in this package have any side-effects by importing alone, so it's safe to drop them as an optimization", via the optional sideEffects entry in package.json. And that API currently requires packages to list all files including CSS, since webpack doesn't special-case particular types (and doesn't offer a way for its loaders to do so either).

   As such at least in the feature's current implementation, omitting CSS file entries from the sideEffects property is a bug.

   However I agree the sideEffects feature should be improved - discussion in webpack/webpack#6571.

   👍React with 👍1Reacted by Christopher Dieringer
8. lock

   locked and limited conversation to collaborators on Jan 11, 2019