@evilebottnawi, may it help to see the postcss-loader options? Maybe this will clarify: https://github.com/preactjs/preact-cli/blob/master/packages/cli/lib/lib/webpack/webpack-base-config.js#L206-L213
And here is the change I want to make: https://github.com/preactjs/preact-cli/blob/00bb61f865917db108ef90974bca291d5d5864aa/packages/cli/lib/lib/webpack/webpack-base-config.js#L207-L224
plugins
option for postcss-loader looks like this — { loader: 'postcss-loader', options: { plugins: [ autoprefixer({ overrideBrowserslist: browsers }) ] } }
— then it will override the plugins
option in postcss.config.js
.
postcss.config.js
in Preact CLI, which will let us specify our own PostCSS plugins without overriding the core preact configuration. preactjs/preact-cli#832
Hi. I've run into a problem a couple of times now. I'm hoping someone might be able to shed some light on it. This seems to only occur once the codebase gets large. I don't have a minimal example, but I'll describe what one might look like.
File A has multiple (postcss-advanced-variables) mixin definitions.
File B calls one of those mixins, and passes parameters.
File C, calls another.
File D (postcss-import) imports file A, file B, and file C, and gets outputted.
When the problem arises, changes to parameters in file C for example have no effect on the output from file D. It feels as though something is being cached somewhere, to the point that even deleting the mixin in file A has no effect on the output. At this point I would expect there to be an error, because I'm calling a mixin that doesn't exist, but all gulp processes appear to run fine, and I can continue to edit file B and see those changes reflected.
I don't understand what's happening here. Any ideas?
webpack-contrib:next
branch on May 22, 2018.
utils/insertStyleElement.js
, utils/removeStyleElement.js
, and test them better
files
field, maybe?
@next
to test a new major update. Since we do not use Babel anymore, you can use master
from GitHub in dependencies and everything will work
publish
step anymore, it is so great!
Hi! I have a question concerning testing components with Jest that depend on values obtained from a css file (via postcss-modules-values @value variables).
In my configuration I am using identity-obj-proxy for .modules.css files, as recommended, but it also transforms @value
declarations to plain name strings with no way of recovering the actual values.
The solution I found was to mock the .module.css
file into the component tests, but this way I have to mock it for all the parents of said component as well.
Does this sound "appropriate"? Is there another way of resolving jest warnings that may appear when using @value
properties in JS?
postcss-loader
to new major release (update deps, drop node@6 and etc), will be great also update postcss
too, any ETA for next postcss
release?