CRA is devil! This is good article and I totally agree.
Here is my thoughts:
CRA is very bloated, it creates 16K of files in your node_modules folder;
CRA forces you to use many things that you don't need;
CRA does not allow you to use external shared typescript code as it maintains tsconfig.json for you and does not allow you to add some props to it, for example you cannot use "paths" property as CRA just resets it on every start. It does not even allow you to reference code outside your src, what???
CRA is only for SPA and if you wanna keep frontend and backend in the same repository (monorepo)... so you will have to hack around it to avoid duplication of node_modules folder etc... (yarn workspaces solve this problem, but it is unnessecary time waste)
CRA is only for SPA and if your project suppose to have several apps you will meet the same problems as above + when deploying all the apps to the same, say, nginx container you will hit the problem where react's static folders override each other, or you have to mess around with nginx config to split things up... what a mess....
CRA is toy for dummies, it creates noise in frontend community and some folks think it's a best practies and afraid to admit that they spend days hacking around this crap...
Yes, you can learn how to cook it, and there are many people who will argue with me, but I will never admit that CRA is efficient and reliable way to run project... eventual you do "eject" and live with tones of crap that will be deprecated very soon...
I recommend you to use CRA for learning, but not for real project or you end up fighting against its limitations and "best practies"
The only advantage is that it comes with hot reload feature, but you can do it yourself anyway or just grab it from github
I'm not crazy (CRAzy?) about CRA either, but I do use it and have found workarounds to two of the points you mention:
there are several npm packages that allow more customization of the CRA tsconfig.json, so you can do things like link external project folders
depending on your deployment platform, you can make a monorepo work. I have a server node instance that runs separate of CRA, and the CRA instance proxies unhandled requests back to it (CRA has built-in support for this). At build+deployment time, the CRA project builds to a dist folder that the main project assumes responsibility to serve, so the whole thing can run as a single server instance
Neither of these steps are very confidence inspiring, but then neither is maintaining your own custom build stack. I've done that for personal projects in the past, and it runs into a problem where you have to futz with it just infrequently enough that you forget what you did last time, and have to relearn it all over each time. Between that and the CRA boilerplate, I'm not sure what's better.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
CRA is devil! This is good article and I totally agree.
Here is my thoughts:
CRA is toy for dummies, it creates noise in frontend community and some folks think it's a best practies and afraid to admit that they spend days hacking around this crap...
Yes, you can learn how to cook it, and there are many people who will argue with me, but I will never admit that CRA is efficient and reliable way to run project... eventual you do "eject" and live with tones of crap that will be deprecated very soon...
I recommend you to use CRA for learning, but not for real project or you end up fighting against its limitations and "best practies"
The only advantage is that it comes with hot reload feature, but you can do it yourself anyway or just grab it from github
I'm not crazy (CRAzy?) about CRA either, but I do use it and have found workarounds to two of the points you mention:
there are several npm packages that allow more customization of the CRA tsconfig.json, so you can do things like link external project folders
depending on your deployment platform, you can make a monorepo work. I have a server node instance that runs separate of CRA, and the CRA instance proxies unhandled requests back to it (CRA has built-in support for this). At build+deployment time, the CRA project builds to a dist folder that the main project assumes responsibility to serve, so the whole thing can run as a single server instance
Neither of these steps are very confidence inspiring, but then neither is maintaining your own custom build stack. I've done that for personal projects in the past, and it runs into a problem where you have to futz with it just infrequently enough that you forget what you did last time, and have to relearn it all over each time. Between that and the CRA boilerplate, I'm not sure what's better.