[RFC] First-class support for TypeScript in the Expo SDK

[ide]

The Expo team is considering adding first-class support for TypeScript to the Expo SDK. For JS type systems (namely TS and Flow) we see a significant preference for TypeScript and in our own experience we find TypeScript to be stable, sufficiently expressive most of the time, and generally positive. We also find that standard, untyped JS works well and will continue to design APIs that work well without a type system.

Why

The primary reason for first-class support for TypeScript is that it is stable and works well without drawing too much on our attention for maintenance. The TypeScript team has done very good work creating smooth upgrade plans (e.g. upgrading from TypeScript 2.x to 3.x is quite smooth) and we've found their work to be reliable. We believe that making more parts of Expo -- in this case, TypeScript -- more reliable will make it more reliable to develop and use apps made with Expo.

Additionally, the very recently released Babel 7 supports TypeScript, which means we can continue to use Babel-based builds for Expo hopefully without introducing too much thrash or instability.

How

In practice, this proposal means that the Expo SDK would move to .ts files and the Flow type hints would be replaced by TypeScript type hints. Today, TypeScript type declarations (https://github.com/DefinitelyTyped/DefinitelyTyped) are helpfully maintained by developers in the Expo community and the Expo SDK provides Flow types; this would switch around where the Expo SDK would provide TypeScript types and the community, if someone were to step up, would maintain Flow type declarations in https://github.com/flow-typed/flow-typed. Given the history of solid work from the TypeScript team, the popularity of TypeScript amongst Expo developers, and the stability and reduced maintenance tax we expect from moving the Expo SDK to TypeScript, we believe this is a high-ROI tradeoff.

Some dependencies of the Expo SDK that aren't maintained by the Expo team, like React Native, Maps, and SVG, may not have complete or accurate type declarations so we expect to start with TypeScript's default non-strict mode, adding stricter options when possible in a forward-looking way (ex: will we be able to keep the strict option when upgrading a dependency in the future?).

Eventually, we may also provide TypeScript support in the new-project templates so it is easy for developers to work with TypeScript from the start. We will continue to design our APIs to work well without TypeScript, which we believe to be responsible, safe, and forward-looking.

Request for comments

We are looking to see how this proposal resonates with Expo developers, especially professionals building apps for business. Along with this RFC thread, we'll also talk to some developers in interviews and at conferences to gauge feedback before making a decision in the coming weeks.

[msevestre]

@ide I have worked with TS and flow (TS with ionic and flow with React native) and I have to agree that the developer experience, in my opinion, is far superior with TS.

Would that mean that a new expo project would support typescript out of the box? Or is this something that the user would have to configure by hand?

Cheers,

[ide]

Would that mean that a new expo project would support typescript out of the box? Or is this something that the user would have to configure by hand?

To start, a new Expo project wouldn't have TypeScript enabled but if you set up TypeScript, the Expo SDK would ship with .ts / .ts.d files for most of the Expo APIs. Over time, we'd provide guides and CI coverage for TypeScript. With this proposal, we'd like to support TypeScript well but not prescribe it.

[jhalborg]

This would be great! When I started out with React Native and Expo last April, I went with Flow because it seemed to have the most support in the RN environment and community. I wrote two production apps that way before switching to Typescript for everything since. It was for the same reasons you mention - stability and quality, as well as better and more tooling and community typings. I really hope this change goes through! 😄

[ckknight]

We currently have a tsc --watch running during development that builds everything in src/ and puts the compiled .js files into dist/. Our entrypoint then points to dist/App.js (instead of src/App.tsx).

I'd love for TypeScript support to be a built-in capability.

Types for Expo would be fantastic as well. DefinitelyTyped is out of date in a few areas.

[Kingles]

Echoing @ckknight here, as is DefinitelyTyped definitions (which have been generally great, huge thanks to the folks working to keep those up) are three major versions out of date and have led to a significant amount of headache, especially when touching edges of the built-in Expo api (some of the more esoteric Camera options, for example). Having a more-or-less guaranteed up-to-date version of the expo types would be a huge win.

[jhalborg]

@ckknight & @Kingles - You can actually use a custom transformer as examplified here and --noEmit already, but it would sure be nice to have a somewhat opinionated and supported setup from the Expo team, especially for newcomers looking to use Typescript.

[ide]

We're working on moving parts of the Expo SDK to TypeScript in a gradual way. Not all of the SDK will be typed to begin with because it's large and there are also several parts we currently don't maintain ourselves. And we're working around some of TypeScript's rough edges but don't have solutions for all of them (ex: we need "skipLibChecks" because the react-native and isomorphic-global fetch declarations from DefinitelyTyped clash in an unfixable way AFAICT).

The contributors to the DefinitelyTyped expo declarations definitely deserve thanks and a shout out, especially @janaagaard75 and @KonstantinKai who've contributed almost half of the commits to the declarations between the two of them.

edges of the built-in Expo api (some of the more esoteric Camera options, for example)

We'd definitely like to make this more robust. Currently there's five-way fragmentation between the JS, Android module definition, iOS module definition, docs, and DefinitelyTyped declarations when all of them are intended to describe the same API and it'd be nice to start coupling their interfaces together and to work towards a fundamentally better single source of truth.

[jhalborg]

We're working on moving parts of the Expo SDK to TypeScript in a gradual way. Not all of the SDK will be typed to begin with

I don't think you need to, at least not to begin with. From a consumer point of view, all we need is

1. First, and most importantly, a team-maintained definition file of the Expo API so that all API changes going forward are always reflected in the definitions that comes with the package, so it doesn't rely on the otherwise solid work of community members.

2. Perhaps more/better documentation in the Expo docs about how to set up and work with a Typescript + Expo project, perhaps springing from the also great example authored by @janaagaard75

After 1. is done, you can implement Typescript in the codebase at your own pace without the community being any the wiser, except for the few of us who sometimes contribute :-)