We need regualr CRA maintainer

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. https://github.com/facebook/create-react-app/issues/9995
2. https://github.com/storybookjs/storybook/issues/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.