Feature request: Add direct PostCSS support #2878
Replies: 10 comments
-
Hey @elkevinwolf thanks for the kind words! We don't want to expose the underlying compiler because then we're locked in to it. We were able to switch from Rollup to esbuild without a lot of issue for apps. Had we exposed a custom babel config and ability to add rollup plugins, it wouldn't have been possible. While we're confident esbuild will continue to serve us well for a long time, we still aren't comfortable locking our API to theirs. So instead of just opening the whole config up to applications, we'd rather discuss which plugins to add by default. And in that spirit, I've renamed this issue. |
Beta Was this translation helpful? Give feedback.
-
We do intend to expand our built-in CSS support, but we're not sure if we want it to go through a JavaScript compiler intermediary. We might just build asset processing into We're also waiting a bit to see how the direct CSS support in esbuild itself shakes out before locking in any API here. |
Beta Was this translation helpful? Give feedback.
-
Just a nit: I'd like to go even one step further and name it something like "Add built-in PostCSS support" and leave "esbuild" out of it entirely. |
Beta Was this translation helpful? Give feedback.
-
take us to the moon @mjackson! (I've renamed it again) |
Beta Was this translation helpful? Give feedback.
-
Thanks for the feedback, @ryanflorence and @mjackson! I agree on avoid locking into a specific build system, especially for a framework that it's just starting. In the meantime, since collaboration to the repo is not possible yet, I will try to locally patch the dev compiler and maybe provide some benchmarks on this same issue? |
Beta Was this translation helpful? Give feedback.
-
I think this is fairly low priority for us unless we can find a more compelling reason to do this. Our styling guide is fairly complete right now including instructions on using remote stylesheets, local stylesheets, PostCSS, and CSS-in-JS libraries. The fact that PostCSS is treated just like any other styling solution means there's nothing new you need to do in your route modules, which is nice. It's just some setup up front. As for running two processes (one for PostCSS and one for Remix), that's also nice in the case that one process needs to be restarted or crashes for some reason. It should also mean that everything runs faster on a multi-core CPU. If having two tabs bothers you, you can always use a process manager like Probably the biggest benefit we could provide you for now would be to have a "Would you like to use PostCSS?" prompt run as part of |
Beta Was this translation helpful? Give feedback.
-
Maybe also add a "Would you like to use TailwindCSS?" and avoid PostCSS and use the Tailwind CLI, this will be way simpler since projects only need to have TailwindCSS installed. Maybe ask for the styling solution.
|
Beta Was this translation helpful? Give feedback.
-
We currently have a very large codebase with a hundreds of components written in css modules and webpack style css importing. without this support we can’t really move any of our website to remix, I really hope you guys add support! Love the tool so far |
Beta Was this translation helpful? Give feedback.
-
@ryanflorence @mjackson is there any plans to implement this? I can give a hand if needed! |
Beta Was this translation helpful? Give feedback.
-
It would be nice if Remix could support custom ESbuild plugins. In that way, plugins like
esbuild-plugin-postcss
could be included to avoid the need to spawn a second process (i.e. for compiling files from./styles
to./app/styles
) and overall project structure will look cleaner.Another suggestion could be to enable PostCSS plugin by default to offer more of an out-of-the-box configuration with optimization in mind for people who want to minify/autoprefix their CSS.
By the way, awesome project. So far I have really liked it, keep it rocking 🤘🏻
Beta Was this translation helpful? Give feedback.
All reactions