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.

[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

[alamothe]

It took me 3 full days to get CRA working with Yarn PNP. It would be great if it worked out of the box.

[dantman]

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.

I don't think this problem that CRA was originally built to solve has gone away. Every one of those popular alternative tools comes with an extreme caveat to their usage.

• Next.js and Gatsby, while nice if you need SSR or SSG capabilities, come with vendor lock in which can be harmful if you are only trying to build a SPA. Routing in particular is the worst. Both frameworks lock you into their own file based router blocking you off from the routing used by the rest of the React ecosystem. If you have a need for say the latest features of React Router v6, both are completely unsuitable. Gatsby at least uses @reach/router, though that's an old library and it's wrapped by Gasby's routing API. Next.js on the other hand is absurdly NIH. You are locked-in to a router exclusive to Next.js, with an API nothing like any other router in the react ecosystem. And even basic code splitting of react components is done using a Next.js provided module instead of the same library as the rest of the ecosystem.
• Vite is the closest to CRA in it's focus on SPA and compatibility with the whole of the React ecosystem. However to use it you have to be sold on ditching the entire WebPack ecosystem for an alternative build ecosystem. And while the plugin system is nice, a couple of CRA's rightfully automatic features like macros are not built-in and have to be setup manually (using undocumented config you only find after thinking you need to use an unofficial plugin by one random developer in order to use it).

Today if you want to build a SPA with React, React-Router, and WebPack, your options are still CRA or manually configuring WebPack, Babel, etc. The use case for CRA still hasn't gone away, it still remains a critical part of React infrastructure. Just without the essential maintenance needed to keep us from going back to manual WebPack config.

[andrei9669]

@dantman one of the new alternatives is remix. altho it is really fresh in the open-source ecosystem, but it offers a similar routing experience to react-router v6.

but either way, I agree that for a SPA CRA is still very important.

[utajum]

https://vitejs.dev/guide/features.html#typescript

Vite does not do type checking, so its not really an alternative for typescript since you have to fiddle with configs, so might as well use plain webpack

[dantman]

@dantman one of the new alternatives is remix. altho it is really fresh in the open-source ecosystem, but it offers a similar routing experience to react-router v6.

Yes, I will keep an eye on it. However it's still more of the same problem in regards to CRA. You get RRv6 with Remix. But it is built around SSR, so it's not made for building a SPA. Likewise while I like React Router v6, if you use Remix you're then locked into RRv6. Using remix you cannot experiment with a random non-RR routers, e.g. (just randomly searching for one) wouter.

but either way, I agree that for a SPA CRA is still very important.

Yes. Specifically we still desperately need a fundamental non-framework that:

• Comes with pre-configured WebPack building and the important stuff pre-configured (bundling, code splitting, css prefixing, macros, etc) whether it has a plugin system or not.
• Can build a static SPA for those who already have a backend and cannot run a Node.js backend.
• Is completely agnostic about everything outside of the build system. i.e. Works with any router library, API client, etc.

This doesn't have to be CRA, I could see another framework pivoting a bit and being able to handle this.

• Vite could make itself a more friendly CRA and WebPack alternative. e.g. Adopt more of CRA's best practice defaults without configuration (TypeScript, macros, etc). Or at least take a page from Parcel and make things automatic. And adopt WebPacks recent web-like interfaces (i.e. the ES modules way of doing Workers instead of import MyWorker from './worker?worker';. And we could all try to ignore the fact it's not WebPack unless WebPack wants to take responsibility for there being no user friendly way to use WebPack to build a router-agnostic SPA remaining.
• Next.js could get over it's NIH syndrome and separate the core from the current Next.js interface taking advantage of it's plugin system to make things more abstract. e.g. Let you plug in non-Next routers. Provide a way to implement other SSR data handling methods in plugins. Ditch next/dynamic for something like @loadable/component. Collaborate with others on a common API route interface. So Next.js with a "SPA router" / "client-only router agnostic" plugin would effectively give you CRA with minimal config and there'd be room to make SSR work with non-Next routers too.
• WebPack itself could realize its losing ground (Vite, Parcel, etc are making builder config user friendly/pluggable but not using WebPack; CRA lags behind making the unmaintained WebPack 4 more popular than WebPack 5; and even the frameworks using WebPack are experimenting with non-webpack bundlers). And come up with its own config plugin/preset system that makes it only take a few lines to use an easier to maintain CRA-style WebPack config.

However none of the ones I've seen are moving in that direction and CRA remains the only way of building a SPA this way.

[OriAmir]

@dantman
I agree with you but there is some serious problem with CRA that looks like nothing progress with them:

1. Many open issues without any answer.
2. really small PR merged into the base code.
3. Webpack 5 was released more than 1 year ago and CRA still using webpack 4.

I am sure that there are many people that want to contribute and help but no one takes care of that or does something about that.
CRA project needs someone from the React core team or from the main contributes that will try to keep that project more updated and "live".We have to do that before it's will be too late.

@gaearon @iansu @ianschmitz or whoever is relevant for that now.

[andycarrell]

@dantman you've mentioned Parcel a couple of times without a direct comparison? My understanding is that parcel does answer many of the questions / deficiencies you've identified - is there something I'm missing?

[dantman]

@dantman you've mentioned Parcel a couple of times without a direct comparison? My understanding is that parcel does answer many of the questions / deficiencies you've identified - is there something I'm missing?

@andycarrell Parcel like Vite is another of the non-WebPack systems. It also has the same issue @utajum mentioned about not doing TypeScript type checking.

I mostly skipped over it because no-one else mentioned it. Though I also have ignored it because it's the one I have prior experience with, one bad experience. Some time ago I tried porting a CRA app to Parcel. It failed with a very cryptic and unhelpful error. I couldn't find any fix for the issue or any way to troubleshoot it and figure out what was not working. So I just had to give up on Parcel entirely. So I don't know how Parcel is currently, but I didn't have a good experience with it the one time I tried to use it.

It looks like Parcel has a new major version since then. So I could take a look at it again. However parcel-bundler/parcel#4155 concerns me and makes me feel like it's no more maintained than CRA (this was fixed in WebPack 5 and I'm waiting for CRAv5 so I can update one of my deps; a bundler that doesn't use WebPack but has a major issue WebPack already fixed doesn't bode well, CRA's only problem here is being out of date, Parcel's is whether the core build system is being maintained).

[andycarrell]

@dantman very good point re typescript I wasn't aware of that limitation, although the docs seem to suggest it works out of the box? https://parceljs.org/languages/typescript/

I think the rest of your comments are quite unfair to parcel.
It's far more well maintained than CRA - a major version has been recently released and patched within the last few weeks. The reason I mentioned it in the first place is I've had the opposite experience, I found version 2 very easy to switch to from CRA v3.

I'd hate to rule it based on one or two bad experiences, and it should be considered as a viable alternative

[ryota-murakami]

@dantman @andrei9669 @OriAmir
I had the same needs as you guys for CRA, so I created a CRA-like React+TS starter based on Vite for my personal use.

vite-react-ts-extended

Installation is quite easy,
If you want to create a plain React+TS programming environment, I'm glad to anyone try it. 🐰

Installation

npx degit laststance/vite-react-ts-extended myapp

cd myapp
yarn install
yarn dev

or npm

cd myapp
npm install
npm run dev

[dantman]

@dantman very good point re typescript I wasn't aware of that limitation, although the docs seem to suggest it works out of the box? https://parceljs.org/languages/typescript/

The limitation utajum mentioned is that Vite (and Parcel) do turn TypeScript into JS, but they do not actually typecheck (validate the types) like CRA does. So the dev server doesn't tell you that you've written invalid code and lets it run anyways, effectively killing half the point of TypeScript.

I think the rest of your comments are quite unfair to parcel. It's far more well maintained than CRA - a major version has been recently released and patched within the last few weeks. The reason I mentioned it in the first place is I've had the opposite experience, I found version 2 very easy to switch to from CRA v3.

The big problem though is what each is based on. CRA is based on WebPack, Parcel is based on the parcel bundler. CRA is poorly maintained, however it's based on a well maintained bundler. In the worst case scenario you can still eject CRA and you'll be in a well maintained bundler ecosystem (though you'll have to upgrade to be on a supported version). Parcel however while better maintained than CRA, is based on a bundler specific to Parcel. And apparently from the issue I referenced, the bundler is not as well maintained as WebPack as it has a critical limitation that WebPack fixed a year ago (even if CRA hasn't incorporated it yet).

---

I did a little bit of experimentation with Vite as well today. It has some promise. However it needs a decent bit of polish to be CRA equivalent. Various bits of basic CRA functionality like SVGR were missing and I had to search through a 3rd party plugins list to find them. I also ran into issues with some important CommonJS/Node based dependencies of mine not working with Vite/rollup and I needed to hunt down plugins and bespoke config to make it work, with only Google searches and comments on random bug reports to answer what I needed to do to make these CommonJS/Node packages work.

However I still thing there's an argument to be made that there is still value in having a WebPack based way of easily building SPAs. Whether that's a well maintained CRA equivalent or something Vite/Parcel-like but based on WebPack.

Edit: And I haven't even gotten to production building yet. Which appears to depend on you running TSC separately from Vite (some concerns about that approach) and needs extra manual config to build a best practice SPA, instead of best practice being the default.

[dantman]

As I said, I still think there's an argument to be made for having a WebPack based "framework" (for lack of a better word). WebPack is effectively still the de-facto bundler and IMHO there should be a way to use it without A) needing to write 500+ lines of config to setup the basic best practices, B) being locked into a single router implementation, or C) being stuck with the obsolete version of WebPack for over a year.

Yes, other non-WebPack bundlers exist. But they may function differently and there's always a reasonable argument for using the de-facto/most widely used bundler/compiler/etc.

CRA/Next.js/Gatsby, Vite, and Parcel are based on different bundlers. I've already went over the issues with Next.js/Gatsby.

"Framework"	Bundler	JS compiler
Create React App	WebPack	Babel
Next.js*	WebPack	Babel (alt. SWC)
Gatsby*	WebPack	Babel
Vite	rollup	Babel (alt. esbuild)
Parcel	parcel-bundler	Babel

CRA/Next.js/Gatsby are the most widely used "frameworks", though Vite is catching up to Gatsby. I wont press much on this since the usage of the underlying bundler is what really matters.

https://www.npmtrends.com/gatsby-vs-next-vs-react-scripts-vs-vite-vs-parcel

Behind these "frameworks" lie the real important components, the bundler (WebPack, Rollup, and the Parcel bundler) and the JS compiler used to compile/transpile the JavaScript (and maybe TypeScript) to JS that all* browsers will understand (Babel, SWC, esbuild).

You can of course argue that popularity doesn't matter for "framework" ecosystems. For just a SPA the "framework" is pretty lightweight and if worst comes to worst all you have to do is eject/rebuild the config used to run the underlying bundler and you can still build your app even if the "framework" dies. Or just write a PR for the "framework" since it's the least complex part of the build process.

The bundler however is different. The bundler is what implements compatibility with the wider package ecosystem/browsers/etc. If bundler is not maintained you can end up incompatible with packages you depend on, missing new functionality in react/etc, your build process breaking in new versions of Node. And you can't eject out of your bundler or easily write a PR to fix these complex issues yourself. So in this case it's a good idea to use something that lots of people depend on working, lots of people have an incentive to troubleshoot and fix bugs in, and lots of people have an incentive to sponsor.

https://www.npmtrends.com/@babel/core-vs-@parcel/bundler-default-vs-@swc/core-vs-esbuild-vs-rollup-vs-webpack

Though maybe that's a lot of words to effectively say. The bundler's maintenance is the most important part of the chain and I don't really trust a "framework" (Parcel) that uses a bundler used exclusively by that "framework" (parcel bundler) especially when that bundler is used by effectively no-one, less than a JS compiler built by one developer, and is already missing compatibility fixes that other bundlers fixed a year prior.

You'd of course be right to argue that other bundlers like rollup are enough above the usage threshold that it's safe to use the "frameworks" based on them. But it's also entirely fair to expect that the current version of the bundler with the most use (by 3x) would have a quick and easy way to build a SPA using best practices and any router library.

---

I might have to re-visit this comparison with Snowpack in the mix. Though examining it it seems to have some issues too:

• At first glance you might think Snowpack is a WebPack bundler based framework as it uses WebPack (or rollup in the future) to make your build. However WebPack is only run as a final step in the production build, it's not involved during development. So you can't actually meaningfully use WebPack plugins that have anything to do with syntax (SVGR, SASS, autoprefixer, etc...) you need to use Snowpack plugins for that. And even if WebPack fixes compatibility with module loading pattern changes in the NPM ecosystem, Snowpack also needs to update its handling or things will break in dev. So it's effectively actually a snowpack-specific bundler like parcel-bundler, just with the ability to tack on any production code optimizations WebPack/rollup make. (Though to be fair, they fixed the compatibility issue that Parcel still has, so they're not as bad)
• Snowpack, like Vite, appears to also be missing CRA functionality out of the box requiring extra config. Maybe more than Vite's, but the extra config needed for Vite is growing each time I look deeper.

---

Another thing worth saying. If we truly think that CRA should die in maintenance mode and that Vite and/or Snowpack are the future. Then we need to make it painlessly easy to convert a CRA project to them. We need documentation on what conversion is needed (both use different ENV syntax; Vite uses a different index.html location and structure; Vite needs extra production config; both seem to require converting .js to .jsx if you use JSX; etc). For every feature CRA uses, we need user friendly documentation on how to get that feature working in Vite/Snowpack if you need it (SVGR, macros, CommonJS/Node based package compat). And we need codemods to assist the conversion.

[devongovett]

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.

[alamothe]

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

[OriAmir]

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.

[dantman]

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.

[OriAmir]

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.

[ryota-murakami]

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!

[cmacdonnacha]

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.

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