
Create React App 2.0: Babel 7, Sass, and More - stablemap
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html
======
b-nint
I'm disappointed setting up typescript is still such a pain with 2.0.

~~~
danabramov
Sorry. We needed to prioritize to get this release out because it's already
been snowballing for about a year.

We actually did have "TypeScript support" on a nice-to-have list for this two
week sprint but unfortunately didn't get to it:

[https://i.imgur.com/l0CpdZy.png](https://i.imgur.com/l0CpdZy.png) (I promise
I'm not making this up :-)

I'm confident we'll ship it by the end of this year though.

~~~
andrethegiant
What is the status of Flow in the JS ecosystem?

~~~
root_axis
Flow offers a more sophisticated type system that is designed to express types
that correspond with the sort of idioms you see in JavaScript in the wild.
TypeScript is simpler and less flexible, but that simplicity can translate
into increased productivity since there are less foot-guns and also less bugs.
Strange/buggy behavior and odd performances issues are not totally uncommon
with Flow whereas TypeScript doesn't seem to suffer from this as much. Since
TypeScript is much more popular, IDE support tends to be a lot better out of
the box, but the flow-langauge-server gives you all the same IDE-like features
(intelligent autocomplete, jump-to-def, module resolution etc).

Personally, I like Flow more, and I also think its easier to integrate into an
existing codebase (either as comment annotations or gradually via per-file
flow comment header), but at the end of the day, _not_ choosing TypeScript
amounts to swimming against the current without much justification.

~~~
paavohtl
>Flow offers a more sophisticated type system that is designed to express
types that correspond with the sort of idioms you see in JavaScript in the
wild. TypeScript is simpler and less flexible, but that simplicity can
translate into increased productivity since there are less foot-guns and also
less bugs.

Source? That's the primary design principle behind TypeScript too.
TypeScript's type system is powerful enough to practically do arbitrary type-
level transformation of data structures, and even do some crazy recursive pure
functional type level programming.

The only things I'm missing from TypeScript are variadic generics (which can
be emulated quite well with TS 3.0) and higher kinded types - and I don't
think Flow supports them either.

~~~
root_axis
[https://flow.org/en/docs/types/utilities/](https://flow.org/en/docs/types/utilities/)

Most of that can't be achieved out of the box with TypeScript. TypeScript was
designed as a _language_ that would bridge the quality of life gap between es5
and more modern languages, Flow was designed exclusively as a _type system_
for annotating standards compliant JS.

~~~
ng12
Not true, most of that can be done with TypeScript. $Values might be the only
one missing.

~~~
WorldMaker
$Values should be possible with Typescript 3.0+ conditional infer types,
presumably something very similar to the built-in ReturnType<T> conditional
infer type.

Untested and off the top my head but maybe something like:

    
    
        type Values<T> = T extends { [K keyof T]: infer R } ? R : any

~~~
wyze
It works, just need to add `in` in-between `K` and `keyof`.

------
sephware
> _More styling options: you can use Sass and CSS Modules out of the box._

This is what I'm most excited about. Emotion is great but I've heard a lot of
great things about CSS Modules, just haven't gotten around to trying them out
yet because it's been so complicated to do. I'll definitely be giving it a try
now.

~~~
davman
I wrote a bit[1] about CSS Modules with React, but interestingly it looks like
CRA isn't using babel-plugin-react-css-modules so I'm trying to figure out
what they're doing instead.

[1] [https://dev.to/daveirvine/postcss-with-css-modules-
andreact-...](https://dev.to/daveirvine/postcss-with-css-modules-
andreact-51ln)

~~~
ascorbic
It's perfectly fine to just use css-loader to handle CSS modules. No need for
babel. Just do:

    
    
       import styles from "./style.css";
    
       <Component className={styles.myClassName} />

------
duncan-donuts
These are some pretty great improvements. I never felt I had to have
cssmodules or sass, but I’ll definitely use them. Great work!

~~~
BigJono
If you don't feel the need to add another dependency, why would you do so?

------
tobr
I see Facebook’s React team is in the comments. Please keep in mind that the
open source aspect of React is part of Facebook’s hiring strategy. While I
believe the React team are genuine in their friendliness and passion for their
work, they also represent and are payed handsomely by one of the worst
offenders in surveillance capitalism.

(I realize some might feel a comment like this is out of place here, but
considering the recent news about enormous leaks and privacy violations, I
think it would be more strange if it wasn’t brought up.)

~~~
ukyrgf
I decided to finally bite the bullet and learn React yesterday. Every time
they mentioned "we do it like this at Facebook" in the tutorial/docs, my
eagerness died a little more. Even little tongue-in-cheek things, like their
shopping list app consisting of companies they've acquired (Instagram, Oculus,
WhatsApp) felt like a bummer.

~~~
danabramov
Hey, thanks for feedback!

Regarding "we do it like this at Facebook" \-- could you point out examples
where this isn't useful, and we could remove them? I wrote some of these,
mostly to highlight that if something works for a massive codebase with
50,000+ components, it will probably work for yours, even if it doesn't look
familiar. I don't know what's an alternative way to say it without losing the
core of the message.

Regarding the tongue-in-cheek one. Well. I don't feel strongly about changing
it if many people feel this way.

------
amelius
I tried Babel some time ago, but I can remember it was painfully slow. Has
this improved?

I also didn't understand why so much functionality for different languages are
harbored by a single tool, instead of multiple smaller tools.

~~~
mercer
I'd say 'multiple smaller tools' is actually what Babel has become. It started
out as a tool to compile ES6 to ES5 (6to5 it was called), but now it's a kind
of framework(?) that you can add various smaller packages to for various
'transpiling' purposes.

------
chrisweekly
Stoked to see service workers will use Workbox!

------
pyman
Thanks for all the hardwork. I used this library when I worked at Uber and
Netflix.

------
magicbuzz
Is it possible to use Redux without an eject?

~~~
daok
It always been...

~~~
magicbuzz
and redux-saga?

~~~
seankimdesign
Of course redux-saga can be used. Unless your goal is to rewire the project
compilation step, ejecting is rarely required.

------
laurent123456
> If you previously ejected but now want to upgrade, one common solution is to
> find the commits where you ejected (and any subsequent commits changing the
> configuration), revert them, upgrade, and later optionally eject again.

That seems insane to be honest, yet it's seems to be the norm to upgrade a
framework in JavaScript (same with React Native). Is that the best solution
there is? In many other languages, you can upgrade a framework without
reverting commits or trying to figure out what to keep or change in huge
diffs. Surely there should be a way to keep the base config untouched, and
have user changes in a separate config that overrides the base on?

~~~
franciscop
Create React App is not a framework, it is more similar to a scaffolding
system that sets up a group of tools and processes. You can upgrade React
normally without issue.

The equivalent to what you suggest would be to autogenerate some files with a
tool, modify the location and structure or those by hand and then expect the
tool to be able to modify then again seamlessly.

