Create-React-App 3.3
github.com
github.com
The whole idea of "you need to eject" and can only eject one time to install a package that allowed me to use JSX If/Else statements [1] turned me off to the whole thing. Now I have a custom project and just create new ones with cookiecutter
Im open to being wrong here, but the experience kinda sucked IMO.
Works fine for overriding Webpack config at least.
https://github.com/gsoft-inc/craco
I needed it to get CRA working in a lerna/yarn workspaces monorepo. Super impressed with how easy config is.
Don’t want this to be purely negative though. I am a huge fan of cra overall and it has helped me immensely with setting up new projects and prototyping. Just hope the core simplicity will stay.
- `index.js` is required as the entry point for the app
- `App.js` is the main app component
- `App.test.js` shows you can write a test for a component
- `App.css` shows you can import CSS files directly into the JS to have it included in the output
You can begin editing those files, or just delete all but `index.js` and start writing your own.
Many folks who have used CRA will just immediately delete those. Beyond that, some folks have forked the `react-scripts` package just to set up a different project source template.
Adding an option to specify a template means that other folks can now publish their own CRA-compatible project source templates and have them work with CRA right away. For example, I'm a Redux maintainer, and we could create a CRA template that already has a dependency on Redux (or our new Redux Toolkit package), all set up and ready to go without the user having to manually install them.
The different package tools mentioned in the release notes serve different purposes. `npm` and `yarn` are competing JS package managers. They both install and update packages from the NPM registry, with some different features available. `npx` comes with the `npm` tool, and is a way to quickly run CLI packages like `create-react-app` without having to explicitly run a separate "install this globally" command first.
And yes, RTK is intended to be useful for both new and experienced Redux users [0], and we're now recommending it as the default standard way to write Redux logic [1].
See the RTK v1.0.4 release notes [2] for the details on the name change.
[0] https://redux-toolkit.js.org/introduction/quick-start
[1] https://redux.js.org/style-guide/style-guide#use-redux-toolk...
[2] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4
I’m about 18 months out from last using it, but people were saying this then and it was, in fact, full of bugs and missing features. The company I was at kept starting projects with it because it was trendy, then switching to NPM when we tried to use a feature yarn didn’t have or lost an hour debugging some problem that turned out to be yarn-induced breakage. This was the consistent experience of about a dozen developers across several projects, most of whom were very enthusiastic about yarn, at first.
Maybe it’s much better now but, again, people have been saying this since it first came out and if it’s true, it’s a recent development.
- Messing up certain cases of dependency resolution such that you'd get a different version than NPM would give you.
- Something involving not checking paths they should have been, that caused brokenness.
- Local package problems of several sorts—really any 1%-of-users-or-lower use case, and I'd guess "just fetch some packages from the NPM servers" is the sole use case over 1%, seemed fairly likely to have problems.
- All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn.
There were more but I don't remember all of them. My impression was that they implemented half the features of npm, did way fewer correctness and safety checks, crowed about how fast they were, and everyone crowned it as a superior drop-in replacement for npm literally years before that would be justified.
Mind I have no love for npm and don't much care what the command I run is called or who made it, I just repeatedly saw projects start on yarn then hit a silly problem the simplest fix for which was "use npm", while people were running around shit-talking npm and acting like yarn was some kind of miracle.
[EDIT] our projects were node, React, and React Native. I'd definitely believe it's possible use Yarn and never hit this if you don't happen to use a package that's broken in it and has only been tested under npm, or happen to step on one of the landmines, and maybe it actually is totally fine now, I just know people were claiming it already was and sticking their fingers in their ears when you told them otherwise back when it absolutely was not a suitable npm replacement yet.
NPM can mess up it's own dependencies, or give you different dependencies on different machines. It's algorithm is (was?) non-deterministic.
> - Local package problems of several sorts
I use yarn with lerna to keep a monorepo of local packages together, it works pretty well. At the time, npm didn't.
> - All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn.
Never ran into anything like this. Show me a package that doesn't work with yarn
Yarn gave npm some much needed competition and made npm improve a bit. Before yarn, npm didn't even have lockfiles. Having both is good, but I've just had less issues with yarn overall.
Been too long, don't remember. Happened more than once. Options were "debug package under yarn, and assuming there's a way to fix it without modifying yarn itself, submit PR to package's repo" or "just use npm".
Naïve search for 'is:issue is:open "npm works"' over yarn's ~2,000 open issues reveals some packages that don't work with it, pretty quickly. I'm sure npm has bugs too but we consistently and reliably ran into yarn problems that could be fixed immediately by switching to npm, on several projects. A browse through their issues more generally reveal tons and tons of broken features and edge cases, still, looks like, which is how it was back when I was using it, too.
If it's working for folks that's fine, but I think it's still a bad idea to give (especially) newbies the impression yarn's clearly the best choice.
I think Rust was the first to do it (if you don't count Haskell's more general do-notation). Can anyone confirm that?
Or, depending on how you feel about sending a message to nil simply returning nil, Objective-C?
Swift's variant is much more modern, though, as it has the ability to inline assert.
https://docs.swift.org/swift-book/LanguageGuide/OptionalChai...
The CLI probably enables a few dozen features, of which you might use a handful of. So there's all these files and configuration code in your project that is never touched/used. I imagine it's a lot of white noise.
Whenever I start new projects, I cleanroom start with an empty git repo. Every line, in every file, has a purpose. (With time, there is some slippage. A feature could get removed, and some code doesn't get eliminated that should, for example). But all in all, the vast majority of the code there serves a purpose.
Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all.
I take a functional style, with the above, to allow myself to really be able to focus on my work. I sometimes feel alone in this approach, but it works for me and I see it's benefits. I place a big premium on clarity.
It does create a build process, but not content. This frees me to focus on my code. Were I to struggle with getting the build to work when that isnt my goal, I'd likely half ass it, make basic errors, and struggle to reinvent the wheel. (Actually, I know this because I do periodically do this just to make sure I understand what CRA does for me. Each time I find months of changes and tweaks I have to learn that I definitely suck at keeping up on even when I have a project that doesnt use a boilerplate)
CRA isnt like other boilerplate apps - either I dont get your point or you choose a poor example to hang your point off of.
But the main advantage of CRA is the fact that it satisfies the needs of the vast majority of the ecosystem, allowing other tools to assume that config for their default setup. For example, enabling Storybook for a CRA-created app hardly any effort.
Modern frontend build tooling is complex, and getting it right in a way that it's (a) correct, (b) maintainable, (c) extensible, and (d) upgradeable is ridiculously hard.
You'll make mistakes that will cause your bundles to balloon in size, or produce assets you never asked for, or fail to produce assets you really needed. You'll be asked to add features to the system that will require full refactors of everything because you didn't think of extensibility upfront. You'll accidentally use libraries that end up being abandoned, or those that break compatibility. You'll want to upgrade to new versions of a single tool, but you'll be stuck in dependency hell where upgrading TypeScript will require a new version of Babel, which will require a new version of Webpack, which will require new versions of seventeen random libraries, and now you're spending your entire week fixing the build instead of writing features.
I know CRA has more features than a lot of people need. But deal with the white noise (and a few extra megabytes of node_modules) and just use it without ejecting. A huge team of smart people is already doing all the dirty work of making sure builds work as expected so you can concentrate on features. Please just use their work.
I didn't find manual configuration of all that to be all that difficult to learn. I feel like people get a ton of use from CRA when learning, and then are told never to touch the magic black box of CRA because it is just so hard. So they never do. And never realize that it isn't as bad as all that.
I do think it provides a great service for new coders, or small projects. So I do recommend using it in many cases. But I completely reject the idea that only 5 people in world are smart enough to set up their own build configs.
There's a rather irritating tendency to frankly insult the intelligence of anyone that's not working on $BIG_NAME_PACKAGE, as though the people working on these libraries are from outer space and not (most often) rather regular humans who've ended up on particular career paths due to planning and/or being strategically positioned at the right time.
For some reason it's particularly prevalent in the JS community, where it especially does not make any sense considering that it's a very active open-source scene with plenty of people pointing out bugs and submitting fixes to popular packages every day. I wonder if it's a frontend web dev thing in general - it's common to see people make similarly hyperbolic statements about CSS (no, it's not that hard to centre a div, and even if it was it says more about you if you agonise over it every time you encounter it and not just, I don't know, save the working snippet somewhere and refer to it when you need it).
I apologize if what I said came across like that. I don't mean to insult the intelligence of people who want to roll their own build tooling, I just want to point out that doing so is a waste of time when somebody else has put in the work of building doing that for you. I would say the same thing to someone who wanted to build their own web framework instead of just using Rails/Django, or someone who wanted to build their own blog engine instead of using WordPress/Jekyll.
Your time is valuable. Don't waste it on writing Webpack configs.
Of course, if you're doing any of this to learn how things work, then more power to you! But if you're putting hand-rolled versions of popular frameworks and libraries in production, then you're doing a disservice to those who have to maintain those things after you've left your job.
I can say with confidence that most posters on HN (including myself) will do a worse job at setting up a build system than CRA. There are hundreds of contributors fixing issues in CRA, and all of them are really smart people. It's an open-source project with thousands of eyes looking at the code. I doubt that a lone developer working in a silo could come up with something better.
I wanted to compile a second app with different babel settings and have that in my webpack config.
I gave up on it after a few hours of trying to figure out what I would need.
Is this really a super rare case that only experts should attempt?
When I ejected CRA it gave me a 600 line config file.
I think I also find the general attitude of the community ("it's all modular!") to be disingenuous. Just bundle all this stuff into a monoremp massive npm package and be done with it, ala rails.
This is one of my least favourite thing about CRA. The equivalent Webpack config tailored to the needs of my project is generally only 100-200 lines long. CRA makes things far more complicated than it needs to be because it has to support everyone's requirements.
That certainly does not excuse me from learning how to use craco to define babel plugins to make sure my material-ui imports are optimized [1], but it does end up saving me a lot of time that I'd rather spend elsewhere.
I've also found that CRA produces smaller apps than even Parcel 1... which apparently is fixed in Parcel 2, but I have yet to try it as it is still in development 3 months after I finished my last project. ;-)
[1] https://material-ui.com/guides/minimizing-bundle-size/#optio...
In return, you get:
- A Webpack+Babel build config that has excellent default behavior out of the box for browser support and code splitting, and supports working with many common types of assets including images, CSS, and SASS
- The Jest unit test runner configured to automatically pick up any test files
- A linting ruleset that only warns for potential errors
- An error overlay that pops up whenever there's a UI crash, minimizes irrelevant parts of the stack trace, and lets you jump to the relevant lines in your editor
- The ability to easily update to improvements in the build system (such as this 3.3.0 release) simply by updating the `react-scripts` dependency.
And, CRA has had a _ton_ of work put into it to smooth over various pain points and incompatibilities between browsers, Node, and the various tools that it's built on.
While CRA doesn't have a built-in way to override its config files, there are several widely used "CRA override" tools like `craco` [0] that allow you to opt-in to modifying parts of the config to suit your needs. I personally no longer have a need to "eject" a CRA project, as the override tools are more than sufficient to let me make whatever config edits I need (such as [1]).
CRA has eliminated the question of "How do I set up a working build setup for a React project?", and made it way easier for folks to write tutorials that focus on the code, not the build setup.
[0] https://github.com/gsoft-inc/craco
[1] https://github.com/markerikson/cra-spectacle-mdx-boilerplate...
Also, it'd add more substance to the discussion, but I really am curious how many people eject. Is it, the minute it (CRA) can't do what you need, you have to eject? Or it becomes exceptionally difficult to interface with a tool that just abstracts away more tools? It's possible those abstractions might not give you the full level of customization would could potentially need, if project requirements shift.
CRACO seems like an admission that CRA, on its own, could be somewhat half baked. The ability to want to override some things without fully ejecting seems like an obviously wanted feature of a toolkit.
Most folks won't need to customize the standard CRA behavior. If you do, there's the community override tools.
As a specific example, two years ago I wrote a tutorial on how to use the Cesium 3D globe library with Webpack [0]. Loading Cesium at the time required changing two Webpack config options, so my tutorial started with "create a CRA app, then eject".
I recently set up a brand new CRA project that also uses Cesium. I could have used `craco` or a similar override tool to apply those Webpack config tweaks myself, but there's actually a `craco-cesium` plugin [1] that applies those edits and handles copying Cesium's assets to the CRA build output folder. This new project didn't have to eject at all.
As another example, that same project also needed to do more customization to the dev server proxying setup than CRA normally allows. CRA lets you define a simple `"proxy"` option in `package.json`, or a `setupProxy.js` file that gets a reference to the Express app to add middleware. I actually needed to apply a proxy middleware at the _end_ of the chain. `craco` let me access the actual Webpack config setup to do that [2].
The other nice thing about these override tools is that your modifications are isolated in one place, so you know exactly what changes are being made. If I were to eject and get all those config files in my project, yeah, I wouldn't know what had been edited from the originals without digging into the Git history. This way, it's one `configOverrides.js` file at most, and I get all the benefits of the rest of CRA's config which has had thousands of man-hours put into it.
[0] https://blog.isquaredsoftware.com/2017/03/declarative-earth-...
Re-loading ny app i to a new CRA harness seems possible but fiddly. The last time I tried I got bogged down in dependency hell because so much had changed (unusual things like my auth library failing when backed by a more modern React). It all remains on the long-term aims list.
I don't think there's that many uses cases that can't be done within CRA. I think there's very limited reasons to eject.
I hate CRA, and I wish it would go die in a hole.
Though... in this comment thread I learned of the existence of something called "craco", so maybe that'll solve my problems the next time some damn students use stupid CRA when they could just copy and paste the frickin' working webpack config we gave them in the previous assignment.
If you need to use CRA behind a different publicPath in dev (behind a gateway) you can't and need to eject.
Would you mind providing some examples?
It would be handy to know exactly what they are running into... so I do not.
I’ve seen some messy, messy work as a result of it. It’s not even CRA’s direct fault, but it has a lot of people convinced that everything is there and you can just run with it from there.
That is extended by some of the advice that if you need a small utility function you should just install a package instead of writing the 3-liner yourself. I find that kind of advice seems to be aligned with CRA in the community.
And on a personal level I prefer having more control over my build methods. Not an overly huge fan of react-scripts on that note, either.
All this said, I haven’t touched it for some time.
I just bit the bullet a few years ago and invested time into learning all the moving parts of a full-stack React app, and created generic build scripts with common libraries - it has everything I need and nothing more. I've continued using it to this day, keeping it up to date has been painless mostly, and have built a number of business applications with it.
A big advantage of CRA I see is that it provides a standard, well-developed and documented. It's suited for onboarding junior team members, as well as allowing people to jump into new codebases.
Otherwise I would first spend half an hour setting up Webpack, Babel, Prettier, eslint etc. before even writing a single line of code.
Most, if not every project I do, I start from scratch, and build the pipeline when I have a need for it. It also forces me to understand the way my app will be build. I've met a lot of developers who only use these pre-build setups, or only use bootstrapped templates that they don't even know what they do, and personally, that scares me.
It used to be that every single React tutorial started with "First, we're going to install Webpack and Babel", and half the tutorial would be filled with configuring those before it even got to the React code.
As a specific example, 3 years ago a React tutorial for building a Yelp clone made it onto the front page of HN [0]. The comments bashed it for spending a ton of time on build setup (and somewhat justifiably so).
Now, React tutorials just start with "run `create-react-app my-app`", and go from there.
For the custom setup I'm using now I tried Parcel and I must say it's pretty good. It hides a lot of the complexities of webpack+babel but it also has its limitations (in, like, a different way though that makes it a better fit for my project).
You use CLI generators for hand-holding, so that you don't have to write lots of code but this works in only the basic hello world kind of projects. As your project gets larger, this same hand-holding gets in your way as you have to understand, twist and tweak someone else's code unnecessarily.
I also disagree with your assertion that this only works for basic “hello world” type projects. I’ve yet to work on a project that’s been hampered by CRA’s limitations; I’d reckon it’s sufficient for at least 90% of React apps.
Do I miss spending hours configuring Webpack builds, CSS and HTML processors, JS compilers, linters, unit and e2e testing frameworks, dev servers and npm dependencies before I can even start coding on the problem I really want to solve? No, I do not.
Depends on the CLI. The AWS SAM CLI or create-react-app or poetry for python, no. But certainly I've run into some where that's the case.
> The CLI probably enables a few dozen features, of which you might use a handful of.
Depends on the CLI. Certainly many do not have this problem.
> Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all.
Yeah, and that's nice, but IME this isn't a problem with code from a good-fit-for-purpose CLI; this isn't a place where I'm burning energy with, e.g., SAM or poetry, or even CRA (though in the last case I can imagine circumstances where it would be an issue, but it hasn't been for me in practice.)
My guess is people still think Webpack is hard to configure despite that being quite simple now.
Except the Apple tax, you can always work around those costs: for example, build Android apps with no IDE and no simulator and writing your own makefiles from scratch. But that doesn't really make any sense if your development work is any sort of business. If your hobby is toolchain configuration, then go for it. CRA feels the same to me.
Facebook released a highly competent Web UI library, and it was a game changer for how I thought about UI on the web at all.
Do I want to give my entire build process for the web to them? No.
Android Studio was released by the group who released the platform. XCode was released by the group who released the platform. Facebook didn’t build the web. I personally prefer having much more control over what code goes into my app.
The only useless thing I recall removing was some service worker code in the default template. If that bothers you it looks like they're making it easy for you to make your own template that's even leaner.
Will I understand everything that's happening? No, but that's a non-goal when I'm starting out. The hope is that I get started, google the stuff I don't understand and gradually understand all the components and why they're there. When I become a JS pro, it's possible the sane defaults won't work for me and I'll choose something else, with an approach similar to yours.
Sadly, you have to fight the creators of the underlying tools tooth and nail to make that functionality the default behavior. Run CRA eject and look at the horror that is the resulting configs.
Which is still way too many, and I'd love it if the JS community would spend some time working on collapsing the dependency trees for widely used tools like Webpack.
> For TypeScript users, we're deprecating --typescript in favour of --template typescript.