✏️Discussion: The direction & future of create-react-app

Hello to all the wonderful people behind this project!

Thank you for making our development experience better and more accessible to everyone ❤️

Today I would like to open a discussion on the direction of create-react-app. I saw the issue opened up by @shelldandy, and I took interest in the future of create-react-app.

You see, the current landscape of programming is changing rapidly. Not too long ago, most programmers managed their dependencies themselves. Being a veteran meant that you had seen the ins and outs of all the tools that supported your tech stack. While there was pride in knowing the complex labyrinths of configs, there was also a lot of energy spent on things that did not produce a tangible impact on the end-user.

And this is where the major shift is occurring: Over the last years, especially in the web field, programmers have shifted from being people that make things work to people that create experiences. As programmers, we want to produce tangible output in the most efficient ways possible. In the web tech landscape, this shift was characterized by the Javascript renaissance, accompanied by the Javascript fatigue. This brought about the trend towards 0cJS, serverless services, and tools like create-react-app.

I believe this to show that what we want as programmers is to create experiences efficiently, and handle only the details that truly matter to us.

In light of this, I believe that the tools of the future will be tools that abstract away all the unnecessary details to bring an experience to life, while providing enough modularity to expose certain details on-demand. These tools shall be:

• zero-config by default
• always at the bleeding-edge (performance, packages, SEO, PWA, etc)
• modular
• extensible
• have an easy-to-use cli that can provide access to multiple boilerplates

Here’s how I see it:

Imagine a cli for create-react-app that can read configuration files like vue-cli meta.js files and infer from there a series of command it has to undertake to scaffold an entire create-react-app repository, complete with extended config and pre-installed plugins.

Imagine being able to load THE boilerplate configuration you want from a list of awesomely-curated meta.js-like github gists.

Imagine being able to automatically export YOUR boilerplate configuration to a github gist via an export command so that you can share your setup with others.

Imagine a create-react-app repository that does not need to be ejected to do partial, custom configurations, but still hides the non-customized configuration from its user.

Imagine a create-react-app that benefits from a plugin architecture, a bit à la Gatsby (but better), where all you need to install a dependency to your favourite service or dev feature is one command away.

Want SCSS in CSS Modules? Load cra-sass-css-modules-plugin and you are good to go.

Want to have firebase support? Sure thing, just install cra-firebase-plugin. It will run you through a series of inquirerJS questions to do a first config. It will expose new files to the create-react-app config files, which you will be able to modify just like any other custom config.

Now, imagine that you are a plugin developer. All you’d have to do to create a plugin is to use a config extend API provided by create-react-app that allows you to install packages, modify configs, and more.

Your comprehensive, efficient, extensible, concierge-like development experience with react will only be a single command away.

Welcome the docker of server configuration, the npm of module registry, and the serverless of scaling, all for your favorite front-end library, React.

Welcome to the future of web development.

This is what I believe to be the future. What are your thoughts?

🚀

[gaearon]

Look at the scope of the changes it takes to upgrade a major version of a tool.

Webpack 4: https://github.com/facebook/create-react-app/pull/4077 (and other PRs) Babel 7: https://github.com/facebook/create-react-app/pull/3522 (and other PRs)

Many of these changes are cross-cutting. Now, the promise of CRA the way I see it is to:

• Free the developer from the burden of making those changes, and instead make upgrading really simple.
• Ensure all these things keep working together well after each upgrade (which is not trivial).

Of course this only works if you don’t eject. But plenty of projects (about half) don’t, and so far we’ve been successfully expanding the use case coverage that comes by default (and will keep expanding it, e.g. you can try 2.x alphas which support Sass and lots of other stuff).

Turning CRA into a plugin ecosystem pretty much kills both advantages above:

• Upgrading is no longer easy because you have to track every “plugin” and which versions it’s compatible with.
• The whole thing is fragile because no plugin can “survive” significant changes in the base configuration (again, look at above PRs). So plugins will be broken by updates, will be clashing with each other, and are not guaranteed to work well together.

The advantages of having shared “base” conventions and feature set (which lets beginners easily switch between examples and feel familiar in different projects based on CRA) also disappear because now we have 1000 unique setups again.

Ultimately my impression is that following this path will just turn CRA into a worse webpack. Why build plugin systems on top of plugin systems?

I think that primarily you want this because some of the features you care about are not supported yet. If they were supported I’m not sure configuring everything (and losing existing benefits like easy upgrades and guaranteed well-done integration) would be worth it. In that case I think our philosophy is still valid. We’ll keep covering more use cases with each release, and try to make 80% users really happy by applying our tradeoffs as a lever instead of ending up with a generic generator with a fragile ecosystem based on mutating configs.

What am I missing?

[yufengwang]

When is it ready for webpack4 ?