4 ms·
Well, we had a 50K sloc codebase written in Flow. We had invested heavily in the type system for quality control, so we had types everywhere. This made it riski
by AriaMinaei 8y ago
Well, we had a 50K sloc codebase written in Flow. We had invested heavily in the type system for quality control, so we had types everywhere. This made it riskier for us to switch to another type system, which is why we stuck with Flow for longer than we should have.
The way I finally did it was that I tried out TS on a side-project that I wrote from scratch. I did expect better tooling with TS, but I was still surprised by how better the experience was.
Auto import just worked. Same with code navigation. And they made me work much faster. Intellisense was also much better. And the error messages more readable. (And they've gotten even better since)
All of these things work to some extent in flow+vscode, but the experience with TS was incomparably better.
I was still hesitant to switch the larger project to TS though, mainly because we were using some of Flow's more advanced features to type-check a function like `wrap()` in this code:
const obj = {foo: true, bar: {baz: 2}}
const wrappedObj = wrap(obj)
wrappedObj.get('foo') // returns true
wrappedObj.get('bar').set('baz', 'some string') // type error. baz must be a number
This was almost possible to do in Flow using `$ElementType<>` and `$Call<>`, but TS had no counterpart for `$Call<>`. Luckily though, TS soon came up with conditional types, which turned out to be a much more reliable way to handle these cases.
That's when I decided to switch the codebase to TS. It took about 5 days. It wasn't straightforward, but in the end, it gave us a much smoother developer experience.