Katex: Consider using TypeScript instead of Flow

[ylemkimon]

Related: #1938

@kevinbarabash It seems you own https://github.com/Khan/flow-to-ts, how difficult is it to migrate to TS?

[kevinbarabash]

I think it's worth understanding what benefits TS would be providing us vs what benefits Flow already provides us. I don't think it would be particularly difficult to migrate. I do have concerns about the lack of exact object types in TS. Another concern is around type-safety. Flow treats all variable assignments and passing of variable params invariantly (readonly when variables/params are covariant) whereas TS treats them as covariant all of the time which is inherently unsafe.

I don't think the migration would be that difficult. flow-to-ts needs some more work especially around bulk updates of files.

[edemaine]

I imagine the main issue is that TypeScript is becoming pretty popular. At least, providing TypeScript bindings would be nice, so that a caller can try to be typesafe, though I think there isn't yet a nice way to do that directly in our own repo/NPM package (?).

[kevinbarabash]

We could add a katex.d.ts file at least manually to start with. It would nice to build the .d.ts file automatically in the future though.

[kevinbarabash]

I've started using TS for a project and it's working well. I actually used flow-to-ts to do the conversion. The two main issue around type safety are:

• TS allows passing parameters that are covariant
• TS' lack of exact object types
• TS doesn't check if the implementation of a type guard actually results in the type refinement that it promises to do.

The first two issues can mainly be addressed by making parameters to functions and properties in object types readonly which is a good practice anyways. The second issue is actually a double edge sword. Even though TS doesn't check that the refinement makes sense, it means that we can write type guards that aren't possible in Flow since Flow restricts itself to a single expression.

I think that assertion functions that were added in the 3.7 release could be quite useful in our codebase.

[kevinbarabash]

In terms of the actually difficulty of the this change, I don't think it'll be that hard. The main thing that we'll have to do manually is update our type guards and make the appropriate changes to our build config.

I do think that once we make the change, we should consider making as many things readonly as we can. Unfortunately, things in TS are not readonly by default which means having a bazillion readonlys everywhere unfortunately. 😞

[kroltan]

I do think that once we make the change, we should consider making as many things readonly as we can. Unfortunately, things in TS are not readonly by default which means having a bazillion readonlys everywhere unfortunately. 😞

You could reduce the bazillion readonlys to just a few million by using the Readonly<T> utility wrapper. Basically instead of applying readonly to each field, you surround the type definition and all fields will be made readonly. More info on linked docs.