Create-react-app: Optional Sass Support

[sgriffey]

Note from Maintainers

We now have official Sass integration documentation.

---

Would be nice to include CSS compilers such as: Sass, Less, Stylus, or even CSS modules, etc.

[mxstbr]

I'm not sure we want to make anything optional, in the sense of having people choose between multiple options. We went down that route for generator-keystone and it's _really really_ hard to maintain.

What you have in create-react-app at the moment is a solid, unopinionated base to just get started™. If people want to add more advanced features they can always eject! (or choose a boilerplate 😉)

[gaearon]

I see where you’re coming from but I’d like to learn more about your use case for Less / SASS in React. With components and a BEM-like convention, many their features are actually not that useful.

The only one I can think of that I’m truly missing in this setup is the ability to share constants across files. This is useful e.g. for color themes. But there is an escape hatch even for this: you can use JavaScript styles (or just inline styles) and then import those values.

What other features are you missing?

[appjitsu]

• No Testing
• No LESS or Sass support
• No Hot reloading of components

So how is this project useful if you still have to add these things to ease your development?

[sgriffey]

Perhaps just adding recipes or documentation for various customizations, like Sass or test runners, using the eject is simple enough and does not require making the project opinionated.

This would help beginners (like me) be able to step their way to something more complicated.

[gaearon]

So how is this project useful if you still have to add these things to ease your development?

We’re sorry if it’s not useful to you yet. We think that many people learning React would appreciate even the current feature set.

Please let’s keep this issue focused on Less/SASS, not on other issues. You can discuss testing in #80. Hot reloading of components won’t be supported until I figure out how to make it more stable (I’m the author of React Hot Loader). I fully intend to work on this, but there are more pressing issues.

Thanks!

[sotojuan]

@appjitsu This project isn't made for you then—it's just the basics to get started with a basic web app for demos and learning the basics of React. This isn't ember-cli for React.

There's plenty of awesome projects in that vein like @mxstbr's boilerplate. The simplicity of this project is the best part about it.

[appjitsu]

Sorry. Don't take my comments as being rude. I think this is a fantastic project.

Although, I do view each of those features to be critical for ease of development.

On Jul 22, 2016, at 12:50 PM, Dan Abramov [email protected] wrote:

So how is this project useful if you still have to add these things to ease your development?

We’re sorry if it’s not useful to you yet. We think that many people learning React would appreciate even the current feature set.

Please let’s keep this issue focused on Less/SASS, not on other issues. You can discuss testing in #80. Hot reloading of components won’t be supported until I figure out how to make it more stable (I’m the author of React Hot Loader). I fully intend to work on this, but there are more pressing issues.

Thanks!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[appjitsu]

Well OK then! Thanks! 😄

On Jul 22, 2016, at 12:53 PM, Juan Soto [email protected] wrote:

@appjitsu This project isn't made for you then—it's just the basics to get started with a basic web app for demos and learning the basics of React. This isn't ember-cli for React.

There's plenty of awesome projects in that vein like @mxstbr's boilerplate. The simplicity of this project is the best part about it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[sotojuan]

@appjitsu Didn't mean to sound like I thought you were rude, sorry 😄

Those features are definitely awesome for development and production, but this is for learning and demos (for now at least). Give it some time.

[gaearon]

^^ good discussion but let’s focus on Less/SASS in the future comments 😉

[thecodegoddess]

SASS would be awesome to have available. I absolutely would have used it today for a project had SASS been available.

[sotojuan]

My issue is that if you allow Sass, you'll get "where's PostCSS/Sylus!?!?!?!". It's a can of worms you have to open carefully.

[gaearon]

@thecodegoddess What features of SASS do you use most often that you miss in regular CSS?

[thecodegoddess]

@gaearon It's more that is what our current architecture is using. I know that you can get away with PostCSS for much as well. Mostly, we have variables and mixins that we are currently using.

[appjitsu]

It would be great to have option from the cli when you first create the project. Similar to yeoman generators.

On Jul 22, 2016, at 1:11 PM, Juan Soto [email protected] wrote:

My issue is that if you allow Sass, you'll get "where's PostCSS/Sylus!?!?!?!". It's a can of worms you have to open carefully.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[sotojuan]

Sure, adding a flag (--sass) is easy but again, what will Facebook do when Stylus/Less/PostCSS people complain? Supporting all CSS preprocessors isn't fun and having the user config their own kinda defeats the purpose of a no config project (and technically the flag is configuration!).

[gaearon]

@thecodegoddess

This makes sense, thanks. For now we want to focus on making this useful for new projects because there are all sorts of conventions in old codebases that would be tricky to support. But I agree we need some solution for variables (postcss or otherwise).

Supporting all CSS preprocessors isn't fun and having the user config their own kinda defeats the purpose of a no config project (and technically the flag is configuration!).

Yep.

Not adding flags or configuration options is a hard constraint of this project in the coming months. We might revisit this later.

[roebuk]

I know people in the SASS / LESS camps might not be too supportive of this, but here goes.

This project currently uses Babel to ensure that all ES2015 and ES2016 features are supported. So, were ensuring that we the latest JS standards even though the browser support may not be there. So why not take the same approach with CSS and add officially add support for css-next?

[gaearon]

I thought about css-next but there’s a _lot_ of stuff there. The direction seems valid though.

The most conservative thing we could do is add support just for variables. But obvious we’d need imports too.

Whatever we add, it needs to be rock-stable. I’m worried about issue lists like this: https://github.com/postcss/postcss-import/issues.

[fedesilvaponte]

I can see in the documentation that it says "currently not supported". Is there a plan to add that or the idea is just to eject and customise it after? I'll be glad to help on finding a solution if the decision is not yet clear.

[gaearon]

We want to wait and see, and most of all we want to understand what problems people are solving with Less/SASS in new React apps today. Perhaps there are other, easier solutions.

[fedesilvaponte]

I understand your concerns, but in my case sass it's a default. It's not about solving a particular problem, It's just part of my workflow. Just to be clear, maybe the purpose of this tool is not to address every case, but it looks so clean and cool that it saddens me I have to eject and pollute the whole app just to get sass support. I'll be following the development of this tool either way because I think it's great. Thanks.

[gaearon]

Got it, thanks for your perspective. We understand people might be used different tools, but we can’t implement support for them _just_ because of that, as we wouldn’t have good rationales for why some tools are supported and some are not. Then we have 10 different supported tools, and we aren’t sure if they all work, and we need to do a lot of extra work if some underlying tech (like bundler) changes.

I hope this gives you some perspective on why we’d rather avoid adding anything that can be solved by existing means.

[appjitsu]

http://developer.telerik.com/featured/why-bootstrap-4-means-sass-has-won

[gaearon]

There is a project called React Bootstrap, does it use either? cc @taion

We shouldn't just do something because Bootstrap does it. Components change how you think about modularising UI quite a lot. So constraints in which Bootstap is operating are not the same as constraints you meet developing React apps.

You should be able to use Bootstrap in React projects, sure. This doesn't mean that something that "won" for Bootstrap is necessary for a React project.

PS I would like further messages in this thread to focus solely on features of Less/SASS that you feel components + CSS don't solve well. Let's not just argue "what is better" because it doesn't help us to make any decisions. Thanks.

[appjitsu]

Obviously. And it would be pointless to list the benefits of one or another here. That is well documented all over the internets. My point was that if you were to choose one preprocessor, SASS is the clear "winner", because of adoption. If facebook doesn't want to choose, then let us choose.

[taion]

React-Bootstrap just provides React components. We don't ship any of the styling. In cases where I use React-Bootstrap, I pull in Bootstrap via npm, and use less-loader in my webpack config. In general, users of React-Bootstrap will need to provide the Bootstrap CSS somehow, but we don't care how.

But if you want to talk more broadly about Less, Sass, or cssnext, my feedback would be:

1. In practice, Sass makes more sense than Less; Sass seems to have effectively "won"
2. Sass is much more user-friendly than cssnext
   
   
   
   1. The cssnext variables syntax is verbose to the point of being painful
   
   
   2. Your app doesn't have to be very big at all before mixins are very useful (e.g. style variants for buttons), and they're not in cssnext
   
   
   3. If you use CSS modules, then you _will_ hit https://github.com/webpack/extract-text-webpack-plugin/pull/166, and anyway the way you do composition and components with CSS modules is actually radically different from how you normally do CSS
   
   
3. You _can_ pull together a bunch of PostCSS plugins to make something Sass-like, and @jonathantneal's PreCSS actually gives you that, but then effectively you're shipping something like Sass, except less popular and less familiar to users

Given all that, my recommendation would be to bundle Sass support. I don't think the PostCSS-based ecosystem is sufficiently mature to offer a good option in the context of a project aimed at developers who want an easy way to get started.

[gaearon]

Ah, got it, thanks for clarifying.

[taion]

And I'd be totally fine with pointing users of React-Bootstrap at bootstrap-sass instead of the Less version if they're trying to use React-Bootstrap with create-react-app.

[appjitsu]

@taion Exactly.

[fedesilvaponte]

@taion Good arguments.

@gaearon Would it help if some of the people here wanting this support offered to maintain this particular feature?

[jxjj]

Personally, I prefer Sass, but I'd be open to anything that allows math and variables in stylesheets. I'm pretty new to React, so maybe there's a more standard React-way to do these things. Perhaps some links in the README is all that's needed.

[gaearon]

What do you use math for? Layout, color tweaks, something else?

[taion]

CSS calc is already supported in every browser that React supports, though, no?

But writing e.g.

border-radius: calc(var(--height) * 2)

feels awful compared to writing

border-radius: calc($height * 2)

[jxjj]

@gaearon I use math mostly for layout and color. Though, I usually use Sass functions for color math.

@taion Agreed.

[mxstbr]

@taion gotta play devil's advocate here:

It doesn't matter if it feels awful, that's what people are going to use in a few months/years time! It's a standard, whereas Sass is custom sugar on top of CSS.
Including CSSNext is like including Babel, including Sass is different.

[ro-savage]

This project feels a bit confused.

If the goal is to make it as easy, and less configuration as possible to get into the ecosystem. Including Sass support makes sense, because it is highly used already and entirely optional. It doesn't harm anyone, and anyone who wants to remove it to optimise their build process is going to eject anyway.

If its to create a 'best practice' project, then it should be what fits in best with the react ecosystem and 'react-way'. Which is my opinion is CSSNext (React - It's just JS / CSSNext - It's just CSS) but is really for the React community/team to decide.

There just isn't any real projects out there that would use straight CSS unless they are doing it for some weird optimisation/capability reasons. You are therefore forcing anyone doing something than 'trying it out' or following a tutorial eject.

[taion]

cc @jquense who I'm sure has opinions on this

@mxstbr

It's true that cssnext is "special" in that sense, but I think unlike e.g. ES2015/ESNext v CoffeeScript, cssnext is meaningfully worse to use than Sass. For example, we deliberately switched away from the cssnext variable syntax toward the Sass-style one, because the cssnext variable syntax is awful, and assuming you'll be running some sort of build step on your CSS, it'd be a bad choice to go out and use it.

I _wish_ someone told me before I started building stuff with cssnext that, actually, the cssnext syntax stuff is just way, way worse than Sass, and that I should have just used either Sass or PreCSS instead.

[taion]

And the cssnext color function spec is, like... I understand why it is that way, and it is that way for a good reason, but:

1. It's bad DX for color(red lightness(+10%)) and color(red lightness(+ 10%)) to do dramatically different things (and you almost always want the latter)
2. But DX aside, you'd always prefer to evaluate the above at build time rather than at runtime anyway, whenever possible

[taion]

BTW: http://cssnext.io/it-s-cssnext-not-CSSNext/

I think cssnext is a great, well-intentioned project, just as Babel is. The problem isn't cssnext; the problem is that, for reasons that I think are somewhat distinctive to styling, most of the upcoming spec functionality implemented by cssnext is much worse than that in Sass-like frameworks.

I can't see why anybody with a build pipeline would want to write var(--button-height) rather than $button-height, or choosing a color modifier syntax where if you accidentally write color(var(--my-color) lightness(+10%)), you end up setting the lightness to 10% rather than increasing it by 10%.

</rant>

[jquense]

To pigback on @taion's point, the big reason cssnext isn't worth its is it's features are intentionally (in most cases) not actually polyfillable. The value-add of many these new features is that they offer something that a preprocesser cannot, which is awesome, except that it most neuters the usefulness of something like cssnext. What you get instead is something with the same potential abilities (things that can be polyfilled) as SASS but with a DX and syntax and such that is far inferior to SASS/LESS.

That added with the fact that it doesn't really even future-proof you, because its not to spec in some cases, and for a bunch of features you would never actually write them the polyfilled version (like custom properties). Not to make sweeping generalizations but I don't thin things like SASS are not going away _any_ time soon

[kasperpeulen]

CSS variables are already supported by all browsers except IE and Edge according to this chart:
http://caniuse.com/#feat=css-variables

To me, it seems silly to use sass variables, if most browser support other variable systems natively.

At this moment, I'm making an chrome extension, so actually, in my project I can use css variables today together with react-scripts. And they work fine. Okay, the syntax is not that pretty, but Webstorm (other editors probably as well) provide good autocompletion and lints.

You can also edit the variables in your chrome dev tools. I'm not seeing your problem @taion Is it just syntax?

[jquense]

@kasperpeulen thats really poor browser support for anyone who is making an app that needs to support windows or mobile users :P.

[kasperpeulen]

@jquense Yes, sure, perfect for a chrome extension though. What I mean, 2 years ago, things like coffeescript and sass totally made sense. But now that ES6 and CSS variables are supported by most browsers, I think it makes less sense to use a different syntax for css variables than the official supported syntax by (future) browsers, and use postcss so that also windows and mobile users are supported.

[taion]

One difference is that CSS isn't a programming language. Most of the "advanced" features – variables, color functions, calc, &c. – can be evaluated statically, so no matter what, normatively you want to have a build step.

Again, assuming you have a build step (e.g. because you're using CSS modules), why would you let the browser do the color math instead of doing it at build time? And if you're not going to have the browser do it, why would you choose to use a syntax where lightness(+10%) does something awful?

[giuseppeg]

@jquense while custom properties are not _transpileable_ they are still usable to implement simple variables – I agree that SASS variables alone are easier to use and I'd be fine with them (one can always refactor them with postcss/codemod).

However the point is which features and APIs to use: SASS is monolithic and opinionated, PostCSS is modular and can bring on _standard_ features.

As I see it SASS is the CoffeeScript of CSS-land, it introduced lots of awesome features and concepts and possibly influenced the standards development but at this point is not necessary anymore :)

[taion]

@giuseppeg

Certainly, and in fact we use a custom Sass-like pipeline that runs through PostCSS. If I were to build a new project from scratch, I'd probably start with PreCSS instead of Sass.

The issue is that the goal of this project is to create zero-configuration scaffolding for React applications. As such, "you can deeply customize what you do in PostCSS" is not just irrelevant but actively contrary to the intent here.

Like, it's directly contrary to the idea of being able to easily set up a real React web project if part of this is "now go choose between these dozens of modular PostCSS transforms". This project adds value by _not_ making users make choices.

[jquense]

and even moreso if its more intended for new users, the PostCSS ecosystem is on the edge, which is really cool, but not great for folks if you need good documentation or _help_. Whereas the SASS ecosystem is big, well established, and easily google-able.

For instance if you need better documentation on the css color function you probably have to read this: https://drafts.csswg.org/css-color-4/#funcdef-color

[taion]

Like, if you think about why this project is so great – Babel 6 is hugely modular and configurable and everything, so power users can do exactly what they want... but relative to the less modular Babel 5, that customizability is friction for new users.

The modularity and customizability of Babel 6 is fantastic from a technical point of view, but in the context of project scaffolding, it's a bad thing – in fact exactly the kind of bad thing that projects like "create-react-app" help to work around.

[giuseppeg]

@taion agreed but

This project adds value by not making users make choices.

I don't want to be forced to use SASS (just to mention one), also considering that the tool is for scaffolding a new project – I'll quote you – "you'd probably start with _something else_ instead of Sass".

dozens of modular PostCSS transforms

_The pro-PostCSS movement_ is asking for a few basic plugins, namely: custom properties, imports, calc, custom media queries. One can always hook SASS up later I guess.

[jquense]

I don't want to be forced to use SASS

I mean by using a tool with opinions ppl are going to by definition have to use stuff they might not choose. that's the cost of not having to choose. Given that the thing that these projects should optimize for is "best for most" and "not actively exposing more choices" to which we are arguing that postCSS is not a great choice, its not a Critism of PostCSS its just noting that it's actively trying to provide very different value than this project :P

[mxstbr]

Most of the "advanced" features – variables, color functions, calc, &c. – can be evaluated statically, so no matter what, normatively you want to have a build step.

Slight aside: Custom properties in CSS cannot be evaluated statically because they can be changed in-browser and everything that uses them will update, contrary to Sass variables.

[taion]

I know they can't strictly be evaluated statically, but they'll most often be used in a way where they could be – just with worse syntax than the Sass equivalent.

And moreover, again, our experience with PostCSS was – we started with postcss-css-variables, but ended up with postcss-simple-vars because the latter was just _better_.

So why give users something (1) worse, (2) harder to use, and (3) effectively just an arbitrary choice anyway?

[ChrisCinelli]

create-react-app is already auto reloading the CSS when index.css changes.
You can add a sass folder and an easy gulp script that watch the sass folder and rebuild the code. For example you can use this gulpfile.js:

var gulp          = require('gulp');
var sass          = require('gulp-sass');
var sourcemaps    = require('gulp-sourcemaps');

gulp.task('serve', function() {
    return gulp.watch(["./sass/**/*.{scss,sass}", "./bower_components/styles/sass/**/*.{scss,sass}"], ['sass']); //Add here your lib folders
});

gulp.task('sass', function() {
  return gulp.src("./sass/**/*.{scss,sass}")
    .pipe(sourcemaps.init())
    .pipe(sass({
      indentedSyntax: true,
      includePaths: ['./bower_components/styles/sass'], // Add here your libs
      errLogToConsole: true
    }).on('error', sass.logError))
    .pipe(sourcemaps.write())
    .pipe(gulp.dest('./src'));
});

gulp.task('default', ['sass', 'serve']);

That is what we use at our company.

We started with a boilerplate that used https://github.com/webpack/extract-text-webpack-plugin and https://github.com/jtangelder/sass-loader . It did not take too long with our javascript code, suzy, bourbon and our styles before it was taking 60+ secs to recompile everything and see the updates when you were saving a line in SASS!

After we switched to gulp for CSS, it takes less than 2 secs and we decoupled the JS and the CSS compilation process.

[chantastic]

Personally, I'd like to see this project remain un-opinionated about CSS pre-processing.

Components + CSS are highly capable. They're easily capable enough for the infant stages of a project.

Can we compile a list of Sass use-cases, relevant to the scope of project like ceate-react-app? I'd be surprised if most couldn't be solved with component-based thinking.

[just-boris]

Another use-case that still haven't mentioned: nested selectors. I often write in my SCSS:

.component {
   /* styles for component */
   &:hover {
       /* styles for hovered component */
   }
}

It looks pretty neat and you don't need to type main class name several times.
This is the main reason, alongside the variables, why I add preprocessor in every my new project.

[taion]

Sass support here wouldn't force users to use Sass – it would just allow them to use Sass without extra work.

Per:

We expect that at early stages, many people will “eject” for one reason or another, but as we learn from them, we will make the default setup more and more compelling while still providing no configuration.

"Just plain CSS" with no preprocessing or postprocessing is not a good way to build anything nontrivial.

The blog posts suggests that this project is intended as more than just scaffolding. Right now, any user that wants to do anything non-trivial with styling is forced to eject. Presumably that's not desirable.

[mxstbr]

Presumably that's not desirable.

Absolutely correct! Which is why it's good to have this discussion about what we're going to include. :blush:

I haven't really seen a good reason to include Sass yet though. (except "It's popular", which isn't what this project is looking for)

I'd much rather go with a component-based styling model since that is what I think the react community will converge around one way or another. The mental model of components is awesome and a big part of what made react popular. Styling is not exempt from that, component-based styling is :+1:

I don't care if that's CSS Modules, JSS, Aphrodite, jsxstyle or whatever you want as long as it fits the mental model of react. Sass doesn't do that, it's "just" popular syntactic sugar as far as I can tell so far.

[lacker]

It seems like you can add Sass support pretty easily with a solution like https://github.com/facebookincubator/create-react-app/issues/78#issuecomment-234739359 . That seems pretty nice because you aren't changing anything about how create-react-app behaves - you're just adding an extra gulp task to convert your sass into css. It's not quite as nice as using a webpack loader directly, but if you want that you can still eject. Since it's not that hard to use Sass in conjunction with create-react-app, I don't think we need to add extra support.

[taion]

@mxstbr

It's not just a matter of popularity/stability, though. If you look at the Babel config here, it very sensibly excludes things like stage-0 and only uses a subset of stage-1. My argument against including something like PreCSS or CSS modules isn't that those are bad ideas in a vacuum – it's that they're both too bleeding edge to be something we should implicitly recommend to novice users.

@lacker

The gulp task sort of works, but it's really ugly, and it exposes users to race conditions, especially when making a production build. In practice that advice pretty much becomes "eject and add a Sass loader".

Contra

PS I would like further messages in this thread to focus solely on features of Less/SASS that you feel components + CSS don't solve well. Let's not just argue "what is better" because it doesn't help us to make any decisions. Thanks.

above, I don't think it makes sense to frame this discussion in the context of features. It's not just about the features – it's about any number of things like stability, ease of learning, popularity, &c.

That's, like, why we write JS instead of Dart, say.

[mxstbr]

My argument against including something like PreCSS or CSS modules isn't that those are bad ideas in a vacuum – it's that they're both too bleeding edge to be something we should implicitly recommend to novice users.

Fair enough if you think that way, but then let's not include anything at all since Sass isn't helping?

[chantastic]

@taion i disagree with the idea that CSS pre-processing is required for a "non-trivial" applications. thinking about architecting styles around components is just different but no less capable. Our large applications haven't written any new Sass after adopting React.

[taion]

@chantastic My experience is very much to the contrary. We're doing a from-scratch build, and if anything, we've pulled in more PostCSS transforms as time has gone on, rather than fewer – going from cssnext to essentially a discount Sass.

@mxstbr Could you elaborate on the problems you mentioned upthread in including both Sass and Less support in generator-keystone? Naively that seems like it'd just be the easiest way to go.

[chantastic]

It's an impossible discussion to have without knowing how far create-react-app is supposed to take you before ejecting.

I'd imagine that, if I was doing from-scratch work, I'd maintain my own starter—as many consultancies do.

The idea that "you have to use Sass" to ship meaningful apps is just categorically untrue. There are too many CSS approaches to be opinionated in this type of starter.

[chantastic]

The more opinionated this tool becomes about non-React workflows, the less useful it is as a starting point for React beginners.

[taion]

I agree that saying "you must use Sass" would not be good.

A strawman: ship support for Sass, maybe Less, and add a few of the most useful PostCSS transforms.

This is very unopinionated – people who like Sass can use Sass... people who don't can just go ahead and not use Sass.

Hence my question to @mxstbr.

[chantastic]

create-react-app: an un-opinionated starter-kit for CSS pre-processing exploration.

[taion]

"Unopinionated" means the user makes the choice, not the framework.

Saying "you should use raw CSS" or "you should use the following blessed set of PostCSS transforms" is just as opinionated as saying "you should use Sass".

[chantastic]

Again, this is an impossible discussion to have without defining how far the pre-eject setup should take you.

It seems unfriendly to eject and have a package.json littered with dependencies I don't want, need, or have any relevance to building the React app.

[mxstbr]

To answer the generator-keystone question:

The big problem is that it creates _a lot_, and I mean _a big lot_ of overhead for the maintainers if users have multiple options/flags. Everytime the tiniest thing changes you have to test it in multiple variations and creations. Even with the best intents and elaborate testing bugs slip through every second time. (things like this)

You also end up maintaining things you don't use yourself, which is the worst-case scenario for an OSS project imo. You'll get unmotivated to fix some LESS problem because you're using Sass and "Who's not using Sass anyway?" and then you never prioritize and get it done.

I would highly recommend avoiding the scenario of the user being able to choose. (as well as that being an explicit goal of this project)

[jxjj]

What's the most common way devs in the React community are handling component styling? Is there a best practice or "React way?" Is the issue that the React community itself is split?

[taion]

Sure, so that's really the crux of the problem.

• If you don't bundle some CSS pre-processing or post-processing, then users are incapable of following standard best practices for styling their web apps.
• If you only bundle one framework, then you are making an opinionated choice
• If you bundle multiple frameworks, then you have extra maintenance burden, and end up with extra stuff post-eject

[taion]

@geekydatamonkey

If I had to guess, Sass with BEM is the most common baseline approach. See e.g. https://github.com/airbnb/css.

Experienced/advanced developers doing greenfield projects often choose CSS modules with PostCSS, or one of the CSS-in-JS approaches like Aphrodite. This is what we do. I absolutely would not recommend this as a general approach – it's full of sharp edges that will leave cuts, and broadly requires a different way of thinking about styling, because CSS cascades largely no longer work as a tool.

One can argue, and indeed I have argued, that CSS cascading is not a "good" way to write styling rules, but these arguments are abstract, and should not be taken as normative for what generally accepted best practices are.

[chantastic]

Right. I think we disagree on the first, which makes not adding any new dependencies the clear winner (to me).

What's wrong with create-react-app followed by an immediate npm run eject?

[taion]

Because then this package is just a very elaborate custom-built Yeoman generator.

Again, not shipping any additional CSS processing is not somehow "unopinionated". "Just use CSS" is very much an opinion, and it's not the opinion that the majority of the internet takes.

Remember that we, the participants in this discussion, are not the target audience. I'm glad you're comfortable using CSS + components. On my side, I'm quite happy with CSS modules.

That's entirely different from saying that these are reasonable as prescriptions for how people should build React apps – they're not.

[chantastic]

My opinion is formed by how confusing large dependency trees are to beginners. If this is something that is going to be marketed toward beginners, describing why the project depends on ALL css pre-processors but doesn't required them, is unfriendly.

[taion]

None of the build dependencies are visible to users pre-eject:

$ npm ls --depth 0
[email protected]
├── [email protected]
├── [email protected]
└── [email protected]

[chantastic]

Right. It's just magic, until you eject, at which point you have no idea what your code depends on. Now I have to know what packages to remove post-eject. That doesn't help newcomers learn in a progressive way.

[taion]

Yes, that's the natural tension for this sort of project.

The more you do pre-eject, the less the post-eject configuration is going to be tailored to your specific needs.

However, the less you do pre-eject, the more likely users will have to eject in the first place.

In general, "just use plain CSS" is not a particularly great recommendation for how to handle styling. Moreover to the point, though, it's also a very opinionated recommendation.

[chantastic]

How did eject get a negative connotation. It's doing a lot for you, even when you eject immediately.

Why should I expect this library to know anything but what is required to build React?

You're attempting to twist this into a discussion about CSS being opinionated. The point is keeping the core competency of a React-focused starter on React and nothing more.

[taion]

I think the distinction you're speaking to is the one between the minimum _usable_ scaffold and the minimum _useful_ scaffold.

Consider hot reloading via React Hot Loader, for example. Per discussion in https://github.com/facebookincubator/create-react-app/issues/93, it looks like the intention is to add it to this library. I think that's a good choice, because RHL is very useful.

What it isn't, though – it's not in any form a _requirement_ to use React. If I were scaffolding a minimal React application by hand, I would not use React Hot Loader. If I eject, React Hot Loader is an extra dependency that your hypothetical user would have to find out about.

[chantastic]

RHL is one package that—in fact—is related to React. You're talking about adding Sass/Less/Stylus/PostCSS/etc all for the benefit of being un-opnionated. It's sprawling.

[chantastic]

In any case, I find the discussion uninteresting. I'm going to eject myself from it.

[lacker]

Now that CONTRIBUTING.md states "If the community is split between different tools, we won't just pick the least controversial or most popular, the tool itself should be agnostic between them." I think the current philosophy to not support any particular css preprocessor is clear, & I think this discussion has gotten distracted, so let's close this. We can always rediscuss later if something changes.

[ChrisCinelli]

I agree with @taion on this:

Again, not shipping any additional CSS processing is not somehow "unopinionated". "Just use CSS" is very much an opinion, and it's not the opinion that the majority of the internet takes.

For me how to start with React has never be . The problem has been "what is the best starting point if I want server side rendering, SASS, hot-reloader, being able to use ES6 npm modules with npm link, great logging and keep a great development speed?".

I think who comes to react, unless they are starting web development from sketch, is looking a way to plug some of the tools they are familiar with. CSS pre-compilers are some of them.

I saw too many boilerplates. It is no easy to say this is the "best one" especially when I was new to react . I think that a repo like this backed up by Facebook has the potential to become "the" reference tool.

At the same time I think people should have an easy path to add the tools they like.

Having options is not a problem. The problem is having too many options that lack documentation and having to spend days to make the system work the way you want it.

[Lakston]

I think I am part of the targeted audience for the creat-react-app as I started trying to learn react less than a week ago. The config part is pretty overwhelming and when I saw the announcement a couple of days ago I immediately started a new project to try yesterday.

After 20 minutes I was already wondering "Ok, how can I use sass (and pug) with this ?" so there you go, a newbie experience.

I will however add that I completely understand the desire to stay un opinionated and a lot more feedback from new users should be reviewed before taking such decisions.

I ended up ejecting just to take a look under the hood and felt a bit overwhelmed by it. Now I'm wondering if learning everything from scratch wouldn't be better since I would have a better understanding of what is going on and I could set up my project to support the tools I use most (sass/pug).

The good news is that in less than a minute I had a react project running so I can start messing with it and for that the creat-react-app is awesome and does what is advertised, the bad news is that it also feels like a sandbox where I can play but if I want to develop something I'll have to learn it all from scratch anyway.

[mxstbr]

That's excellent feedback @Lakston, thanks so much for taking the time to post that!

[gaearon]

By the way, as we said above, we are open to learning why you find SASS useful in your projects (apart from habit). Since this issue has become a little bit too broad, perhaps it’s worth creating another one where we specifically collect SASS features that you find useful in React projects.

[taion]

@gaearon

I can speak to this a bit. For the main project we're working on, we've migrated from "just plain CSS" to "CSS modules with cssnext" to "CSS modules with a heavily Sass-like scheme".

First, my experience with CSS modules leads me to recommend against either CSS modules or CSS-in-JS in this sort of context. Modularized CSS is awesome, but it works very differently from normal CSS, and has enough sharp edges that "using properly modular CSS" is very different from and not a strict requirement for "using React". They go great together, but it's definitely advanced right now.

In terms of specific features that we make use of:

• CSS variables/custom properties: these are immensely useful for e.g. defining a set of theme colors and using them consistently throughout our web app. Specifically, I'd like to highlight the Sass-style $variable syntax as being much more usable than the custom properties var(--variable) syntax. I can't really explain it, but the advantage in usability of the former is much more than you'd expect.
• Color functions: This links directly to the above – we define some theme colors, and want to use a consistent set of variations in brightness for things like borders, shadows, &c.
• Mixins: Again this connects to the above – for things like defining a consistent set of style variations, e.g. different style variants for buttons, like if I have a confirm button that I want to be green, a delete button that I want to be red, &c., but keep a consistent relationship for use of gradients, shadows, &c.
• Nested selectors: Again just a usability thing... it's way nicer to nest .child under .parent than to do .parent .child... even moreso for defining :hover, &c. pseudo-classes. Here I actually do think the cssnext syntax is nicer than the Sass syntax, but the transform has _significant_ problems in working with invalid selectors like &-bar and & + &

[taion]

BTW, I don't think the issue count on postcss-import is representative of the stability of that plugin (and more than, say, facebook/react's issue count is representative of React's usability 😛). I haven't had any bad experiences with it.

v8.x introduces some interesting complications from async processing, but they haven't caused me any problems in practice, and otherwise v7.x is rock-solid.

[taion]

Though to continue on this note, the biggest problem with the PostCSS transforms isn't stability – it's that they allow spec-incompliant things that are very tempting to use.

For nesting as above, we found ourselves actively wanting to use selectors that don't work like &-bar and & + &. Currently, the plugin transforms that into something that does in fact "work", but per the spec they shouldn't.

This comes up for the color function stuff too – right now, color(red lightness(+10%)) will increase the lightness by 10% as a user would naively expect, but per the spec this should _set_ the lightness to 10%, and the correct form for what almost everyone would want here is actually color(red lightness(+ 10%)).

[gaearon]

Thank you very much for the context, this was super helpful. We’ll keep this in mind, and will be referencing this issue when making decisions in the future.

[taion]

Pardon the logorrhea on my part – on PostCSS, to summarize, we've found the stability just fine. The issue instead is that with the cssnext stuff, it's very easy to write CSS that is badly broken per spec but will right now get processed into something that works.

This is fine for advanced users that are willing to go the extra mile to make sure they're not writing spec-incompliant CSS that still happens to work in cssnext, but to me seems extremely dangerous for general use – like a repeat of the Babel 5 decorator thing, but worse.

[timarney]

First off I would love to have Sass support out of the box. Adding a loader doesn't opt anyone into using Sass - if a Sass file exist it gets parsed.

Looking at this post from @tylermcginnis https://medium.freecodecamp.com/create-react-app-and-the-future-of-creating-react-applications-3c336f29bf1c#.qky3g94y1 very small sample but the CSS comments are both questions about using Sass.

https://medium.com/@jcochran/how-do-you-integrate-sass-without-breaking-things-692dc7c2e248#.5my51vm77

https://medium.com/@FNGR/that-sounds-really-really-cool-but-without-sass-its-not-for-me-7481a85e4283#.voixt9e0u

That said as for Less, Stylus others (likely Sass as well ... ) can they be supported via PostCss?
https://github.com/gilt/postcss-less
https://github.com/MoOx/postcss-cssnext
https://github.com/seaneking/poststylus

I have an issue open here tweaking the plugin setup for PostCSS that would handle these cases

https://github.com/facebookincubator/create-react-app/issues/171

[gaearon]

We haven’t made any final decisions here. It’s just that we think this is _currently_ out of scope, and we want to come back to this when we have time to look at CSS in React more holistically.

In the meantime you can always use a console SASS tool that outputs .css files right inline, and put *.css in .gitignore.

[taion]

I think this might be a good place to consider adding some customizability.

Ultimately, the choice of CSS framework is mostly orthogonal to the tooling complexity in setting up React.

I think giving a very limited set of choices for mostly orthogonal things like the choice of CSS framework would be a value-add here.

[doodirock]

I have to say I don't really like the idea that SASS isn't being considered "just because people use it." I fully understand that you are trying to find out "why" people want it included before you decide what to do. However, I would ague that because so many people use it, is really just as valid of a reason.

If the goal of this project is to help beginners, then I would suggest most beginners out there probably have spent a lot of time in the world of SASS over the last few years on the web. These newer concepts for CSS are great, but for most people SASS is what they know. So by limiting these people to either new concepts or plain CSS you limit the goal of the project.

Just my thoughts.

[gaearon]

Just to make it clear, you can use SASS with this project if you want to.

If you’re used to SASS, you’re also probably used to launching it in the console and letting its watcher compile the SASS files. So this is exactly what you can do:

1. Put *.css into .gitignore
2. Create *.sass files instead of *.css
3. Launch the SASS watcher and let it create the CSS file(s)
4. Import that *.css file(s)

Yes, this is a bit of extra work, but it’s perfectly doable.

[just-boris]

@gaearon there is some important issue with your solution: you can't run the whole your development environment with a single npm start, you would have to run sass-watcher as a second process.
That probably will be blocker against doing this.

[mxstbr]

That probably will be blocker against doing this.

How is opening a second terminal window a blocker? 😃 It's CMD + T and then npm run sass, that doesn't seem like a blocker!

[gaearon]

You can also change your start command to start the SASS watcher before react-scripts start.

[just-boris]

@mxstbr let's say it like I have to open twice more terminal windows than before

@gaearon if I do this:

node-sass --watch --recursive src & react-scripts start

Then I will not be able to stop node-sass because it will be in background.

[gaearon]

There are workarounds to that too.
(But it might be easier to write your own Node script that spawns both.)

[just-boris]

@gaearon thank you, that probably solves my issue

[giuseppeg]

@just-boris you can define pre and post scripts in npm that will run before/after a given script e.g. start.
FWIW you can bring up processes that are running in background with fg [ jobid ] and eventually kill them with ctrl+c

[poksme]

The node-sass watcher in the background with its pid in a variable for cleanup on ctrl+c is a really clean solution.

I also recommend using node-sass binary from your node_modules folder to avoid global dependency.

Another thing to keep in mind is that the --watch option prevents node-sass to compile unchanged files on startup hence the need of a compile-sass rule for initial compilation.

My npm scripts rules ended up looking like this:

  "scripts": {
    "dev-server": "node ./scripts/start.js && kill $WATCH_SASS_PID",
    "background-sass-watcher": "./node_modules/.bin/node-sass --watch --recursive src -o src & WATCH_SASS_PID=$!",
    "compile-sass": "./node_modules/.bin/node-sass --recursive src -o src",
    "start": "npm run compile-sass && npm run background-sass-watcher && npm run dev-server",
    "build": "npm run compile-sass && node ./scripts/build.js"
  },

[yordis]

My 2 cents in the discussion.

The only thing I will support having by default is cssnext just because at the end of the day we are writing CSS from the specs.

[brianberlin]

My workaround uses node-sass and concurrently. Install both as a dev dependency and modify your start script to ./node_modules/.bin/concurrently -r './node_modules/.bin/node-sass src -w -o src -r' 'react-scripts start' I'm surprised how well this works. If it fails to compile, the error stays in the console until the error is cleared and I found that by adding -r to concurrently it doesn't mangle the original colors.

[iRoachie]

Is there any reason flags can't be supported. For instance create react app --sass. There's no harm in having the option and it wouldn't make the project confusing for new people. Those that want sass, just add the flag. Most dev cli's have flag options for additional functionality.

[gaearon]

This is my personal opinion so please don’t take this as an official position of React team or something like that. Here goes.

Adding any flag explodes the number of possible configuration we need to support. The day we add less-loader and sass-loader, many of these issues will become _our_ issues because they affect our users in the configuration _we_ recommended:

• https://github.com/less/less.js/issues
• https://github.com/webpack/less-loader/issues
• https://github.com/sass/node-sass/issues
• https://github.com/jtangelder/sass-loader/issues
• https://github.com/webpack/css-loader/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20modules

We take issues in the underlying libraries very seriously. We follow up with them and make sure they get fixed, fork or replace the dependencies, if necessary, so that our users have the best experience. But we are not ready to officially support the spectrum of CSS transpilation alternatives.

Unlike, for example, Babel plugins, we don’t use SASS or Less at Facebook, so we have no idea which issues are affecting the users, and would not be able to allocate enough time and effort to fix them.

Unlike with webpack, we wouldn’t get to constrain the features you use to a tightly controlled subset so that we could ensure they work well together.

Additionally SASS (the most commonly requested tool in this thread) is a wrapper over a native binary written in C/C++ which adds more rare but complex issues that we wouldn’t be able to help anyone with. If you never had any issues with these tools, it’s great. It is however not cool if somebody attempts to run a React example built with an official React toolkit, and they get a segmentation fault.

At this point in time we are going to keep treating CSS transpilation as a problem outside of CRA concern. As demonstrated above you can use SASS/Less or something else in a CRA pre-ejected app if you treat .css as a compilation target that you import, and have a SASS/Less watcher running in background, just like this worked before Webpack. But we are not ready to recommend either of those solutions officially, even as we understand that many in the community use them.

Also, as I said previously, we intend to look into this space (styling in React) later this year. If our effort is unfruitful, we might give in and enable SASS/Less by default, but this will require Create React App to further mature and prove its value anyway.

Let’s revisit this topic in the beginning of 2017.

[gaearon]

We now have official Sass integration documentation.
Feel free to contribute if something is missing!

For now I think this is enough, and covers the use cases most people have.

[gaearon]

We're exploring a tighter integration in the spirit of what most people in this thread wanted (just import it and it works). But we'll need some changes on sass-loader side to make this happen. If you're interested, please subscribe to this discussion: https://github.com/webpack-contrib/sass-loader/issues/532.

[gaearon]

Sass is now supported.
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html