We need regualr CRA maintainer

[ryota-murakami]

I know recently, Maintainers of Create React App are working during their "FreeTime". Thanks all time @mrmckeb

I think this is not healthy situation, that relying too mush volunteer work, if 2021 still Create React App is a new officially supported way to create single-page React applications. I think FaceBook should support dev resources for Sustainable Development.

Webpack5 update PR already merged but yet ship dependency reason.
So I think we need maintainer who handle manage well keep up clean and non-breaking npm dependencies, for prevent like current vulnerability Clutter. Thank you handling that @gaearon

• [WP5] Webpack5 update #10961
• Help, npm audit says I have a vulnerability in react-scripts!

[gaearon]

I totally hear your frustration. As an original co-author and a sporadic maintainer over the years, I probably carry most of the responsibility here. Let me try to address your points and add some context that might illuminate the situation.

Before CRA, the ecosystem was hopelessly fragmented. The entire category of tools like this didn't exist — there was no Next or Gatsby or Vite and so on. The vast majority of React developers were setting up their Babel, webpack, etc, manually, and having a really bad time. These tools were difficult to get working together correctly. For example, webpack had no built-in concept of development and production modes, and no defaults for filenames (it would just crash if you forgot an option). So it was kind of an emergency.

I (co-)created CRA to solve this problem.

It was intentionally minimal and limited in scope (no configuration, no plugin system) for two reasons. One reason was that, the more feature-rich it is, the harder upgrades will be. The other reason was, I knew that React itself will take a vast majority of our time, and I won't be able to dedicate more than a few weeks sporadically to CRA every now and then.

Despite what may appear as it languishing (many open issues, lagging releases), I believe CRA has been, and still is, incredibly successful as a project. Just a few weeks ago, I found an old project using react-scripts@0.7.0 from several years ago. I bumped it to react-scripts@4.0.3 and it just worked. Years of tooling changes, changes in config formats, deprecations, new features — all with a single line. This is very powerful. This is precisely why CRA was created, and it still does a great job at keeping small and mid-sized projects up to date with tooling. Lagging releases are not an issue for such projects because the alternative is they would simply not update at all.

Like I said earlier, it was always the intention that we're not going to be able to work on it full-time. I really, really appreciate the efforts of the volunteer maintainers. I did not expect that someone would help pick up the project while I'm busy. So I'm very thankful. But it was intentionally designed for this kind of sporadic development. We would get critical fixes out as soon as posible, but overall, starting with 2.0, it's mostly in maintenance mode and does not strive to be the best tool for production React apps. It is a tool to get started and get something running fast. Perhaps, it's not even best at that anymore.

Realistically, CRA is inherently very limited. It does not follow best practices for performance because it produces client-side only apps. This means it doesn't benefit from optimizations that are commonplace today with other frameworks, such as static generation or server-side rendering. Unless there is a drastic redesign, it won't benefit from future-facing features like Server Components. So if you care about delivering the best user experience, I don't think CRA is the right tool in the first place. It has its use cases, but many other tools now exist that do this job better. CRA still works great for the getting started use case, but you shouldn't see it as the best React app setup. It's not, and isn't meant to be.

I think the biggest thing that causes people to worry about maintenance is the "vulnerability" reports. This is where it becomes noticeable that releases are lagging behind. Unfortunately, as you probably know, 99.9% of these reports are false positives and the npm audit system is horribly broken. We will be working with Node/npm to figure out a solution to this. It creates unnecessary FUD and penalizes slower-moving projects even if they're not actually vulnerable.

There is a conversation to be had about where we want CRA to go in the future. Definitely, I hear your frustration about not having a dedicated full-time working on it. But that was a conscious choice from the beginning when I was setting up the project. And again, I think the sporadic maintenance strategy has largely been successful because of its limited scope and thanks to all the volunteers who helped out. Overall this didn't start being such a problem until (1) npm started the FUD with audits, (2) I had to take a long pause from the project to focus on React itself (and now, on React Docs as well).

I want to better understand what you want to see focus on. Can you tell me more about what concrete problems ("X doesn't work") have urgency? E.g. the webpack upgrade — what makes it urgent as opposed to, say, waiting a few more months? Are there any user-facing features you are waiting for? Bugfixes?

There is also a broader question of what the long term plan should be for CRA. In the current client-only design, you could make an argument that CRA does not have the right defaults for the web ecosystem. For example, we'll really want to make Server Components as easy as possible to adopt for the ecosystem. Tools like Next.js or static generators will be able to do this, but this clashes with CRA's client-only approach. One possible solution could be to expand CRA feature set and add some kind of SSR/SSG capabilities to it. But this requires a lot of expertise and I don't see how we can compete with projects that have all the existing know-how in this. Another option is to make CRA more of a "launcher" and make the existing client-only template one of the possible choices, like a "classic" one. But push the ecosystem towards choices that are better for the web.

I don't know what the right answers are but I hope this illuminates the situation a bit. Overall, it would help if you could reframe the question around the concrete actionable things you want to see done, and why they are important. Thank you.

[44px]

To me, the main problem with lagging releases is the dependency conflict that arises when a newer version of TypeScript or Babel is required. A few examples:

1. create-react-app --template typescript creates unresolvable dependency conflict #9995
2. babel-loader conflicts with create-react-app version storybookjs/storybook#5183 (reproducible now with npx create-react-app, npx sb init, yarn start)

I don't think CRA needs more features, "maintenance mode" is totally ok. But it needs somewhat regular releases (twice a year maybe?) just with dependency updates to keep pace with an ecosystem.

[ryota-murakami]

@gaearon
I really appreciate for your very kind response.
Might be a bit long as I'll respond to each one in block I'm afraid.

Before CRA, the ecosystem was hopelessly fragmented. The entire category of tools like this didn't exist — there was no Next or Gatsby or Vite and so on. The vast majority of React developers were setting up their Babel, webpack, etc, manually, and having a really bad time. These tools were difficult to get working together correctly. For example, webpack had no built-in concept of development and production modes, and no defaults for filenames (it would just crash if you forgot an option). So it was kind of an emergency.
I (co-)created CRA to solve this problem.

It's feeling nostalgia my first CRA is react-scripts@1.0.13 at 2017 and I've completed project initial setting still I have apreciate about it.

It was intentionally minimal and limited in scope (no configuration, no plugin system) for two reasons. One reason was that, the more feature-rich it is, the harder upgrades will be. The other reason was, I knew that React itself will take a vast majority of our time, and I won't be able to dedicate more than a few weeks sporadically to CRA every now and then.

Personally I expected CRA is Plain React Starter Kit powerd by FaceBook Offical so CRA don't need rich new feature and agree keep minimal/limited sopope.
And I knew you are working for React it's self there is no complaint against you, to be clear.

Despite what may appear as it languishing (many open issues, lagging releases), I believe CRA has been, and still is, incredibly successful as a project. Just a few weeks ago, I found an old project using react-scripts@0.7.0 from several years ago. I bumped it to react-scripts@4.0.3 and it just worked. Years of tooling changes, changes in config formats, deprecations, new features — all with a single line. This is very powerful. This is precisely why CRA was created, and it still does a great job at keeping small and mid-sized projects up to date with tooling.

I agree with that, totally.

Like I said earlier, it was always the intention that we're not going to be able to work on it full-time. I really, really appreciate the efforts of the volunteer maintainers. I did not expect that someone would help pick up the project while I'm busy. So I'm very thankful. But it was intentionally designed for this kind of sporadic development. We would get critical fixes out as soon as posible, but overall, starting with 2.0, it's mostly in maintenance mode and does not strive to be the best tool for production React apps. It is a tool to get started and get something running fast. Perhaps, it's not even best at that anymore.

I have no complaint about sporadic maintaining cycle, project status of after 2.0.
I think souldn't hurry up too much or give them pressure who working volunteer in free time bacause I thnik maintainer must not get depression from Open Source Software that learned from Henry Zhu(ex Babel maintainer).
Even though

We would get critical fixes out as soon as posible

At the sentence I have only short story I want to tell you.

At the Oct 24, 2020 create-react-app v4.0.0 was released but TypeScript isn't working completely.

• 4.0.0 breaks with typescript (all versions) #9868

I also facing this issue in my react-react-app-todo-example and I finally fixed
issue in

• Fix noFallthroughCasesInSwitch/jsx object is not extensible #9921

But above fix with v4.0.1 not comming soon, that released after about a mouch

during ship v4.0.1 some person telling about relase date

• Fix noFallthroughCasesInSwitch/jsx object is not extensible #9921 (comment)

and so many peaople seeking workaround in this thread

• 4.0.0 breaks with typescript (all versions) #9868

over 100 comments.
To be clear, I'm really apreciate @iansu who handle shiping it!

Actually that's tier 1 reason why I submit this issue, I don't cover all codebase detail of CRA though I'm motivated to become one of maintainer if I could ship that critical bug fix.

Realistically, CRA is inherently very limited. It does not follow best practices for performance because it produces client-side only apps. This means it doesn't benefit from optimizations that are commonplace today with other frameworks, such as static generation or server-side rendering. Unless there is a drastic redesign, it won't benefit from future-facing features like Server Components. So if you care about delivering the best user experience, I don't think CRA is the right tool in the first place. It has its use cases, but many other tools now exist that do this job better. CRA still works great for the getting started use case, but you shouldn't see it as the best React app setup. It's not, and isn't meant to be.

I thnik CRA don't need competision and defeet Next.js that like F1 formula 🏎 Framework.
I earier said Plain React Starter Kit powerd by FaceBook Offical is better position in my view and you mentioned good for getting start React.(and that has enough power for build Regular Single Page Application)

As for the Server Components I pland publish backend cra-template with Node Server(Express) & Sequelize & MySQL(Docker Compose) that will support Server Components easily.
For to do that I planed work based on this CRA basesd fullstack JS project and polish it.
In addition I submited PR for to be sharerable src between server dir

• Add DISABLE_MODULE_SCOPE_PLUGIN option #10998

• create-react-app should allow TypeScript imports outside src #8785

wrap up

I'm afraid too long resonse and I can't make 1 by 1 response your last 3~4 paragraph block.
But anyway I really apreciate you are solving npm audit pretty well, and making great announce for community!

I'm welcome conticue discussion if you have a unclear something 🤗

[mrmckeb]

To me, the main problem with lagging releases is the dependency conflict that arises when a newer version of TypeScript or Babel is required.

We could do better here, agreed. Currently only @ianschmitz and @iansu have access to publish (from active maintainers), and we also need to rewrite our tests to support more regular releases. We just don't have the confidence to make "quick" changes today.

On testing, we haven't rewritten our tests because we wanted to make some larger changes to CRA first (we wanted to avoid rewriting tests first). Where we go next with CRA is unfortunately the blocker to that work being started, as @gaearon said, but we do plan to get CRA into a place where it a) meets more of the community needs/requests, and b) is updated more frequently. We're working together (with @gaearon) on this, and I hope we can come to a solution in the near future.

To be clear, we have Webpack 5 in the works - @raix is leading the charge there - and we're planning to ship that in alpha form soon, providing there are no big blockers. More on that in the coming weeks I hope!

[ryota-murakami]

@mrmckeb Thank you for sharing your thought!
To quick fix these TypeScript problem and make a confidence for release without TypeScript things regression,
could we utilize my Create React App TypeScript Todo Example 2021 somehow?

Rough strategy is making alpha version before publish certain numbering release, and then install the alpha version into the Create React App TypeScript Todo Example 2021 for Testing is working fine on TypeScript Project?.
the repo's almost code are covered Component Testing with React-Testing-LIbrary and E2E Testing with Cypress.

Also running new release on actual project is easy to detect conflicted dependency like @44px mentioned #9995
I hope we'll get any make sense quick releaseable TypeScript support workflow in this thread.

[ryota-murakami]

@44px I guess package.jsons "resolutions" field is good option for resolve module version conflict.
But this is Yarn specific feature, I found npm-force-resolutions that enable resolutions field on npm though.

[tomasbruckner]

@gaearon
Thanks for sharing the insights about the CRA. I really appreciate the effort of the CRA team over the years. I have built many projects based on the CRA and it was super helpful.
But lately, I am starting to get frustrated with CRA over the speed of starting the dev server, build time, and HMR. It takes more than 10 seconds to start freshly installed CRA even on a high-end computer. When you run it on a low-cost computer or your codebase increases, your start-up time increases to minutes and HMR to 8+ seconds.

It would be ok if there were no alternatives, but I can see a lot of projects that are making so much progress in this area by integrating esbuild and making the build up to 100x faster. I played with some of these projects and it felt like out of this world. It was next-level experience for me and it really opened my eyes that it is not normal to wait so much time to start your app or to see your changes updated in the browser.

If CRA is in maintenance mode, does it mean that this issue is not going to be addressed in the near future (Q3/Q4 2021)? I can live without server components, but such a slow experience with CRA really drops my productivity. It would be the main reason I will have to look for CRA alternatives.

I don't mind waiting for speed improvements in the CRA, but if there are no plans, it would be great to know it's futile to wait. In that case, I would have to experiment with some alternatives.

[royderks]

Thank you for the extensive information here @gaearon! As React 18 is being developed now, will CRA still be listed as a good way to get started with a SPA in React?

[ryota-murakami]

@TomasHubelbauer FYI: Personally I was migrated babel-loader to esbuild-loader for getting blazing fast dev-server.
I recommend you follow the webpack or esbuild: Why not both? article for setup esbuild-loader and you'll get speed as well as Vite 🚀

[ryota-murakami]

@mrmckeb @ianschmitz @iansu @44px @gaearon
I have a idea about dependency conflict that arises when a newer version of TypeScript or Babel is required problem.

It's replace babel-loader to [esbuild-loader](https://github.com/privatenumber/esbuild-loader) in the TypeScirpt setup.
This means esbuild-loader handles all of TypeScirpt and remove all TypeScirpt related things form Babel.
I think this should be easier to babel dependency management that allowed faster release with confidence.

What do you think about it?

Also @bvaughn reported about ReactDevTools's display hook name feature,

• Default source maps generated for DEV builds seem invalid? #11204

and I'm using esbuild-loader in CRA v4.0.3 project overriding Webpack config by craco but hook name showing correctly.

this is override script

So that replacing might not impact to sourcemap stuffs.

[markerikson]

Just saw this thread and want to toss out a few off-the-cuff thoughts.

I think CRA has more than accomplished the original goals of providing a standardized approach for quickly creating a new React project, with good defaults out of the box, and without having to configure Webpack+Babel.

As mentioned, there are plenty of other options today, both Webpack-based (Next, Gatsby) and non-Webpack (Vite, Snowpack). However, I think CRA still provides plenty of value for its particular niche.

CRA also still serves as the default standard recommended approach for setting up a React app, per https://reactjs.org/docs/create-a-new-react-app.html#recommended-toolchains .

I see Dan's comment about CRA and relation to things like Server Components and "best practices for the web ecosystem". I understand the thought process there, but I'm a little concerned that that could lead to a "perfect is the enemy of the good" scenario. Not every app can or will be able to use Server Components, and Server Components are still pre-alpha experimental. There's absolutely value in having good defaults push people in the direction of best practices (such as warning about large bundle sizes automatically), and certainly if there are ways to drive adoption of SCs via CRA improvements, that's great. But, I can foresee a potential trap there - if we get to a point where there's no work being done on CRA or no encouragement to use it just because it doesn't provide the absolute best possible hypothetical result, that could end up eliminating the value that it does provide.

In terms of concrete improvements, I think the Webpack 5 upgrade is likely most beneficial because A) it keeps CRA up to date with its largest dependency, and B) it lets people benefit from WP5's artifact caching, which could help address some of the speed concerns.

I'd love to see something like ESBuild integrated into CRA for speed. In theory, because of the black-boxing of the Webpack config, that could be done right now and almost all users could benefit from it - it would only be those of us like me who have done our own CRA overrides via craco or react-app-rewired that might have to deal with the changes.

I actually haven't run into the TS dependency issues yet myself, but I can understand how that would be frustrating. CRA does definitely need to be able to work right with TS, and especially updates to TS versions outside of react-scripts.

Overall, I think CRA still serves a valuable role in the React ecosystem. Not sure what the right approach is for ongoing maintainence, but I think with some targeted effort on a few key changes we could help ensure it stays relevant going forward.

[nickserv]

I'll keep this short as I don't want to get too far off topic, but I think having some sort of plugin/extension/recipe system would help a lot in making CRA more flexible without putting as much burden on the core maintainers (since plugin developers can start picking up work in userspace without having to maintain forks). For example Gatsby recipes can install entire tool configs automatically, and Rollup plugins have been so successful that some (such as Babel) are now maintained by the core team.