Suggest users to explore alternatives interactively

I came across a pretty nice interactive list of react-based starter kits and I think that something like this should be provided to people who grow out of create-react-app and want to explore the alternatives.

http://andrewhfarmer.com/starter-project/

After a newcomer has played with the components and has understood the core principles, it′s common to become curious about redux, hot reloading, universal rendering and many other things that are good to hide away in the very beginning of the journey to React. Giving people a convenient entry point into this huge and growing zoo of alternatives is pretty important in IMO.

I’m not insisting that the above link should be added to README.md because I’m not sure if all good options are listed there and if the author is willing to update the data regularly. What I’d like to point out is that the section with the alternatives in the repo seems pretty poor ATM. No matter how many projects are listed there, the suggested UX for outgrowing create-react-app is far from ideal. A link to an interactive list of all sorts of starter kits will show the React ecosystem in a much higher depth.

[mxstbr]

I’ve been thinking about this, and I think you’re making some great points. I can see us moving in this direction.

Could we use a fork of react-scripts for this? And just add our custom config stuff on top?

This is a major effort, so I’m not sure if I’ll be able to do it soon, but this is something I want to do.

[gaearon]

I agree tinkering is useful and desirable for some people. I don’t propose to remove that feature but to make it opt-in, or at least easy to opt out of.

The issue with “internals” folder is that once you fork, it’s just there. You’ll have to either update it manually (tricky when your git history diverges because your fork is your app), or you’ll leave it outdated for a few months. Then next version of Webpack/Babel comes out, or there’s a critical bug in a dependency, and you have to dive into it and figure out how to maintain this folder even if you never wanted to do this in the first place.

If RB is implemented as a monorepo with two packages, users could still use npm link to change configuration. However they would also have the option of just deleting the local rb-internals package, and using the one from npm maintained by the community. They’d get bugfixes and improvements without diving into details. At any point of time they could also download the rb-internals source, npm link it (or just start referring to it from the source), and tweak it. They could also publish their fork and use it as build configuration for their or their company’s projects. I think that even if you want to customize things, this is more scalable than having each project contain its snowflake configuration.