Typescript Migration

[riotrah]

Describe the feature you'd like:

1. Similar to recent efforts at dom-testing-library to migrate the codebase to TS, the motivations for the same migration happening to this library apply here as well.

I've had a hard time finding previous issues/PRs that propose this migration in this repo, so I've created one, at least so we know where the maintainers stand, and if possible, serve as a centralized place to coordinate a piecemeal migration if given the greenlight.

2. Here's a paraphrased from memory summary of arguments raised from around the testing-library family regarding TS:

   Premise: Typescript support benefits library users whether or not they use TS explicitly, so long as their IDEs support relevant intellisense ( which the most popular ones do )

   a. In-house type declarations ( versus those in DefinitelyTyped ) help maintain correctly versioned and maintained types.

   b. However, there is an effort overhead in terms of keeping track changes to logic with changes to exported types.

   c. Migrating the codebase to TS entirely allows maintainers to "automate" type declarations altogether, via existing type declaration build processes in kcd-scripts.

   d. However, that adds a barrier to entry for new contributors comfortable with JS and OSS contributions, but not TS.

   e. That being said, TS's rising popularity and similarity to JS anyways renders that, IMO, less of a problem.

   f. This means, assuming point (e) turns out to be true, that both contributors and consumers of this library will benefit from less-error-prone code, easier/faster understanding of library components / APIs and all around better developer ergonomics ( in my view )

Suggested implementation:

0. I don't speak for the maintainers in the absolute slightest, so here's my best guess as to how best to do this.
1. To reduce maintainer headache during code review, and simplify collaboration, the migration should probably be considered a long-ish running endeavor, with progress implemented via piecemeal/iterative PRs.
2. kcd-scripts already includes support for TS and Babel, so initial setup with library entrypoints migrated to TS should serve as an appropriate starting point with minimal difficulty ( presumably )
3. After step 2, I suppose it could as easily be an open bounty as to which files get migrated next, unless someone has a better idea.
4. Perhaps after all or enough is migrated, the manually written type declaration files can be removed in favor of build-time emitted ones?

Describe alternatives you've considered:

1. Keeping manual type declarations as-is

Teachability, Documentation, Adoption, Migration Strategy:

1. If approved/merged changes result in actual changes in externally-facing APIs - or changes in the way they're best conveyed/expressed - as a result of TS migrations, then docs and other externally facing content that describes APIs should probably change. That being said, more accurate and explcit types will reduce the need for highly specific API descriptions.

2. I am not sure what else this section is supposed to describe.