Right now, we partially configure postcss in core by adding the postCssImport plugin, half as a relic from initial development and half because it's an ugly config and we figured everyone would use it. But I don't think this is the right thing to do, for a couple reasons.
If any other postcss plugin ever needs to use the configuration function like the imports one does, they will be unable to do this through spike without forking and modifying core, which is whack
It's confusing where the imports even come from, and there is no ability to remove this plugin. Having it sit in the base template config makes it more clear what is actually being passed to postcss and gives the user full control over it.
The disadvantage is only prettiness, but in this case I think flexibility and clarity outweigh this concern.
Right now, we partially configure postcss in core by adding the postCssImport plugin, half as a relic from initial development and half because it's an ugly config and we figured everyone would use it. But I don't think this is the right thing to do, for a couple reasons.
The disadvantage is only prettiness, but in this case I think flexibility and clarity outweigh this concern.