Create-react-app: Requesting multiple versions of create-react-app

[crowdwave]

It may sound a little crazy at first, but I think there should be two or maybe even more versions of create-react-app

I LOVE that it is zero configuration. It should always stay this way.

On the other hand, there are broad categories of application development that each need their own implementation:

i.e.
create-react-app for babel
create-react-app for typescript

create-react-app for browsers
create-react-app for electron
create-react-app for native

So zero configuration within any implementation, but a recognition that there could be multiple implementations.

My primary motivation is wanting to move to typescript.

It's possibly even worth considering moving only to typescript and dropping babel.

[Timer]

There exist multiple community-maintained forks of react-scripts that support all of these features you describe.

You can use react-scripts-ts for typescript support, for example.
We're currently evaluating a potential plugin system and would love some feedback if you'd like to help it progress.
It's simply infeasible for us to support that many packages, but plugins might be the answer.

You can see the proposal which enables TypeScript here: https://github.com/facebookincubator/create-react-app/pull/2815.

If you'd like to use TypeScript immediately, go ahead and try out react-scripts-ts!

[crowdwave]

@Timer thanks for the reply.

A million times please do not implement a plugin system.

It would destroy the core value of create-react-app which is zero configuration.

I just don't know how to emphasize this enough - you have solved the unbelievable, excruciating, time and soul destroying pain of getting going (and staying going) with react, don't destroy that by moving to configuration from zero configuration. Please don't.

Once you implement a plugin system then heck you may as well delete create-react-app because if I want to have to learn, stay up to date, read out of date blog posts (wrongly) explaining it, be confused by changes and deprecations, learn and grasp how it works and why it is not working, then I may as well just start with all of those same pains that webpack and babel provide.

[Timer]

@crowdwave the plugin system would still be zero-configuration; additionally no one is allowed to create arbitrary plugins -- only we can create plugins. Think of them as add-ons! These add-ons will be chosen carefully as well, because we'd have to permanently support them.

These are features we'd normally have in the core of CRA, but do not because people complain about too large of a node_modules/ size and love the eject feature. We do not want to pollute configurations unnecessarily. These plugins/addons work with eject, too!

[crowdwave]

If there is zero cognitive load for the user then great.

Hard to see how to do so without some sort of options or config. I suggest my approach of different implementations is easier to understand, with zero config within each implementation. At some level is sounds like semantics and perhaps it is, but it makes sense to me that there is a "zero config" CRA for typescript, and a "zero config" CRA for babel etc

[Timer]

The only step will be npm install react-scripts-plugin-typescript --save; after that, it just works. No configuration necessary.