Support postcss

[deviantintegral]

On a call yesterday, both @starshaped and @ckrina mentioned how they think now is the time to switch new projects from sass to postcss. When I asked what was in the way of making that happen, they both said that the biggest next step would be to support postcss in drainpipe like how we do with sass.

Let's discuss what high level commands we would want to add, what points of extensibility there may need to be, and what our ideal testing plan is.

I don't know if this matters, but I would also say that supporting single directory components would be a big win as well.

[justafish]

we do currently use a couple of postcss plugins (autoprefixer and cssnano), however it's hard to say we support it when it's designed to be a language you customise yourself for each project by clicking together various plugins. I personally switched back to sass where possible because it's behaviour was unpredictable and hard to maintain.

[deviantintegral]

@starshaped Can you think through what sort of setup makes sense to share across projects as far as postcss goes? If we have a proposal, even just "here's the libraries and configuration I'd recommend", I think it will help us determine how and if we do this.

[starshaped]

How many browser versions back are we wanting to support? If we need to support a lot of older browsers, we'd want to pull in PostCSS plugins for things like nesting. If we're supporting mostly 'modern' browsers, however, there probably aren't a lot of plugins we'd need.

One that would be useful to add in addition to autoprefixer and cssnano would be PostCSS Custom Media, which would add the ability to use CSS custom properties in media queries (something that isn't currently possible).

Another that would be useful if we'd want to replicate using Sass partials is PostCSS Import, so that would be worth looking into. Drupal core uses this PostCSS plugin currently as well.

Besides that, it all depends on what Sass functionality we'd want to replicate using PostCSS, if any. CSS has so many fantastic things built into it now that wouldn't really need to add a lot of PostCSS plugins!

[deviantintegral]

I'm marking as low as there haven't been further requests on this since it was initially filed, but if we've got PostCSS on new projects we can re-evaluate.

[deviantintegral]

How many browser versions back are we wanting to support?

For new projects, we generally say "only the current supported release" of each browser. If a browser isn't getting security updates, it's dropped.

@YesCT could you also (easily) provide a representative guideline from LSM projects?

[justafish]

I don't think this is going to be practically possible. The current plugins we use don't change the syntax of CSS, if we start adding ones that do and supporting a particular PostCSS pipeline we'd be stuck maintaining a custom language - which means we also have to provide things like backwards compatibility etc.

[ckrina]

I still think this is not that crazy. There are very few postCSS plugins that we would need currently. I would move away from replicating SASS way of styling and more on working with a CSS mindset. My problem though when setting up a project is basically setting all the plugins, get them working together... I have to invest too much time to get all this working inside our project structure. Could we just have a starting point with one or 2 plugins and then if a project or a team wants to add more things they can do that for their specific project?

[justafish]

Could we just have a starting point with one or 2 plugins and then if a project or a team wants to add more things they can do that for their specific project?

^ this is the problem - we can only maintain a specific set of plugins, which we'll then need to continue supporting. What I've seen happen with postcss is that an update to one of those plugins, or the addition of a new one, completely breaks the pipeline and this can happen at the project level outside of our control