Repository navigation
Preprocess future-proof CSS features #130
Description
Would you be open to add a few future-proof PostCSS plugins to transpile things like custom properties, calc, custom media queries?
This could be as simple as using the postcss-cssnext plugin or set up a lil preprocessor like we did for suitcss.
If there is interest I can probably help out.
Activity
mxstbr commentedon Jul 23, 2016
There's an ongoing discussion about this in #78!
The TL;DR by @gaearon about cssnext is:
giuseppeg commentedon Jul 23, 2016
That one is a more broad topic since it is about adding support for SASS/Less.
What I was asking here is if there is any interest in transpiling future-proof features like we already do in JavaScript with Babel.
Regarding cssnext, yep I agree that "there’s a lot of stuff there" – if we want to play it safe we could just add imports, variables (custom properties), calc, custom-media and autoprefixer.
Anyway I am fine with waiting and see where #78 goes.
gaearon commentedon Jul 23, 2016
We are open to add transpilation for standardized features if those tools don't have large issue lists. We don't want to recommend broken tools by default.
gaearon commentedon Sep 8, 2016
Since #78 has gone a little bit too broad, let’s use this issue for specific proposals about PostCSS plugins that are safe to enable, work great, correspond to stable specs, and give at least some of the features people want.
giuseppeg commentedon Sep 9, 2016
Stable
TBD
N.B. the plugins below don't support dynamic custom properties i.e. cp are compiled to static values.
Personally I also use postcss-autoreset and Stylelint but those require custom configuration.
MoOx commentedon Sep 13, 2016
My 2 cents:
I am myself using CSS-in-JS (via RN-web) and avoid CSS when possible.
46 remaining items
daviestar commentedon Sep 23, 2016
Thank you, I ended up using gulp to build all my non-js tasks.
For SASS, I compile to
_styles.cssat the projectsrcroot, import that css file at my JS root.. and updatenpm starttoand everything works great.
giuseppeg commentedon Sep 23, 2016
@gaearon I feel like that we can close this issue unless you want to implement this thing
tonyxiao commentedon Sep 24, 2016
@daviestar do you have one css file per component then? Or just a single massive
_index.cssfile at project root?daviestar commentedon Sep 24, 2016
@tonyxiao I put SASS files in with my components, but as I said above I don't really agree I should import them into JS as IMO, CSS doesn't work that way. I can easily avoid it by compiling all my SASS files to one CSS file at the root using gulp, then just import that so webpack picks it up in development.
tonyxiao commentedon Sep 24, 2016
Got it, thanks a pretty workable approach if you just completely avoid importing css into js. thanks for sharing @daviestar
gaearon commentedon Sep 30, 2016
Let’s close as there is no consensus and I don’t feel comfortable proceeding with this.
jonathantneal commentedon May 21, 2017
That Sassy nesting has finally been fixed.
MoOx commentedon May 29, 2018
FYI, I deprecated cssnext in favor of postcss-preset-env, you might want to think about this one that offers stages like babel-preset-env!
ai commentedon May 29, 2018
Yeap. With
postcss-preset-envwe can enable only stable CSS specs. It hasstageoption same as in Babel.gaearon commentedon Oct 2, 2018
We run
postcss-preset-envnow.jonathantneal commentedon Oct 2, 2018
I’d love to share this with my family and friends. I wrote PostCSS Preset Env, the tool you are using to future proof CSS. I hope it’s not presumptuous to ask, but might it earn a mention or thanks in the blog notes, @gaearon?
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html
gaearon commentedon Oct 2, 2018
We should probably include it into the notes. I forgot.