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 [email protected] from several years ago. I bumped it to [email protected] 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 [email protected] 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 [email protected] from several years ago. I bumped it to [email protected] 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.

[polarathene]

This issue has fallen out of view pages behind new issues. I think it is an issue that warrants a pin for visibility?

[ryota-murakami]

@nickmccurdy

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.

That's doing well by craco might be unofficial though.

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

@ I agree with you.
Here is comparison activity of CRA and Vite while 1 month.(2021/08/11~202109/11)

Create React App

　 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

Vite

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

During a month, opened over 25~28 Pull Request on the both project almost might from motivated contributions.

(Also In Vite case maintainer @patak-js and author @yyx990803 really motivated to code commit and oganization member @antfu making super inovative tools for improving Vite.)

The problem is CRA merged only 5 PR a month despite receiving about 25 Pull Request from awesome contributors.
Pinning this Issue on issues tab page top helpful for notifications to new contributors that

"Your contribution might not take a look by administrators"

I want to prevent for people wasting time cause believed following "PRa welcome" badge.

[robertwt7]

I agree in the case of PR not being looked enough.
I suppose "maintenance mode" of CRA should still accept contributions from community just to keep it active and address issues. as @markerikson said, we're kind of falling to waiting for the 'perfect' thing rather than keeping it 'good'

+1 to pin this issue as I believe this post spoke for most of us

[dantman]

I think what we're missing here is some communication from the current maintainers (or at least those currently working on v5). We're just looking for a decision on the future of CRA. If the decision is to go into maintenance mode that's fine, we just need that communicated.

I would also say that if the final decision is that CRA is in maintenance mode because people should be trying other things. The only proper way to do that would be to have documentation on how to migrate / setup the other frameworks with equivalent functionality to CRA.

Basically every one I checked (Vite/Snowpack/Parcel) required manual config for some portion of CRA's functionality:

• Autoprefixing CSS + PostCSS Normalize
• SASS
• SVGR
• macros
• eslint
• Jest
• Storybook
• PWA/service-worker.js

Some of these missing bits being basic best practices for ensuring what you build in production is compatible with people's browsers. Or ensuring you don't write coding mistakes.

[OriAmir]

@cmacdonnacha @dantman I really agree with both of you !
My question is who could give us answers or decide something about that ? I don't see any comment from "official" member of CRA.

[aaronplanell]

Hi everyone!

It seems that CRA 5.0 is out: https://github.com/facebook/create-react-app/releases/tag/v5.0.0

Thanks to the mainteners! 😊

[aaronplanell]

@gaearon , I think that you can close this issue, what do you think?

[alamothe]

Just tried 5.0 and there were a few problems. Given that issues in this repo are just collecting dust or locked by the stalebot, what should we do? Should we file issues for 5.0?

[iansu]

Yes, you should file issues for v5. We're aiming to do a patch release in a couple days.

I'm going to convert this issue into a discussion.

[alamothe]

A suggestion: please stop using stale-bot to limit discussion. E.g. there is an issue from 1 year ago which is locked, if I have a working fix I can't go and contribute that. Who benefits from limiting and hindering the free flow of ideas? I suppose it is fine to close an issue for bookkeeping but limiting is not OK.

[ryota-murakami]

This post is exactly for here.
https://blog.filippo.io/professional-maintainers/

[Nefcanto]

CRA is very slow. Please move to esbuild.

[Tymek]

Check out Vite. In my team it was a painless migration :)

[nickserv]

esbuild is great for developing libraries, but Vite adds the features it's missing for developing apps

[ryota-murakami]

@nickmccurdy

Vite adds the features it's missing for developing apps

What kind of features? I'm using Vite regularly but I have no idea.

[nickserv]

Mainly code splitting, CSS bundling, and fast refresh.

See Why not bundle with esbuild?

[quantuminformation]

Can this be closed since CRA 5?

[Nefcanto]

We also migrated to Vite + React template.

Though the migration had a couple of challenges we had to face, now we are all satisfied.

The same codebase that would take more than a minute to be built in CRA, is now built in less than a second (300 milliseconds in fact), which is somehow weird.

But the app works and after extensive testing and even production testing, no problem is detected. This means that in our case Vite is faster 180 times faster than CRA.

[quantuminformation]

It’s like my birthday x 180

On Tue, 28 Jun 2022 at 06:09, Saeed Nemati ***@***.***> wrote: We also migrated to Vite + React template. Though the migration had a couple of challenges we had to face, now we are all satisfied. The same codebase that would take more than a minute to be built in CRA, is now built in less than a second (300 milliseconds in fact), which is somehow weird. But the app works and after extensive testing and even production testing, no problem is detected. This means that in our case Vite is faster 180 times faster than CRA. — Reply to this email directly, view it on GitHub <#11768 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU35QCYSM74U4L3GDGQTLVRKCIDANCNFSM5KHZ5TMQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

-- Kind regards *Nikos Katsikanis* <https://nikoskatsikanis.com> *Tech Innovation* | *Podcast Host*

[hidaytrahman]

Do we have any latest sweet update on it? I understand we don't have much time to work on CRA actively but is there any plan to get rid of security issues?

[quantuminformation]

cra is dead since ages, use vite, it’s easy

On Tue, 28 Feb 2023 at 18:13, Hidayt Rahman ***@***.***> wrote: Do we have any latest sweet update on it? I understand we don't have much time to work on CRA actively but is there any plan to get rid of security issues? — Reply to this email directly, view it on GitHub <#11768 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU35UTAKQIJ7EVL3NHRSLWZY55DANCNFSM5KHZ5TMQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

-- Kind regards *Nikos Katsikanis* <https://nikoskatsikanis.com> *Tech Innovation* | *Podcast Host | Linktr.ee <https://linktr.ee/nikosshow>*

[willxy]

Related and more current/recent discussion at reactjs/react.dev#5487, see in particular gaearon reactjs/react.dev#5487 (comment)

[hidaytrahman]

Thank you!