Create-React-App 3.3

https://github.com/facebook/create-react-app/releases/tag/v3.3.0

by revicon • 7 years ago

114 91 7 years ago

github.com

tomashubelbauer• 7 years ago

Isn't it odd that the removal of --typescript in favor of --template isn't considered a breaking change?

acemarke11• 7 years ago

It's not removed, it's just being deprecated. I would assume it would only be removed in 4.0:

For TypeScript users, we're deprecating --typescript in favour of --template typescript.

Vinnl2• 7 years ago

You only run that when starting a new project, right? So no existing projects would break when it's actually removed, because they'd never run it again.

JMTQp8lwXL4• 7 years ago

Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it?

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.

SenHeng• 7 years ago

I typically start such a new project by cloning from a boiler plate repo that I created myself. I find those easier to use than CRA.

rajatsharma912• 7 years ago

That's a good strategy, I occasionally use that too, but a better strategy is to keep isolating often repeated functionality in your project and turn them into library packages, so you can simply add them as a dependency from now on. This way, you boilerplate becomes smaller over time or you can even start from scratch easily.

JMTQp8lwXL4• 7 years ago

I have my own babel+webpack+etc repo I clone for mini-things I want to dig into (e.g., how does "tool x" work?) and I can freely explore learning that tool, without clouding my production important code base. I then transport those learnings back, and the implementation is more refined, since it's clearly written by somehow who knows how to effectively use Tool X, without haphazardly throwing it around.

Keats• 7 years ago

I do the same. I find it much easier to understand and I've always needed to modify the config anyway. I wrote about my own boilerplate in https://www.vincentprouillet.com/blog/react-typescript-webpa... and the Webpack config is like 75 lines. It could work with Vue or anything else just as well.

My guess is people still think Webpack is hard to configure despite that being quite simple now.

52-6F-623• 7 years ago

I do the exact same. I find this is especially important where license and dependency management is a concern.

cstuder• 7 years ago

CRA sets up a completely working development environment, I can start coding immediatly. The code I have to remove from CRA is minimal (Clean out App.js, delete the CSS file). It saves a _lot_ of mental energy for me.

Otherwise I would first spend half an hour setting up Webpack, Babel, Prettier, eslint etc. before even writing a single line of code.

acemarke11• 7 years ago

No, because CRA explicitly encapsulates and hides all that functionality inside the `react-scripts` package. You only add a single dependency to your own app's `package.json`. All the config files are in `node_modules/react-scripts/config` if you really want to look at them, but otherwise they're effectively hidden.

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

JMTQp8lwXL4• 7 years ago

Correct me if I'm wrong, but if you eject, all of those files and NPM dependencies are just dumped into your main package, even if you didn't need that configuration? E.g., let's say CRA supports SCSS files. You eject and now you have a webpack config that can handle SCSS files, but your project doesn't use them. Now you have white noise. A really small, and potentially trivial example, but that sort of buildup is death by a thousand cuts to a project. "What does this line do?" "Do we need it?" future engineers will ponder.

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.

woutr_be• 7 years ago

I recently did a project that used the create-react-app CLI, and felt a bit anxious. I know the setup that create-react-app creates, but I still prefer to write this all myself.

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.

latchkey• 7 years ago

Personally, I love working on features and building apps more than I like dealing with the esoteric and always changing ins and outs of java/typescript build systems. CRA solves that problem for me, without creating a lot of cruft in my folder.

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

rajatsharma912• 7 years ago

You are absolutely right! The quantity of white noise is so much that at some point of time, you'll end up thinking that it would have been much easier had I started this project from scratch instead of inheriting this monstrous code!

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.

jakelazaroff3• 7 years ago

What white noise? None of the configuration files are exposed unless you eject.

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.

brlewis3• 7 years ago

I think you have in mind something that's very different from create-react-app.

t0astbread• 7 years ago

I'm also working with a custom build flow now but I always found CRA to be way easier. It just works vs. with a custom webpack/babel/etc setup there's so many moving parts that I had to manage that it never worked as well as a CRA project. Afaik CRA also hides most (all?) config files from you until you eject.

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

dmitriid• 7 years ago

CRA (and other CLI tools for other projects) provide out-of-the-box functionality that you already want, most likely.

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.

ergothus• 7 years ago

I normally hate boilerplate apps. CRA is an exception. It doesnt pre create any content of significance. ( basically a hello world page, although it has a demo image file to rip out)

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.

Vinnl2• 7 years ago

I guess a large part of that is that you literally don't have to worry about the stuff that CRA does for you behind the scenes. With most boilerplates, after you clone it you have to check for updates, and whatever you do with it afterwards is your own responsibility - including e.g. updating configuration when the tools you use change, completely negating the purported advantage of that boilerplate. With CRA, you simply update react-scripts and you should be mostly there.

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.

nindalf2• 7 years ago

I think CRA's core audience is people like me - JS noobs. I have no idea about all the things I need to do to start a JS project or how to get it deployed. CRA tells me - "just run this line and you're good to go". The goal is lowering the barrier to entry by giving sane defaults.

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.

acemarke11• 7 years ago

I'm a JS and React _expert_, and I still use CRA all the time whenever I want to spin up a new project because I don't want to take the time to mess with all the build setup. I just want something that works right.

xixixao• 7 years ago

Btw CRA is essentially what traditional IDEs have had for decades baked in - it’s just that the JS world doesn’t (yet) revolve around monolithic IDEs.

joshgachnang• 7 years ago

One of the biggest benefits of these CLIs is they give everyone a common starting point. If everyone is putting together their own webpack config, etc, the chances of finding someone who can quickly answer "why isn't X working" go down drastically. That's awesome for beginners and advanced users alike.

acemarke11• 7 years ago

Exactly.

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.

[0] https://news.ycombinator.com/item?id=11778663

z3t42• 7 years ago

create-react-app installs almost one million packages. So I understand why one don't want to do that manually. But that is crazy!

acemarke11• 7 years ago

Nitpicking: last time I checked, it was around 1500.

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.

GeneralMaximus2• 7 years ago

I say this as someone who has been paid ridiculous amounts of money just to help configure and improve build systems: please just use CRA for all your React projects. Or, if you need server-side rendering, use Next.js. There are, like, five people in the world who have any business manually configuring Webpack+Babel+SASS+TypeScript+$WHATEVER, and all of those people are already working on CRA.

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.

awongh• 7 years ago

I've been finding that I go outside the base config quite quickly.

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.

codingdave• 7 years ago

There are, like, five people in the world who have any business manually configuring Webpack+Babel+SASS+TypeScript+$WHATEVER, and all of those people are already working on CRA.

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.

stupidcar• 7 years ago

No, because what these CLIs actually provide is a preconfigured build system, not the straw-man overstuffed boilerplate you are suggesting they do.

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.

pavlov• 7 years ago

I think of CRA as a cost of doing business in today's web apps, just like the cost of doing Android dev is to download Android Studio and let it install bazillion GBs of stuff; the cost of doing iOS dev is to buy a Mac, install Xcode and pay Apple an annual $99; etc.

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.

52-6F-623• 7 years ago

I disagree.

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.

jholman2• 7 years ago

Every month some new batch of students use CRA for their final project. Every other month month I deal with some idiotic mess CRA has made that a 3-line patch to a config file would fix, but I can't fix that without ejecting, which all the advice tells them not to do. Often it's proxy problems, sometimes it's something else, I can't really keep track.

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.

petetnt• 7 years ago

Hi jholman, part-time maintainer of CRA here. Sorry that Create React App has caused you and your students problems. Would have a specific list of issues (or specific ones like proxy issues) that you needed to eject for to fix that we could look at and improve in the future?

52-6F-623• 7 years ago

I wouldn’t use language quite as strong as yours, but I have always preferred working without it outside of a quick prototype. It’s just so many dependencies that aren’t really needed... I can’t justify it.

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.

duxup• 7 years ago

"some idiotic mess CRA has made that a 3-line patch to a config file would fix, but I can't fix that without ejecting, which all the advice tells them not to do. Often it's proxy problems, sometimes it's something else"

Would you mind providing some examples?

It would be handy to know exactly what they are running into... so I do not.

Red_Leaves_Flyy• 7 years ago

If it's happened more than twice you should probably consider giving your current and future students information on how to handle the issues your previous students have faced. Going off the harsh language in your comment, your disdain for CRA may be showing to your students which may make you seem unapproachable.

dragonwriter• 7 years ago

Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it?

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

brlewis3• 7 years ago

Actually cra hides the boilerplate configuration in react-scripts. If you want to touch the configuration that you never need to touch, there's eject. It's my intention never to use eject.

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.

cageface• 7 years ago

I think a lot of people have been waiting for this in order to start using the new optional chaining and nullish coalescing operators. Thanks to the Typescript and CRA teams for making this happen. This will be a nice quality of life enhancement.

davedx2• 7 years ago

Hmm. I’m a frequent user of cra but this release reads quite confusing. What are templates and why do I need them? Why are there 3 different package tools used (npx, npm, yarn)? What is all that babel config for? I have to be honest, the main reason I use cra is so that stuff is abstracted away, and this release looks like a lot of it is starting to “spill back out”.

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.

acemarke11• 7 years ago

CRA's default template gives you several files in `/src`. In the default template, most of those files are intended as examples:

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

davedx2• 7 years ago

Thanks for the breakdown! I find it really difficult to track everything that's going on in the react ecosystem. I realise for many people 'npx' is something that's been available for a while now but it's one of the many things I haven't had time to look at yet

darekkay• 7 years ago

I am using redux-starter-kit in one of my projects and I was curious about the "Redux Toolkit" package you mentioned. I have somehow missed the change of name, but I find it more fitting now. Highly recommended, even for experienced Redux users.

chrisweekly2• 7 years ago

I hear you, but FWIW CRA continues to do a pretty admirable job hiding the complexity. I think it's fair to say that the 3 tools you referenced by name are elementary / required knowledge before working on a Node-based project, and it'd be impossible (or crazy) for CRA to try to abstract them away: `yarn` is a generally superior alternative to `npm`. `npx` is a convenient alternative to globally-installed packages.

shantly3• 7 years ago

`yarn` is a generally superior alternative to `npm`.

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.

leshow4• 7 years ago

So interesting that a few years after Rust introduced the optional chaining operator, it's been filtered through the lens of many major languages out there.

I think Rust was the first to do it (if you don't count Haskell's more general do-notation). Can anyone confirm that?

jsolson• 7 years ago

Swift?

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

leshow4• 7 years ago

Rust had it before Swift did, I remember when the ? proposal came down the pipe to replace the try! macro and Swift didn't have it yet

rpeden• 7 years ago

I think C# (and VB) had it before Rust. My memory of the timeline might be a bit off, though. I know C# and VB got the chaining operator in 2015.

RubenSandwich• 7 years ago

After some digging, I think Groovy got it first. Here is a blog post from 2009 about it: https://mrhaki.blogspot.com/2009/08/groovy-goodness-safe-nav....

leshow4• 7 years ago

Cool, thanks for this. Rust/Swift's variant is arguably a little different (because it works with a sum type) but I think the influence is pretty clear here.

mchristen• 7 years ago

Coffeescript has that operator.

misiti37802• 7 years ago

Am I the only one here that loves the idea of create-react-app but doesnt use it because it is almost impossible (or rather, was almost impossible as of a few months ago) to utilize features in webpack etc.

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.

[1]https://github.com/AlexGilleran/jsx-control-statements

pcmaffey• 7 years ago

Use craco.

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.

misiti37802• 7 years ago

this is exactly what i was looking for, thank you!

zuck92• 7 years ago

You can use https://github.com/timarney/react-app-rewired to override anything in the default CRA config

sli• 7 years ago

I don't think this works on CRA 3 and it's development has slowed a lot. craco (listed in the alternatives) supports CRA 3.

w33ble• 7 years ago

Nope. My company ended moving off it because it’s not extensible at all. create-poi-react-app is a nice alternative, same functionality (and more) while using webpack chaining and allowing you to bring your own eslint config (or anything else).

JMTQp8lwXL4• 7 years ago

I see comments praising they can now use new ECMAScript proposals, e.g., nullish coalescing. If you hadn't been at the mercy of an abstracted build tool, you could've upgraded your build system yourself. I don't like the idea of running my projects like that. If I want something in my project, I get it. There's none of this "waiting around" for it.

ng12• 7 years ago

Yeah, it's such a huge failure on Facebook's part. It's completely unusable in an enterprise environment and I can only recommend it for small one-off applications. The tagline they use but is "convention over configuration" but it's really "convention without configuration". It's frustrating the amount of times you find a GitHub issue for a feature you're looking for and the answer from the CRA team is "well we've decided you don't really need it" -- even for things that are a simple one or two line config in Webpack.

Create-React-App 3.3

Related Stories