Closed chris-morgan closed 6 years ago
Since YOU are passing those vars to the plugin, YOU can probably pass the same to another plugin.
That would indeed be one way of operating, but I don’t think it’s ideal. It’s better if plugins that are explicitly building on top of this—using Custom Properties syntax—can genuinely build on top of it.
This ties in (very) loosely with #60 too.
Closed based on #60. PRs welcome if someone would like different functionality.
I contend the closure mildly. There was no solution in #60, nor even a workaround—merely a declaration of what such a workaround would be (amounting to “not my problem, make a plugin of your own to inject the variables
into the stylesheet”). And that’s what this issue is all about, because the state of affairs substantially reduces the utility of the variables
option.
postcss-at-rules-variables is all about making custom properties work inside things like
@if
, but it goes looking through:root
rules to fill them in, rather than depending on this plugin’s knowledge of the variables that there are. This is troublesome because variables that are created through the options (customProperties({variables:{foo:'bar'}})
) are completely inaccessible to it.GitScrum/postcss-at-rules-variables#153 is about this from postcss-at-rules-variables’ side.