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.
postcss.config.jsis 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.jsinstead of or in addition to the currentpostcss_binary#pluginsapproach.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.additionalOutputsandbazel.datavariables?Requiring use of these
bazel.*variables breaks portability assumptions, if the reason for supportingpostcss.config.jsis because it's a standardised approach that could be used with other PostCSS runners.