ESLint: Enable recommendedTypeChecking lint rules

[jsjames]

This PR adds in tseslint.configs.recommendedTypeChecked to improve our typescript code. The largest required update is that the "any" type can no longer be used as a crutch as it eliminates any typescript checking.

Most of the files have been updated - there are a few where specific eslint checks have been disabled at the top of the file. Those can be addressed over time.

[relativeci]

#4696 Bundle Size — 12.83MiB (~+0.01%).

58cc8f0(current) vs bdcaa5f main#4693(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   4 changes 1 regression

	Current #4696	Baseline #4693
Initial JS	1.58MiB(~+0.01%)	1.58MiB
Initial CSS	0B	0B
Cache Invalidation	6.72%	6.67%
Chunks	603(+0.17%)	602
Assets	687(+0.15%)	686
Modules	2595	2595
Duplicate Modules	0	0
Duplicate Code	0%	0%
Packages	123	123
Duplicate Packages	1	1

Bundle size by type   1 change 1 regression

	Current #4696	Baseline #4693
JS	11.11MiB (~+0.01%)	11.11MiB
CSS	895.5KiB	895.5KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	45.73KiB	45.73KiB
Other	847B	847B

Bundle analysis report Branch jsjames:lint-add-typeChecked Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[jsjames]

@digitaldan - could you review the changes made to the thread-provider code. the changes are typescript enhancements to address some of the errors in linting.

[florian-h05]

I have reviewed everything except for the thread-provider, over LGTM. A few comments:

[jsjames]

I added the @typescript-eslint/promise-function-async rule and fixed those instances where a functions returned a promise and were not async. I'd recommend (and this is what I implemented) is that we rely on the autowrapping that occurs for async functions - i think that will be cleaner.

As an aside, I think we should enable this rule as well:
"@typescript-eslint/explicit-function-return-type": "error"

This will make the core more readable/documented as it will be clear what the return value is for functions. Thoughts?

[florian-h05]

This will make the core more readable/documented as it will be clear what the return value is for functions. Thoughts?

For my part, I don't need it, as IntelliJ does a good job in displaying the return type if none is explicitly written down, and IMO it keeps the code "less verbose" to not write it explicitly.

[florian-h05]

LGTM, thanks!
Thread network map changes look good as well, but let's wait for @digitaldan to confirm.

[digitaldan]

Sorry, just seeing this today, I just tried this out and it looks good to me 👍

[digitaldan]

LGTM