Optional Sass Support about create-react-app HOT 113 CLOSED

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!

from create-react-app.

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 webpack-contrib/extract-text-webpack-plugin#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.

from create-react-app.

@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.

from create-react-app.

@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 & + &

from create-react-app.

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

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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?

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

@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.

from create-react-app.

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.

from create-react-app.

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)

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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 😉)

from create-react-app.

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!).

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

@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.

from create-react-app.

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.

from create-react-app.

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

from create-react-app.

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.

from create-react-app.

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>

from create-react-app.

@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.

from create-react-app.

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.

from create-react-app.

Presumably that's not desirable.

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

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 👍

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.

from create-react-app.

It seems like you can add Sass support pretty easily with a solution like #78 (comment) . 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.

from create-react-app.

@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.

from create-react-app.

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

from create-react-app.

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

from create-react-app.

@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.

from create-react-app.

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.

from create-react-app.

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?

from create-react-app.

• 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?

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

@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.

from create-react-app.

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

from create-react-app.

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

from create-react-app.

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

from create-react-app.

@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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

Ah, got it, thanks for clarifying.

from create-react-app.

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.

from create-react-app.

@taion Exactly.

from create-react-app.

@taion Good arguments.

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

from create-react-app.

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.

from create-react-app.

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

from create-react-app.

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

@taion Agreed.

from create-react-app.

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

from create-react-app.

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

from create-react-app.

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?

from create-react-app.

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

from create-react-app.

@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.

from create-react-app.

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?

from create-react-app.

@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 :)

from create-react-app.

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

from create-react-app.

@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.

from create-react-app.

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

from create-react-app.

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.

from create-react-app.

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?

from create-react-app.

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.

from create-react-app.

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?

from create-react-app.

@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.

from create-react-app.

@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.

from create-react-app.

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.

from create-react-app.

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

from create-react-app.

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.

from create-react-app.

"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".

from create-react-app.

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.

from create-react-app.

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)

from create-react-app.

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?

from create-react-app.

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?

from create-react-app.

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.

from create-react-app.

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

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

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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 #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.

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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

from create-react-app.

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.

from create-react-app.

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%)).

from create-react-app.

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.

from create-react-app.

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.

from create-react-app.

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

#171

from create-react-app.

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.

from create-react-app.

@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.

from create-react-app.

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!

from create-react-app.