Foundation-sites: build: move to PostCSS

[DanielRuf]

Sass has its issues like missing binaries for all platforms, not so great performance and dependencies like node-gyp.

A move to PostCSS will solve all these issues and allow us to use new CSS features internally before they can be used in all browsers.

[DanielRuf]

Should we also label this for Foundation Sites 7 @colin-marshall?

[colin-marshall]

I think some of our dependencies are deprecated and recommend switching to PostCSS anyway. If it's not too complicated, we could probably get this in for 6.5.

[DanielRuf]

There are about 3 PostCSS plugins needed to use the current code without (almost) any code changes.
So this should be possible in general.

[DanielRuf]

https://github.com/jonathantneal/postcss-advanced-variables
https://github.com/postcss/postcss-simple-vars
https://github.com/postcss/postcss-nested
https://github.com/postcss/postcss-mixins
https://github.com/pascalduez/postcss-apply
https://github.com/postcss/postcss-color-function
https://github.com/andyjansson/postcss-functions

https://bigbitecreative.com/a-look-into-writing-future-css-with-postcss-cssnext/
http://cssnext.io/features/
https://pawelgrzybek.com/from-sass-to-postcss/
https://www.signalonline.at/blog/moving-sass-to-postcss

What is missing?

I guess we should do this in v7.

[erredeco]

Pardon me the naive question, but... why should someone stop using scss to do the same things with an ensemble of postprocessors? This would mean that you have to rely on more dependencies (so more potential issues, an higher risk that the author of postprocessor X stops the development...) or not?
Is it just a performance thing?

[DanielRuf]

It is not just a performance thing. PostCSS uses cssnext and supports much more new upcoming features.

[erredeco]

Don't take me wrong, I am in favor of using postcss processors (like autoprefixer - aways be praised - or cssclean for example) but I currently don't understand why I should prefer:

• postcss-simple-vars + postcss-mixins + postcss-nested + postcss-color-function + et cetera (whatever else is needed to emulate the same functionalities of scss)

versus

• scss

As I wrote, what happens if the author of postcss-mixins for example stops the development ?

[ncoden]

I do not know PostCSS enough to get into the "PostCSS" vs "Sass" discussion. I heard that PostCSS plugins can be buggy when used together but never used it on a real project to test this be myself. Also, I fully agree with the fact that Sass is limited, bugged too and not well maintained.

The thing is Foundation is not only a CSS+JS library but a Sass library too. We provide mixins and helpers people can use to build their own design and components. Switching to PostCSS would be a major breaking change for all the workflows. So no matter how easy for us it is to migrate, this is definitely not coming before v7.

If we want to investigate in it for v7, I'd like these question to be resolved:

• Would all variables/mixins/placeholders/utilities/any helpers defined in Foundation be importable in the user PostCSS ?
• Would this be compatible with any workflow without advanced configuration ?

[colin-marshall]

I guess I misunderstood what this PostCSS proposal was when I made my post, so please disregard that. I thought it was just for replacing gulp plugins like autoprefixer. I didn't realize it would be to replace Sass altogether.

[DanielRuf]

replacing gulp plugins

This is part of the full move to webpack (4) then.

[colin-marshall]

@DanielRuf I assumed we would be using this for webpack:
https://github.com/webpack-contrib/sass-loader

[DanielRuf]

Sure. PostCSS is just an idea for v7 as Sass is not so fast at all.

[Grawl]

LibSass has been deprecated in favor of Dart Sass