Migrate BCD internals to TypeScript

[queengooborg]

With as big of a consumer base and how critical BCD is, it's important that we ensure that our code is always functioning as intended. As I have been working on Yari, I have now realized the power that TypeScript has in projects like this.

I think that we should consider migrating our internal code over to TypeScript, which should help us eliminate issues we may have during development.

(An added benefit is that in doing so, we can always be certain that our typedefs are up to date!)

[queengooborg]

CC @saschanaz @schalkneethling @caugner @foolip @sideshowbarker @bershanskiy (pretty much every contributor I can think of right now who is active and has contributed to BCD's infrastructure)

[saschanaz]

There's already JSDocs everywhere, I guess it'll be very straightforward to migrate.

[foolip]

I've read but never written any TypeScript, so I don't have a strong opinion on this.

[sideshowbarker]

As I have been working on Yari, I have now realized the power that TypeScript has in projects like this.

Same here. I’d never worked much with TypeScript until I had occasion to make some contributions to Yari. But after having working with TypeScript in Yari, I’m sold on the benefits it could also provide to maintenance of the BCD internals.

[bershanskiy]

I fully support migration to TypeScript, I used it extensively in the past and found the following advantages in my own projects:

• Type checking actually does prevent runtime bugs
• Type inference is incredibly useful, especially during development. I can hover on a varible and immediatelly get a sense of what it is and what the surrounding code does.

(An added benefit is that in doing so, we can always be certain that our typedefs are up to date!)

This is a very important point. In my opinion, inconsitent/obsolete typedefs are the largest problem with TypeScript ecosystem, and it can be reliably fixed only by ïn-depth"adoption of good TypeScript. The problem is:

• Connection between Code (function parameters in function signatures) and Typedefs can be broken.
  Lots of projects (e.g., BCD) provide manually written typedefs, so typedefs can actually diverge from the code. For example, see Update typedef file #16328 By the way, was it the original inspiration for this discussion? 😉
• Connection between Typedefs and Data (function arguments at function call sites) can be broken.
  TypeScript types are checked (by TS compiler) only at compile time, then types are stripped to produce JavaScript (which is evaluated by JS engine). In reality, JS engine never ever sees Typedefs, so it's perfectly feasible for a sufficiently large project to have two mostly isolated components which have a different concept of underying data. JS engine can actually hide some inconsistencies by doing automatic type conversion.
• Library consumers actually rely on Typedefs, so they can adopt slightly erroneous Typedefs. Once the Typedefs are fixed, existing library consumers might get compilation errors. This basically forces library authors to delay the real fix to a major release (since it is a "breaking" change).

This happens very rarely in practice, but when it does it is a huge pain to fix it. I remember reading a blog post about this exact bug in React. (I can try to find it, if you are interested.)

Also, please note that we do not have to make TypeScript transition all at once, we can break it up over time. We can start simply by renaming files from ".js" to ".ts".

[queengooborg]

Thanks for your feedback, @bershanskiy, this is all really wonderful information! The gradual transition would definitely help in this case as well!

And yes, #16328 is absolutely the motivation behind this, haha! XP

[caugner]

For the record, I would love to see BCD internals in TypeScript. 😍

[queengooborg]

It sounds like we're all in agreement! I've opened #16406 to prepare for the migration, and will commence work on the actual migration soon (once all the script changes have been merged or closed)!