WebUI: Convert JS files to TypeScript

[Piccirello]

This PR convert all JS in src/webui/www/private/scripts to TS. The typechecking isn't super strict yet (it allows implicit any), but this gives us a good starting point. From here, we can then export strict types from all of our modules (i.e. window.qBittorrent.* classes).

To serve as an example of strict module typing, a few modules have been modified to properly export their types. This includes AddTorrent, Cache, ColorScheme, ContextMenu, FileTree and Misc. All usage of window.qBittorrent.$MODULE is type checked.

[HanabishiRecca]

That's a chunky one. Not sure if it's a good idea to introduce so many changes here (including functional ones), as it could be too difficult to comprehend for reviewers.

[HanabishiRecca]

There is default HTMLElementTagNameMap type.

[HanabishiRecca]

This is not safe, document.getElementById returns null if element doesn't exist.
Do we have a contract that all used elements would always exist?

Generally speaking, it's better to avoid as casts when possible. This case would require a runtime check though.

[Piccirello]

This is meant to be a direct replacement for existing code that calls document.getElementById(). The existing code always assumes the requested element exists, so this new code keeps that behavior. In the future I think it would be useful to refactor that.

[Piccirello]

That's a chunky one. Not sure if it's a good idea to introduce so many changes here (including functional ones), as it could be too difficult to comprehend for reviewers.

This was intended to be as few changes as necessary to get TS compilation working with any amount of type safety. The only large-ish refactor was introducing getElementById, and that was just to avoid introducing 100+ type casts throughout the code.

[HanabishiRecca]

But tsc produces results regardless of errors, unless you explicitly set noEmitOnError.

My proposal was to (at least initially) keep all type checking stuff purely on the dev's side.
I.e. during build we could run tsc --noResolve --noCheck or some other faster transpiler without type checking like esbuild.

[Piccirello]

But tsc produces results regardless of errors, unless you explicitly set noEmitOnError.

My proposal was to (at least initially) keep all type checking stuff purely on the dev's side. I.e. during build we could run tsc --noResolve --noCheck or some other faster transpiler without type checking like esbuild.

I don't think there's any point in using TS if we allow type errors. CI should enforce that there aren't any type errors in order to merge. I can break up the current PR if it's easier to review, but I do think these changes are ultimately necessary.

[HanabishiRecca]

I'm talking about primary build script. End users / packagers should not hit that IMO.
For CI type check could be set up as a separate action.

[Piccirello]

I'm talking about primary build script. End users / packagers should not hit that IMO. For CI type check could be set up as a separate action.

I'm not completely following. How would the primary build script differ? And how would we enforce "no new type issues" in CI if we already have ~700 type issues?

[HanabishiRecca]

And how would we enforce "no new type issues" in CI if we already have ~700 type issues?

As I said, we simply don't enforce it for now. Check locally, submit.
Most people would also see errors inside their IDE.

But if you insist on enforcing it, I'm not in a position to argue 🙂

[Piccirello]

@Chocobo1 do you have any thoughts on this?