Migrate toolkit reports to TypeScript

[OlegWock]

GitHub Issue (if applicable): n/a

Explanation of Bugfix/Feature/Modification:
I migrated toolkit reports to TypeScript. In most reports this meant just adding types, but some of them was incompatible with types (mostly due to using Map as structures with pre-defined set of keys instead of using plain objects). For those I had to modify code a bit, but I tested and there shouldn't be any change in behavior.

Please note this PR will conflict with #3360 so I suggest it will be merged first and then I'll resolve conflicts in this PR

[jakehamtexas]

You can avoid this renaming of the root interface by adding this extends clause.

Suggested change

	interface YNABSharedLibImpl {
	dateFormatter: YNABDateFormatter;
	defaultInstance: YNABSharedLibInstance;
	}
	type ExtendWithAny<T extends {}> = { [key: string]: any } & T;
	type YNABSharedLib = ExtendWithAny<YNABSharedLibImpl>;
	interface YNABSharedLib extends Record<string, any> {
	dateFormatter: YNABDateFormatter;
	defaultInstance: YNABSharedLibInstance;
	}

Separately, I would recommend against using any here, why do you think it is needed?

[OlegWock]

why do you think it is needed

YNABSharedLib has a lot of stuff inside of it and typing it properly will take a lot of time. As it was out of scope of current PR, but I still needed a way for TS to stop yelling at me for accessing unknown properties I come up with such solution. But I'll your suggested code more, I'll update it

[jakehamtexas]

I would suggest moving this to the declaration for chart since it will be less brittle to changes in Highcharts, and keep us from accidentally casting to a wrong type.

const chart: Highcharts.SeriesOptionsRegistry['SeriesPieOptions' | 'SeriesColumnOptions'] = { ... };

[OlegWock]

I'm not sure I follow what you mean here. Chart is instance of Highcharts.Chart and here we're casting only one of it's options object

[jakehamtexas]

I only reviewed about 30% of the diff because it's quite large. A few things I noticed are:

1. Maybe we should provide a .d.ts file for the Highlight types we use (ironic to find an actual use case for .d.ts at this point lol)
2. Perhaps it would be good to add some more linting that is TypeScript specific, now that we are at this point. Especially https://typescript-eslint.io/

[OlegWock]

Thanks @jakehamtexas ! Your comment were really helpful 🙂

Maybe we should provide a .d.ts file for the Highlight types we use

Sorry, but I don't get why we need it? (and why d.ts in particular)

[joshmadewell]

thanks for doing this! great stuff