General feedback

[gaearon]

Let’s use this thread for a general discussion.

Does the flow feel good? Did we pick the right plugins, presets, and loaders? Do you see areas for improvement?

This project is in a very early stage so there’s plenty of all hanging fruit if you’d like to make React experience better.

Thanks for taking a look at this project!

[gaearon]

Eventually, yes, but this will need more thought.

[SpencerCDixon]

Are there any plans to eventually provide an "addon" abstraction like ember-cli has so that developers can build a community around the CLI or is that out of scope/not something this project should be concerned about?

[eanplatter]

There's been a little discussion on it here: #24

[mxstbr]

See the discussions in #13, #24 and #55, I don't think we want to go down the route and make this a react-cli.

[gaearon]

I wouldn’t say it’s forever out of scope but definitely not this year. 😄

[roebuk]

First off, this is a great project, thank you for creating it.

Would it be worth outputting a webpack-stats.json file for ease of grabbing the built assets by other systems?

[gaearon]

@roebuk This sounds like a useful feature but we want to limit the ways we expose webpack so we could potentially replace it in the future. I’m not totally opposed to this though, especially if there was a more widely accepted simpler standard format for this.

[PhilipGarnero]

You guys are awesome ! I started react 3 days ago. I am really upset I didn't find this earlier. So much headaches and pointless questions would have been avoided.

This is very helpful ! Especially the readme. It would have saved me so much time if I read it when I begun. Keep improving it.

Keep your mind on newcomers, they'll be more than happy with what you provide.

The only thing is that I find a bit weird that the index.html and favicon.ico files are not inside src. I would have expected the root dir to be free of any sources or resources and only have conf files. But that's just me.

[kasperpeulen]

I just wanted to say that I love love love love this 💃 👍 🍰 🎉

[gaearon]

Thank you! (By the way you didn't find this earlier because we released it a few hours ago)

[a-tarasyuk]

It is good starting point in standardization all react-boilerplate's. Thanks. I think would be very useful to have opportunity extend/override configs,. for instance for webpack, babel, eslint, and so on. I think community should discuss all features which this tool should have, and create good style guide.In my opinion we should have lightweight/extendable tool based on style guide, and extend it for own purposes

[pirelenito]

Interesting approach.

However I'm not sure it is a solution for the problem it is trying to fix. The way I see it, it is merely delaying it. As pointed by this thread, it will be much sooner than later that any project will require some minimum configuration, which will lead to an eject and the user is back to the "JavaScript fatigue" situation:

• lot of files and configurations that are impossible to grasp;
• very hard to keep the build system updated and with new fixes/improvements.

I think the problem we should try to solve are more geared towards "good configurable defaults". We sure can hide all the complexity of configuring tools behind a single dependency, but we must allow a level of configurability with formal escape hatches to disable and extend the default configuration.

Such approach does come with some drawbacks, as you will get more mileage if you stick to the proposed conventions (like the linting and the test tool), but once we look over the bike-shedding, the end result in a tool that just works.

And as has already been said in this thread, the point of such tools is not to provide a high level of customization, if you need so, you can use the underlying tools directly.

This is what I've been trying to solve in the past couple of months in a tool that I've iterated a couple of times already called Sagui. It is a single development dependency that is auto-bootstrapped (no global CLI) and provides all the requirements to build a modern JavaScript front-end application with Build, Optimization, Development Server with Hot reloading (with React support), Test, Coverage and more!

More importantly, it is already used in a couple of projects in production.

And the developers have the benefit of the continuous improvement of their working environment with a single npm install.

Would love to hear you thought on it as well, as I deeply respect your opinions! ❤️

tl;dr:

• We can't run away from configurability: embrace good defaults but provide formal escape hatches;
• Should be easily upgradeable: users can get constant improvements, like build speed, usability tweaks and bug fixes by just updating the dependency.
• Reduce context overhead and leverage npm scripts: try not to introduce another global tool;
• Don't try to create another plugin ecosystem: we already have Babel, Webpack and Karma;

@mxstbr: Your work on react-boilerplate has helped us a lot on building Sagui :)

@gaearon: You helped shape the current version of Sagui after a chat we have in React Europe, so thank you!

[gaearon]

There is a space for more than a single tool. Let’s keep learning from each other’s work!

[PhilipGarnero]

@pirelenito you should maybe try to be the next step after create react app. I'm pretty sure you could work something out with @gaearon to create a tool to migrate his tool to yours like eject but more like an upgrade.

[gaearon]

I think would be very useful to have opportunity easy extend/override configs,. for instance for webpack, babel, eslint, and so on.

Please see my reply in https://github.com/facebookincubator/create-react-app/issues/99#issuecomment-234657710.

[pirelenito]

Interestingly, I was planning to do the same thing at one point, but abandoned it favor of some simple configuration options and formal escape hatches. Maybe you will end-up on a similar situation?

What do you think is the major drawback of a tool such as Sagui?

Thanks!

[kasperpeulen]

I think there is a real need for a project like this. I would keep the configuration as minimal as possible. One good reason, there doesn't exist much (or any) project like this. Maybe someone else makes some other starter project with more config options, but I think there should be a place in the javascript ecosystem for a minimal config tool like this.

I'm learning javascript for a couple of weeks, and I'm trying to write a project in ES2015/ES2016 + react, mainly for learning.

In this process of learning, I notice that I'm 75% learning about tools, and 25% learning about actual code and writing code. When I was learning iOS in Swift, this is what much different. I think 10% was about tools, but I felt productive right from the beginning, just coding and coding. Now I'm reading manuals about webpack, babel, autoprefixer, eslint, flow, live reloading etc. etc..

I know it is all helpful, because I love writing code in ES6 syntax, and I love catching errors at compile time. I love seeing my css changes right in a second in the browser, but it takes a lot of time before I actually get to write some code.

Then with boilerplate, this helps somewhat, but I don't feel comfortable having a boilerplate where 90% of the code I don't understand what is going on. All kind of test frameworks (I haven't spend any time learning javascript test frameworks yet). Karma, Mocha, gulp, rollup, commonjs, umd, whatever, ugh ... my brain just overloaded with names ... names that doesn't say anything to me, and where I feel like I should still read more about

So yes, I used react-scripts for a couple of hours, this, and I love it, it is clean, all the code in my own package I understand, that just feels good. Okay, there is probably some magic going on that I don't understand, but that is fine. I don't understand how chrome makes my html and javascript turn into a webapp, but that is none of my business. That is chrome's business. I don't understand how react-scripts makes my ES6 code work, how it gives me compile time errors, how it imports my css using javascript import, or how it add autoprefixers to my css, but it just works. And all that is now facebook's business. I just care about how to use it. Not how they made it work.

So this is one use case for react-scripts/create-react-app, people that are learning web programming in 2016 and learning ES2015/2016 syntax right from the beginning. What this provides is way to immediately start with learning how to code and don't worry much about tools yourself.

🎶🎶🎶 Let's start coding now, everybody is learning how, come on and safari with me. 🎶🎶🎶

https://www.youtube.com/watch?v=IMChBJZUDK8

[kirkaustin]

Great project! Maintaining those configs is a real PITA. The only thing that's keeping me from embracing this is the lack of support for CSS Modules. I'm not sure I understand the objections, as it makes writing CSS rules much, much simpler for component-centric projects.

Also, I'd like more flexibility with the dev server. I'd like to add some proxy support to external web services using http-proxy, for instance.

[gaearon]

I'm not sure I understand the objections, as it makes writing CSS rules much, much simpler for component-centric projects.

Can you help me understand the problems they solve for you? Global class pollution, what else? Do you use composes?

[tlrobinson]

Overall I love the idea of this project. I was sad @petehunt's rwb didn't seem to get much traction, so I'm glad to see a more official project with similar goals.

(Cross-posting the below from a HN comment. I haven't read through all the comments, apologies if this has been covered)

I think there will always be people who want to tweak ESLint rules or enable new Babel features, but would still like to take advantage of improvements to this project.

Perhaps exposing a subset of those tools' configuration options would be sufficient.

Alternatively, you could imagine a pretty simple system that allows you to pull newer versions of the "ejected" code and handle merge conflicts using your version control software.

I'd also suggest reducing the amount of non-configuration code that's generated by "eject". I think basically everything in "scripts" could be put into a package ("openChrome.applescript" seems like it should be a feature of opn anyway). That would also reduce the number of devDependencies that need to be added to your project's package.json (rimraf, chalk, opn, etc)

[kirkaustin]

Global class pollution is the big win. Probably the best thing to happen to CSS since the beginning. Namespaces was one of the big wins when Java first appeared. I don't think anyone regrets that addition.

We have a few different groups writing reusable React components that can be shared. The problem of CSS collisions has led us down a path similar to BEM which requires verbose, nested class names.

The beauty of CSS Modules is that you not only avoid having to do that, but you end up using much simpler class names like ".icon" or ".content" which anyone can understand, not just engineers. We're trying to pull designers in the direction of using more CSS in the work that they provide, and we don't want to burden them with tools like SASS.

I haven't used composes myself, but it seems like it could be useful.

One other side benefit is that the development class names end up being verbose and easy to debug, while the production class names end up being very short and obfuscated.

[keyz]

@gaearon CSS Modules is awesome. I have an example here that might be able to show you how it works in action: https://github.com/keyanzhang/repo.cat/tree/master/src/components/Main/Filters/SingleFilter

In the CSS file I no longer need to "BEM" my CSS selectors. I can simply name a selector .link and it's guaranteed to be local to the component that imports it.

For example, let's say I have 2 components Foo and Bar. Both of them have a link that needs to be styled but the 2 links don't share the same style.

Without CSS Modules I could import './styles.css'; in each component file, but I'll need to give them different classNames like fooLink, barLink to avoid global name collision. This doesn't feel quite right to me since I need to mentally track all my components and make sure I don't accidentally use the same className for actually different things.

With CSS Modules, a class name gets renamed to something like SingleFilter__link automatically at compile time. It effectively solves the global namespace issue and enables me to think locally from a true component perspective.

http://glenmaddern.com/articles/css-modules is another great article that explains this concept.

[kirkaustin]

I think it's great that you're providing a less opinionated baseline for the configs, as I was never that comfortable with the airbnb solution. It might be worth considering allowing for some overrides, though. That way I could just add a small number of eslint rules that would be concatenated with your defaults if I wanted to customize.

[mxstbr]

It might be worth considering allowing for some overrides, though. That way I could just add a small number of eslint rules that would be concatenated with your defaults if I wanted to customize.

We've actually disabled all stylistic eslint rules, so there should be no need to add custom config. If there's a stylistic rule warning you're seeing please let us know immediately and we'll disable it with the next release. (see e.g. #157)

[kirkaustin]

Well, my point is that I would like to add my own stylistic rules. That means I would like to append those rules to the ones that are provided.

[gaearon]

Thanks, we’ll keep this feature request in mind. Unlike Babel/webpack extensions, allowing custom eslint config seems fairly straightforward and shouldn’t hurt us in the long run (I can’t really imagine we’d have a compelling reason to move away from eslint). In fact creating a custom .eslintrc that extends our config at react-scripts/config/eslint could already work. We’re not going to generate such config by default, but I think we might document a way of doing this some time in the future.

[kirkaustin]

Great, that's exactly what I had in mind.

[Ethanjfriedman]

As an instructor at a web dev bootcamp, just wanted to say this is great. 👍

The config swamp was a real hurdle for budding junior devs to get over in learning React -- understanding JSX, lifecycle methods, organizing their code into modules, etc. etc. is hard enough for someone with 2 months of coding under their belt without adding in messing around with Webpack and Babel. which topics we can layer in later.

[idibidiart]

@gaearon

What is Facebook's position on using Shadow DOMnfor CSS encapsulation? Have you seen Maples.js? https://github.com/Wildhoney/Maple.js/

Would you consider moving to this approach at some point? Or why not now? :-)

[gaearon]

We are currently not planning to use Shadow DOM actively because it’s not supported by many our target browsers and requires global configuration. We may revisit this choice in the future.

[aweary]

It'd be interesting if there was a potential extension/plugin system for creating apps with more specific use cases. Being able to do create-react-app --with-router or create-react-app --relay would be useful. Maintaining or supporting that kind of configurability might be difficult though, so an extension system where anyone could plug into the app build step and introduce dependencies/files/configuration would nice.

[gaearon]

@Aweary Please see #24

[KarolAltamirano]

Awesome project guys, thanks for creating it. I have one question about the project structure. Wouldn't it be better to have index.html and favicon.ico inside src folder? I would personally prefer to have all react app files including index.html and favicon.ico inside src folder and directly in the root folder just files / folders related to dev process even though it will be just node_modules, package.json and README.md

[mxstbr]

src contains all files that webpack treats as modules, which index.html and favicon.ico don't count towards!

[PhilipGarnero]

@KarolAltamirano @mxstbr Does it prevent it from working ?

If not, the users aren't handling webpack at all so I don't see the problem. Sure from your point of view, it seems silly but from mine, having these two files laying there feels kinda weird.

This is not an issue anyway and just a matter of preferences. If you think it is more logical that way, you're probably right.

Thanks for your job on this project, I love it.

[KarolAltamirano]

@mxstbr @PhilipGarnero Yep, it depends on point of view and from both sides it can make sense. The reason why I prefer to have everything app related in the src folder is that when I start adding files like .gitignore, .gitattributes, .editorconfig to the root folder it will just feel a bit messy to me to have somewhere between these files also index.html and favicon.ico

Anyway I got your point about webpack modules and if you think it works better the way it is right now I'm okay with it. Just wanna share my point of view on structuring projects even though it's more about personal preference than an actual issue.

[gaearon]

I would personally prefer to have all react app files including index.html and favicon.ico inside src folder

It depends on point of view. If you look at it another way, neither index.html nor favicon.ico are “React app parts”. React app starts in your root component, the rest can be thought of as host environment.

You could twist it either way though. So for now the distinction we chose is that src only contain modules (things that import each other), and anything else goes into the top level. We may revisit this later.

[idibidiart]

@gaearon

How do you approach style encapsulation for React components at Facebook? There is Radium which is for JS based style declaration and CSS Modules for creating isolated CSS scopes. Have you settled on a style encapsulation approach?

[vjeux]

@idibidiart take a look at the first part of this talk (the one about cx), this is how we deal with styles at Facebook on the web today: https://speakerdeck.com/vjeux/react-css-in-js

[mxstbr]

@idibidiart also read #78 for a (long) discussion about this subject.

[idibidiart]

@mxstbr thank you for pointing me to that discussion.

@vjeux @gaearon there is a subtlety to why something like CSS Modules (+React CSS Modules) is preferable to our (my team's) way of building apps, and it is based on some axioms our team has developed over time that are not universal.

So, at this point we're considering creating a live fork of create-react-app to add support for those tools.

Eject is an escape hatch (exactly what the name implies), not a customization option per se.

I realize what I'm suggesting is not an optimal answer but it's as close to one as we could find right now. :-)

[gaearon]

So, at this point we're considering creating a live fork of create-react-app to add support for those tools.

This is reasonable. (And we’ll keep an eye on popular forks.)

[trevordmiller]

My 2 cents on the philosophy and future of this project

TL;DR

🤘 React Create App rocks! I hope to see this project continue to be wary of "design by committee" and stick to only the officially standard tools as you have been doing :)

---

Full thoughts

I just want to give you all a great big hug :)

I absolutely ❤️ ❤️ ❤️ React Create App. It is extremely valuable to have a minimal abstraction for config so that the React team can optimize under the hood and tie all the pieces together without breaking the public API (npm start, npm build, npm run eject). Thank you so much for building it!

While reading through some of the comments on this page and on Twitter, I completely agree that this project should stick with minimal + majority use cases and not get too bloated; for example, I'm happy to see the push back that has already happened on things like CSS Modules, Radium, or other non "standard" tools. Unless an approach / tool is a "blessed" (officially supported) way of doing things by the React team, it shouldn't be included with this project. Getting too bloated has been the downfall of every other boilerplate generator / CLI I've used. I think react-create-app should draw a line in the sand that it will only concern itself with what it already has done - the compilation process - Webpack, Babel, ESLint (lint preventing build/runtime errors only). Unless the React team is going to officially bless an approach for linting, testing, styles, state management etc, then it would make sense to be incorporated. I am happy to see this is already what is being done - the React team has a fantastic track record of great wisdom and restraint in their feature requests!

[trevordmiller]

My 2 cents on the customization problem

Obviously, people are going to have different needs for their projects; they can npm run eject but I think that ejecting should be viewed as a last resort because then your project loses the benefit of the config abstraction (access to continuous improvements, best practices, and updates from the CLI under the hood). I'd prefer to see react-create-app add a new feature for config composition of other configs to extend it's minimal out-of-the-box configs instead.

For example

The CLI could compose its configs with the user's package.json configs if it exists (ie if the eslintConfig property exists in the user's package.json, compose it with the react-create-app config). Same thing for the babel and webpack properties (might need to be a subset of setting properties).

[trevordmiller]

My 2 cents on linting

I think including ESLint as has been done is the right move as it helps prevent errors; however, this is a fine line to walk as linting can also be used for style etc. The rules being used now seem to be good, but why not just use the "extends": ["eslint:recommended", "plugin:react/recommended"] options instead of manually maintaining a list of rules in react-create-app? The requirements for a rule to be added to this recommended list by the ESLint team seem to be in-line with what react-create-app is looking for: "

As for allowing users to customize these rules, see my composition proposal in the My 2 cents on the customization problem comment above ^.

cc: @nzakas

[trevordmiller]

@gaearon Would love to hear your thoughts on my last three comments above if you get a chance ^ :)

[PhilipGarnero]

Which procedure to follow when putting a project on git (or any other vcs) ? By that I mean, should we upload node_modules ? (I'm new to the js env and it looks like not everyone is thinking the same way)

If not, what do we do when we clone the project ? I didn't find anything about this subject yet. For now, it seems like the only solution is to create a new project and then override it with files coming from git. It doesn't seem really convenient.

A new command would be nice to have or even a create-react-app .

What are your thoughts about this ?

I'm more inclined to not putting node_modules inside the git repo as we do in the python community but this doesn't seem like a good practice with js devs.

[lacker]

@PhilipGarnero Don't upload node_modules to git. Instead, after cloning the project, run npm install immediately. I would recommend that workflow not just for create-react-app-based projects, but for any sort of version-controlled project using npm.

[Lakston]

@PhilipGarnero I'll add to what @lacker said and recommend that you create a .gitignore file (either by hand or via github) and add node-modules to that file.

On github you can just click on add gitignore when creating your repo and chose node. You can also for exemple see my angular-twitch-viewer repo and copy/paste the gitignore file (it has a lot more than just node_modules).

[mxstbr]

A .gitignore file will automatically be created with the new version. :+1: