You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 25, 2023. It is now read-only.
This is currently low priority, however I've created this issue to gather interest for configuring via postcss.config.js instead of or in addition to the current postcss_binary#plugins approach.
An open design question is how this can work with Bazel's model, which requires all inputs and outputs to be specified ahead of time.
Requiring use of these bazel.* variables breaks portability assumptions, if the reason for supporting postcss.config.js is because it's a standardised approach that could be used with other PostCSS runners.
The text was updated successfully, but these errors were encountered:
postcss.config.js
is a configuration format used by many PostCSS runners, such as postcss-loader for webpack and rollup-plugin-postcss, and is commonly referred to by PostCSS plugin docs such as Tailwind's.This is currently low priority, however I've created this issue to gather interest for configuring via
postcss.config.js
instead of or in addition to the currentpostcss_binary#plugins
approach.An open design question is how this can work with Bazel's model, which requires all inputs and outputs to be specified ahead of time.
For example, would we need to replicate availability of the special
bazel.binDir
,bazel.additionalOutputs
andbazel.data
variables?Requiring use of these
bazel.*
variables breaks portability assumptions, if the reason for supportingpostcss.config.js
is because it's a standardised approach that could be used with other PostCSS runners.The text was updated successfully, but these errors were encountered: