You aren't doing meaningful checks or adding additional TS context, so why even bother with adding a tsconfig? Most IDEs will apply those checks with the jsdoc alone and it isn't actually checked at runtime.
Two niggles...
First: The following is TypeScript, and not the current version. While I've actually converted a lot of the projects I'm working on to TS, prefer most training examples in plain JS, also assigning the right type to the event would probably correct the any type casting.
const file = (event.srcElement as any).files[0];
...
const base64Str = btoa(reader.result as string);
Second: There's no mention of getting the correct mimetype and/or extension from the File interface.
Nice... put in a feature request for yaml/toml support... Been using yaml myself for this kind of thing for a few years now. A closer to the box linter would be nice.
I wrote config-merge for a similar use case... It merges configs/strings, and was easy enough to wire in the selected language with a component based on React Context with a useStrings component, and shimmed out a getStrings (which will get the current context outside react context, like action creators or reducers).
https://www.npmjs.com/package/@tracker1/config-merge
Yeah... for about the past 2 years, mostly been on internalized apps so stopped using most polyfils at that point. Generally only support browsers with fetch and async function support, which is everything that's seen an update since late 2017.
I agree that if I supported IE11, would probably polyfill for fetch, but at this point, I'm starting to lean towards just using ecmascript modules directly in the browser for anything public facing, which definitely excludes IE11.