ai on 7.0.27
ai on master
Release 7.0.27 version (compare)
ai on master
Update the type annotation for … (compare)
postcss.config.jsin 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:nextbranch on May 22, 2018.
utils/removeStyleElement.js, and test them better
@nextto test a new major update. Since we do not use Babel anymore, you can use
masterfrom GitHub in dependencies and everything will work
publishstep 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-loaderto new major release (update deps, drop node@6 and etc), will be great also update
postcsstoo, any ETA for next