
TypeScript support added to Create React App - mattwoodnyc
https://github.com/facebook/create-react-app/pull/4837
======
netcraft
offtopic, but I'm in the middle of trying to convince my small team to pick up
typescript for a new significant node backend for our company. It seems like a
no-brainer from my perspective. Compilation is fast, we would use `strict` but
would allow devs to default to `any` if the types got too hard. There are no
downsides but so many upsides - better refactoring, intellisense,
documentation, communication of interfaces, protection against the javascript
and library minefields. Glad to see there are lots of other people thinking
this is valuable - wish I could figure out the right way to convince my team.

~~~
ergothus
> There are no downsides but so many upsides

I've not used TS, but from what I've read the types from TS are not js
compatible, so once you go into TS you have code that just isnt js.

(As opposed to flow, where you can just have it not be used)

While transpiling is normal, I'm as hesitant to tie myself to TS as I am to,
say, a non-standard decorators syntax. Anyone coming to me with "there are no
downsides" in such a case doesnt sound very credible.

Assuming I'm wrong, how would you address this?

~~~
smt88
You're wrong.

Once you transpile the TS, you have standardized ECMAScript. Want to stop
using TS? No problem. Just delete your TS files and work from your JS files.

And, beyond that, TS is intended to be a superset -- never incompatible, just
"extra".

Finally, you can use TypeScript the same way Flow is used, through comments.

Tying yourself to TS isn't really something you can do, and there's zero risk
in using it. You can always throw it out later.

~~~
h1d
> No problem. Just delete your TS files and work from your JS files.

This is quite an irresponsible comment.

The JS code generated isn't really meant for editing especially if you used a
feature that isn't present on the runtime (like async/await in browser), not
to mention all the formatting is rearranged.

If you're willing to go back to JS, you want to keep the original source.

~~~
smt88
"Irresponsible" is a bit of an overstatement, don't you think? The TS team
explicitly says their goal is to generate readable JS, unlike (for example)
Clojure or Scala.

Also, the async/await thing isn't an issue if you target the latest ECMAScript
version. That's the only really ugly thing, and it's been easily avoidable for
over a year.

~~~
h1d
Readable JS doesn't mean, convert back to the file in the format you used to
for editing.

That comment could make people throw away the original and end up with machine
generated code when going back.

~~~
smt88
Have you read transpiled TS before? It's sometimes almost identical to the
source. It's as close as you can get to just removing the static typing.
Variables have the same names, for example.

I used to have a problem where I'd be debugging the JS instead of TS file
because visually, they were almost identical.

------
davidjnelson
Diff of the pull request: [https://github.com/facebook/create-react-
app/pull/4837/commi...](https://github.com/facebook/create-react-
app/pull/4837/commits/506d1734e02823ad8094ede96a9aa4110381e586)

~~~
baddox
Interesting that the first line of that pull request removed the Oxford comma.

~~~
AbuAssar
I'm pretty sure it wan't intended at first place though.

------
markatkinson
This is awesome. I recently moved from Typescript to plain Javascript for a
project and it is quite frustrating.

You don't realise what you had till it's gone!

~~~
z3t4
For someone stubborn that refuse to use TS, what are you missing ? Is it the
IDE tools or the compiler error messages, or writing type annotations ?

~~~
jimsmart
In addition to icholy's points, stronger typing means one traps a whole class
of errors at compile/build time, as opposed to runtime.

------
karmakaze
BTW, anyone here used ReastReason, BuckleScript is it? I've been meaning to
look into it but don't have a sense of the payoff. I read that it can coexist
which is a great feature. Wonder how it compares to a TypeScript workflow.

~~~
scottmf
As much as I want to love it, I’ve found it far too restrictive, which makes
it difficult to play around with and learn (although error messages have
recently improved).

And while I like that JSX is built-in, I don’t like that it’s so different.
And having to use <div> ReasonReact.stringToElement("Blah") </div> (The spaces
are required) everywhere instead of <div>Blah<div> makes it feel like a poor
imitation of JSX and isn’t fun at all. But maybe they’ve fixed some of that.

Someone else said Reason is “better”. The type system might be more sound but
TS is far more flexible and forgiving, and doesn’t have ugly and off-putting
syntax for promises/async and interop.

~~~
baddox
I find the benefits outweigh those disadvantages, but I would never suggest
switching to Reason for a non-experimental project at work because I think the
disadvantages scream “this isn’t quite ready yet.”

------
solidr53
Pretty much just file extension support and docs. The support mainly comes
from Babel 7.

~~~
cix_pkez
I'd call that a good thing, really. Not needing ever more dependencies.

I think this is a solid direction to go.

Let's just say I give the React devs... props.

~~~
mikewhy
Funny, cause just using typescript to compile means you get to drop a lot of
Babel dependencies / eslint dependencies.

~~~
WorldMaker
There's still react-scripts-ts [1] which drops the majority of Babel in the
CRA pipeline for solely Typescript. Presumably, it will remain active as it is
still a useful alternative if you know you are going to want Typescript from
day one. (This Babel-based support is perfect for those unsure and looking to
experiment, which is great.)

[1] [https://github.com/wmonk/create-react-app-
typescript](https://github.com/wmonk/create-react-app-typescript)

~~~
mikewhy
I use react-scripts-ts. There's an open issue discussing the future of it now
that CRA does it on its own.

[https://github.com/wmonk/create-react-app-
typescript/issues/...](https://github.com/wmonk/create-react-app-
typescript/issues/431)

------
chris_st
I'd love to use TypeScript, but I've hit walls of errors that are nearly as
bad as the old C++ template errors! (Though to be fair, this was a while ago,
the compiler may have improved).

SO: Any _good_ way to learn TypeScript, particularly the more complicated
types?

~~~
acemarke
What sort of errors are you running into, and what project setup are you
using?

If you're using Create-React-App-TS, that's a separate fork of CRA 1.x that
adds TS support, and has _horribly_ restrictive lint rules (many common style
practices are treated as _compile_ errors). See
[https://github.com/wmonk/create-react-app-
typescript/issues/...](https://github.com/wmonk/create-react-app-
typescript/issues/333) for discussion. (I ran across this while trying to set
up a TS project for another team.)

I'm happy to see the TS support in CRA 2.x, because now I can actually
recommend that people use it to get started with TS support.

I personally had never actually _used_ TS at all until this last week, when I
was helping that same team rework some of their code. They'd been slapping
`someVar : any` across the entire codebase just to make the compiler shut up.
I tried adding a type representing their API response object, added it as a
prop to the appropriate React component, and showed them how you could start
getting autocomplete and compile-time catching of mistakes, and suddenly they
began to see that there were actually benefits of using TS, not just overhead.
I'm hoping to try adding TS support in to my own team's codebase in the near
future.

~~~
Nican
I use TypeScript every day, and I like it way better than JavaScript, but here
is an example of a bad error message:
[http://ss.nican.net/photo_2018-10-22_22-09-58.jpg](http://ss.nican.net/photo_2018-10-22_22-09-58.jpg)

~~~
acemarke
Yup, totally agree - that's pretty tough to read.

In that _specific_ example, I think the key part is the "... is not assignable
to ServerRoute | ServerRoute[]". It's just giving you all the fields in the
type of the object you _are_ returning, and trying to tell you "I can't go
from an A to a B". But yes, hard to pick out the key bits of info in there.

------
matchbok
Great to see. Any javascript project of reasonable size quickly eventually
collapses under its own weight.

~~~
dwaltrip
Typescript looks interesting and increasingly appealing -- it is high on my
list of tech to explore.

However, absolutist statements are not very useful... It shouldn't even need
saying, but clearly large javascript projects do succeed from time to time.

~~~
BigJono
"Time to time" is reductive even. Large Javascript projects succeed all the
time, and have done for decades. This whole thread needs a bit of perspective,
no matter what you think of Typescript, the web wasn't invented in 2015...

~~~
dwaltrip
Very true. I was being soft with my language in an effort to make my point
more digestible.

