PostCSS plugins adapter

[DenisIzmaylov]

Requirements:

• Set of plugins for automating a kind of regular tasks, e.g. RTL, Browser Prefixes and so on.

Problems:

• It takes a lot of time and effort to achieve it.

Solutions:

It would be great to have an adapter which make it possible to re-use PostCSS plugins in JSS and to get the existing ecosystem available without any changes.

Some examples:

1. Autoprefixer: https://github.com/postcss/autoprefixer/blob/master/lib/autoprefixer.coffee
2. RTL, which is discussing in #410

The problem is that guys from PostCSS made a big vendor lock-in by using require("postcss") instead of dependency injection pattern.

• [ ] Design JSS bridge adapter to get it as drop-in replacement by using http://api.postcss.org/ and https://github.com/postcss/postcss/blob/master/docs/writing-a-plugin.md
• [ ] Find a way to replace postcss dependency in PostCSS plugins "on the fly"
• [ ] Write a plugin for https://github.com/cpojer/js-codemod which will transform the existing plugins to use DI pattern and a few adapters - for PostCSS and JSS

[iamstarkov]

@DenisIzmaylov wanna explore options and contribute?

[iamstarkov]

do you need rtl? and jss has plugin for autoprefixing

[kof]

PostCSS produces the AST, currently JSS doesn't have one.

[kof]

I will wait with this until there is a specific case. From my experience 95% of things people need are already in place.

[kof]

I will close this for now, because the output is not clear and overhead + work amount to make this happen is big. This would require a whole new concept.

[kof]

Also you don't need all postcss plugins in jss, those 2 have partially very different goals. Only some plugins are really useful.

[DenisIzmaylov]

Thanks for attention.

There is a lot of sugar and "nice to have" plugins which could be ported to JSS.

• https://github.com/2createStudio/postcss-sprites
• https://github.com/TrySound/postcss-inline-svg
• https://github.com/jonathantneal/postcss-write-svg
• https://github.com/postcss/autoprefixer
• http://postcss.parts/tag/color
• http://postcss.parts/

Almost all of those plugins could be used "AS IS".

Bonus point:

I think we have to define rule:

• Do not close the issue until the author is answering
• Issue could be closed in 48 hours if the author do not provide any answers

Or something like that.

[kof]

We can always continue the discussion on a closed issue, closing means only that there are currently no actions planned. If I wouldn't a discussion I would lock the conversation.

[kof]

For e.g. we have jss-vendor-prefixer for prefixing values and we have javascript to use any color library we want, I am using this one, postcss-write-svg and postcss-inline-svg don't make any sense, we can use string template or even import svg as a string.

[kof]

Big differences between jss and postcss are:

1. JSS is designed to work at runtime in the first place, on the server second.
2. JSS tries a more functional API from the user standpoint, its not a new language. We try to use javascript features to produce CSS. PostCSS tries to enhance the CSS as a language, like babel. Lots of postcss plugins don't make any sense in JSS, especially syntactic sugar plugins.

[DenisIzmaylov]

Thank you for sharing your point. But in the same time it seems we have to think and to care about new users which could migrate from PostCSS, styled-components and so on.

In other words we should help to reduce any costs for this migration. It means any migration process should be smooth, step-by-step, etc. Otherwise it will be very expensive for the project budget and reduce JSS users. But by increasing the users is important goals. It we'll improve the quality. A lot of solutions are dead just by the one reason - they did not have a right promotion.

So it would be great if:

• We will not limit anybody.
• We will provide opportunities for end-users.
• We will cover as much use cases as it possible.
• We will add any "killer features" which could increase users base.
• All activities in GitHub Issues will be more kind-friendly, predictable, expected and polite.
• We will extend requirements - if someone do not use SSR it doesn't mean that SSR is something not important. It's actually really important for a wide range of commercial products. I've already explained that in my talks. I meant runtime and server side should be important both.

Sorry, if I understood something incorrect.

[kof]

Thank you for sharing your point. But in the same time it seems we have to think and to care about new users which could migrate from PostCSS, styled-components and so on.

It will mean: rewrite and learn how to do those things in cssinjs. It doesn't mean they can run a magical script and migrate everything easily.

We will not limit anybody.

Constraints are the reason why one lib is a good fit for a particular task. If you have any specific things you want to add, feel free to create a separate issue for a very specific idea.

All activities in GitHub Issues will be more kind-friendly, predictable, expected and polite.

Does this mean my wording is not polite?

Thanks for your feedback, its mostly correct, but very philosophical. The only thing I can tell is that supporting all PostCSS plugins is a very hard task, which will require a complete rewrite. Also I act almost always upon specific feature request. Otherwise it ends up being useless, because we have no one to validate the quality of what we would do.

[kof]

Btw. I someone REALLY wants postcss in jss at runtime, I could write a plugin, which will use the original postcss + allow to use any plugin. But the performance cost would be big + much bigger library size. I would do it or help doing it once at least 1 person has a valid use case to do so and asks.

[iamstarkov]

@DenisIzmaylov here we go https://github.com/lttb/babel-plugin-prejss

[iamstarkov]

dropmic

[kof]

Its only for preprocessing, but yet it gives you everything from postcss.

[kof]

Means one can't regenerate the styles created on the server differently, for e.g. if postcss rtl plugin has been used, you can't switch back to ltr at runtime, like it would be with a native jss plugin, but yet I guess it might be useful.

[DenisIzmaylov]

@iamstarkov commented 9 hours ago: DenisIzmaylov here we go https://github.com/lttb/babel-plugin-prejss

Yep! I've asked Artur to publish it yesterday. :)

On previous week we've started to make jss-from-css adapter which has been originally based on styled-components:

• https://github.com/axept/jss-from-css

We used stylis.js like styled-components for preparing plain CSS from SCSS. For transforming plain CSS to JSS we used reworkcss. It's isomorphic and now you can use it as:

npm install jss-from-css --save-dev

There was one problem - performance issues on client-side because we have to parse CSS.

To solve it we create the task about babel plugin:

• https://github.com/axept/jss-from-css/issues/1

It was good news from Artur yesterday.

Now, when we solved performance issue on client-side transformation, we focused on PostCSS version to keep it integrated on both sides with prejss:

• https://github.com/axept/jss-from-postcss

It means this PostCSS adapter and prejss babel plugin could be used together to keep the application code isomorphic:

• On client-side PostCSS styles are converting to JSS by babel-plugin-prejss
• On server-side PostCSS styles are converting to JSS by jss-from-postcss

[kof]

On client-side PostCSS styles are converting to JSS by babel-plugin-prejss

This happens also on the server during the build, no?

[DenisIzmaylov]

With using babel plugin - yes - it's happening on server side during build stage. In this case on client-side we'll get a compiled callback function in final bundle which returns a plain JSS object.

On the server side we have this compilation on module execution stage (when a module is requiring).

This solution should be total replacement for styled-components. Or we missed something which still is good in SC and do not present in JSS?

[kof]

Further discussions reg. styled-components api here: #341