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 (I promise I'm not making this up :-)
I'm confident we'll ship it by the end of this year though.
Oh wow, that statement is so much more than I'd have expected - there's something to look forward to!
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.
For several versions now, Typescript also supports type annotations in JS comments and an allowJS mode for mixing TS and JS in the same project, or using only JS and JS comment type annotations.
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.
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.
type Keys<T> = keyof T
type Values<T> = T[keyof T]
type Readonly_<T> = Readonly<T>
type Shape<T> = Partial<T>
type NonMaybeType<T> = NonNullable<T>
// Exact<T> cannot be implemented because TS doesn't have exact types as a separate concept,
// It should be noted that object literals are exact by-default if there's a type annotation
// Issue: https://github.com/Microsoft/TypeScript/issues/12936
type Diff<A, B> = Pick<A, Exclude<keyof A, keyof B>>
// Rest<T> should be equal to Diff, because TS doesn't have exact types
type ElementType<T, K extends keyof T> = T[K]
// PropertyType in unnecessary, because T[K] works for everything
// Note that this is variadic - "Args" is an array of arguments
type Call<F, Args extends any[]> = F extends (...args: Args) => infer B ? B : never
// This works for both objects and tuples.
type ObjMap<T, F> = { [K in keyof T]: Call<F, [T[K]]> }
// I couldn't figure out how to implement Class<T>, but you can access the type of a class instance with
// typeof ClassName.prototype
// $SuperType and $Subtype are not documented, so I can't try to replicate them.
// TypeScript doesn't have existential types, but you can emulate them within the type system, or avoid them using e.g "infer"
// Discussion and encoding https://github.com/Microsoft/TypeScript/issues/14466#issuecomment-338045331
[1] https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript-Handbook/blob/master... [3] https://github.com/facebook/flow/blob/cf03c08109014c4503a392...
Untested and off the top my head but maybe something like:
type Values<T> = T extends { [K keyof T]: infer R } ? R : any type Props = {
age: number
name: number
}
type Values = Props[keyof Props]Why does the project generated by react-native-cli contains some flow syntax by default? this is stupid. Not everybody has a flow plugin for his IDE. And obviously flow type declarations are not valid JavaScript. I understand you want to push your stack onto your users but no need to be that invasive.
I'd list Create React App as the number one best JavaScript technology of all time, awarded for the massive pain saving it confers. It allows the most fabulous thing in the world, which is to avoid using the JavaScript tooling.
I've setup about 4 projects over the past year, if you feel like you need help feel free to email me any particular pain points you have and I'll try to get you through them, email in profile (not a react contributor, just frequent react/typescript user on financial applications)
Add typescript, babel typescript, add the plugin in babelrc, and update the Babel cli build command in package.json to look for ts file extensions.
That enabled me to start incrementally adding typescript into an existing node.js codebase, I was surprised how easy it was.
package.json (scripts)
BABEL_ENV=development babel -d build/ src/ --extensions \".ts,.tsx,.js\" --quiet --source-maps inline
"type-check": "tsc",
@babel/preset-typescript, typescript
presets: ["@babel/typescript"]
{
"compilerOptions": {
"target": "esnext",
"module": "commonjs",
"declaration": true,
"outDir": "build",
"strict": true,
"allowSyntheticDefaultImports": true,
"esModuleInterop": true,
"skipLibCheck": true
}
}Native TypeScript support will be a huge improvement.
I haven’t personally followed the status of TS in CRA closely, but I know it’s a popular request among our users so I would love for us to make it easy.
Sometimes it gets confusing connecting the negative news of these large companies to their cool open source projects.
I’ve been pretty happy with the team’s thoughtful approach to adding a dependency or not.