We need regualr CRA maintainer

@mrmckeb

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

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.

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:

create-react-app --template typescript creates unresolvable dependency conflict #9995
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.

@gaearon

@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

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 🤗

@ianschmitz

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!

@mrmckeb

@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.

@44px

@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.

@gaearon

@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.

@gaearon

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?

@TomasHubelbauer

@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 🚀

@mrmckeb

@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.

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.

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.

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

Hi all. I am one of the Parcel maintainers. If we can help here, we'd love to!

About the issues mentioned in this thread:

TypeScript type checking – is possible through validator plugins, however these are currently experimental. It's on our roadmap to significantly improve them soon.
Package exports field – is on the short term roadmap. We were focused on getting v2 shipped before tackling too many more features, but now that it's done, it's on my list in the next couple weeks.
Parcel uses SWC by default for transpilation rather than Babel, and we implemented our own Rust-based compiler on top of it for tree shaking etc. However, it's extensible via plugins and Babel is also supported by default.
Unlike Vite/Rollup, it should work out of the box with all npm packages (e.g. written with CommonJS).
In regards to maintenance, Parcel has a very active core team including several full-time contributors working for Atlassian.

We're also going to be building a project scaffolding tool similar to create-react-app soon. This will make starting up a new project easier, and we'll have different templates e.g. for React, different styling tools, etc. We'd love input from all of you on what the default React template should include.

If anyone on this thread would like to help with the above, we'd love to have you. We'd be open to working with the CRA project in any way that's helpful to the ecosystem. Overall, I think Parcel and CRA's philosophies are very similar. We want to make it as easy as possible to get started with a pre-configured setup. Where Parcel differs is that it should also be easy to extend as your project grows.

Go away Parcel, we like CRA except it doesn't have maintainers at the moment.

I'm not really understand the point of this topic..
The original idea was to think how we keep maintains CRA and keep him alive but it's fells like it's been issue of comparing CRA to Vite and Parcel.. I think we miss the point of the actual problem.

I'm not really understand the point of this topic..
The original idea was to think how we keep maintains CRA and keep him alive but it's fells like it's been issue of comparing CRA to Vite and Parcel.. I think we miss the point of the actual problem.

The original question was about CRA maintenance. But one of the co-creators has said CRA is intentionally in maintenance mode and they believe that CRA's purpose has been supplanted by Next.js/Gatsby/Vite/etc.

However CRA is still the most widely used of these and there are still some categories of users/projects whom are only properly served by CRA.

So the actual problem right now is:
"CRA is not being properly maintained, but there is still a category of users who's needs are only directly served by CRA. What should be done for these users?"

Vite/Parcel/Snowpack have come into the conversation because Gatsby/Next.js are not equivalent replacements for CRA and Vite/Parcel/Snowpack are the closest to CRA at least as far as what they build (a React based SPA with no restrictions on what client-side React libraries you can use).

With the caveat that none of them have an equivalent default configuration to CRA. With manual config needed to re-enable many of CRA's features and best practices for browser compatibility. And the caveat that none of them are WebPack based which raises some questions to discuss about replacing the most widely used SPA building tool using the most widely used bundler, with a SPA building tool not based on the most widely used bundler.

@dantman

With the caveat that none of them have an equivalent default configuration to CRA. With manual config needed to re-enable many of CRA's features and best practices for browser compatibility. And the caveat that none of them are WebPack based which raises some questions to discuss about replacing the most widely used SPA building tool using the most widely used bundler, with a SPA building tool not based on the most widely used bundler.

@dantman Thanks for the detail
Answer.
So, what you say actually that CRA not going to release any more major releases and we should hope that all CRA features will be in the future in Vite/Parcel ?
Actually CRA 5 is very close to Beta version and it's work pretty well..so I'm confuse already.

@devongovett

Problem root is priority of the company.

Metaverse >>>>>>>>>>>> CRA

@devongovett Thank you for your friendly comment from Parcel community!
That will must be helpful for us!

So, what you say actually that CRA not going to release any more major releases and we should hope that all CRA features will be in the future in Vite/Parcel ? Actually CRA 5 is very close to Beta version and it's work pretty well..so I'm confuse already.

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.

My biggest concern is that the brand new ReactJS docs are advocating for the use of CRA here. Though it's good to get users started, they may get the wrong impression that CRA is actively maintained and eventually choose to start a production app with it.

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.

@cmacdonnacha

@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.

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! 😊

@gaearon

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

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?

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.

Navigation Menu

Repository navigation

We need regualr CRA maintainer #11180

wrap up

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

We need regualr CRA maintainer #11180

Description

Activity

gaearon commented on Jul 6, 2021

44px commented on Jul 6, 2021

ryota-murakami commented on Jul 7, 2021

wrap up

mrmckeb commented on Jul 8, 2021

ryota-murakami commented on Jul 8, 2021

ryota-murakami commented on Jul 9, 2021

tomasbruckner commented on Jul 17, 2021

royderks commented on Jul 24, 2021

ryota-murakami commented on Aug 1, 2021

ryota-murakami commented on Aug 1, 2021

markerikson commented on Aug 2, 2021

nickserv commented on Aug 3, 2021

polarathene commented on Sep 10, 2021

14 remaining items

devongovett commented on Dec 3, 2021

alamothe commented on Dec 3, 2021

OriAmir commented on Dec 3, 2021

dantman commented on Dec 3, 2021

OriAmir commented on Dec 3, 2021

ryota-murakami commented on Dec 6, 2021

cmacdonnacha commented on Dec 7, 2021

dantman commented on Dec 7, 2021

OriAmir commented on Dec 7, 2021

aaronplanell commented on Dec 14, 2021

aaronplanell commented on Dec 15, 2021

alamothe commented on Dec 15, 2021

iansu commented on Dec 15, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions