Locally I can set a z-index of 10 but when I run through production it get's compressed to 3. Apparently this is a cssnano thing but it doesn't appear you are utilizing cssnano. Any idea where this could be coming from and how I could disable this behavior?
Worth noting if I roll back to 3.5.3 it's no longer an issue.
I am seeing the same issue, presume it is related to: https://github.com/vuejs-templates/webpack/issues/614
I'd guess there is some way to pass safe: true down into the CSS processing from vue-loader but I can't tell how to do that exactly.
Based on other PRs that have been accepted, I suspect that upgrading to vue-loader v15 will fix this problem, but the migration path is pretty complicated. I spent some time on it, but getting cryptic errors:
Compiling…
Compilation failed:
Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
- configuration.module.rules[7] should be an object.
-> A rule
and not sure how to proceed. Not sure I understand the purpose of webpacker obfuscating the actual webpack config file behind environment.js, makes it very hard to modify or debug.
see also: vue-loader migration guide at https://vue-loader.vuejs.org/migrating.html
I’m going to echo this as my biggest gripe with webpacker. It’s very difficult to tweak as everything seems to be overwrites rather than actually setting or adjusting from the ground up. There may be legitimate reasons for this design choice but it makes this package a pain to use even if it is still the best way to get webpack into a Rails app
Adding the following in my production.js webpack config fixed the issue for me. Perhaps this should be a webpacker default. FWIW we do not use Vue.
environment.plugins.get('OptimizeCSSAssets').options.cssProcessorOptions.safe = true
It took me a while to figure out which (new) plugin was causing this issue, what webpacker named it, and that it is only included in the production environment. It would be great if plugin configurations were loaded via a separate config file in config/webpack so they could be easily adjusted in one place. The files could serve as documentation of default values and allow changes, much like the rails environment config files.
Hopefully css-loader will get bumped to > 1 which will resolve this issue in webpacker v4.
Ran into this as well. My fix was similar to @jnimety, but modifying _only_ the zindex setting:
// config/webpack/production.js
environment.plugins.get('OptimizeCSSAssets').options.cssProcessorOptions.zindex = false
@kylefox do you have any idea how to test that configuration in local or staging environment ? I have exactly same problem about z index with webpacker but it not working smoothly because when i implement your solution i got the error
.../node_modules/@rails/webpacker/package/config_types/config_list.js:48
if (shouldThrow && index < 0) throw new Error(Item ${key} not found)
^
Error: Item OptimizeCSSAssets not found
is it relevant?
Is this a problem in latest RC?
@ahyanarizky You could try setting NODE_ENV=production, assuming you're adding this config to config/webpack/production.js.
We're using Webpacker 3.5.5, so your mileage may vary if you're running a 4.0 RC.
@kylefox We have fixed this in latest RC, it uses postcss safe parser so you don't need to specify the option.
Upgraded from 3.5.5 to 3.6.0 and finding this is still an issue?
(Also @kylefox's fix did work for us, thanks!)
If it's good for you feel free to close the issue please 👍
Most helpful comment
Adding the following in my production.js webpack config fixed the issue for me. Perhaps this should be a webpacker default. FWIW we do not use Vue.
environment.plugins.get('OptimizeCSSAssets').options.cssProcessorOptions.safe = trueIt took me a while to figure out which (new) plugin was causing this issue, what webpacker named it, and that it is only included in the production environment. It would be great if plugin configurations were loaded via a separate config file in
config/webpackso they could be easily adjusted in one place. The files could serve as documentation of default values and allow changes, much like the rails environment config files.