New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PostCSS plugins adapter #427
Comments
@DenisIzmaylov wanna explore options and contribute? |
do you need rtl? and jss has plugin for autoprefixing |
PostCSS produces the AST, currently JSS doesn't have one. |
I will wait with this until there is a specific case. From my experience 95% of things people need are already in place. |
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. |
Also you don't need all postcss plugins in jss, those 2 have partially very different goals. Only some plugins are really useful. |
Thanks for attention. There is a lot of sugar and "nice to have" plugins which could be ported to JSS.
Almost all of those plugins could be used "AS IS". Bonus point: I think we have to define rule:
Or something like that. |
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. |
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. |
Big differences between jss and postcss are:
|
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:
Sorry, if I understood something incorrect. |
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.
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.
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. |
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. |
dropmic |
Its only for preprocessing, but yet it gives you everything from postcss. |
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. |
Yep! I've asked Artur to publish it yesterday. :) On previous week we've started to make We used stylis.js like 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: 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 It means this PostCSS adapter and
|
This happens also on the server during the build, no? |
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? |
Further discussions reg. styled-components api here: #341 |
Requirements:
Problems:
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:
The problem is that guys from PostCSS made a big vendor lock-in by using
require("postcss")
instead of dependency injection pattern.postcss
dependency in PostCSS plugins "on the fly"The text was updated successfully, but these errors were encountered: