WIP: Fix loading comment replies

[CL-Jeremy]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

closes #9474.

Description

This PR makes use of the recent feature update of upstream YouTube.js Edge version to quickly fix fetching replies. Since upstream will most probably publish a release (v18?) soon-ish, I'm putting this here as a starter (based on the discussion at LuanRT/YouTube.js#1214, see additional context below). Upstream has nested replies ready so that could be implemented later Nested replies already implemented for local API (design choices have to be made).

Do note this is WIP due to depending on unreleased upstreams and some necessary temporary changes to the build process (have to avoid using self-built npm packages for security reasons, but pnpm/action-setup currently causes a bug with TypeScript compiler that is again only addressed in latest commit tip). The code works on my side. YMMV.

Screenshots

See below.

Testing

Open any video with comments and try to load them. Replies should also work.

Desktop

• OS: macOS
• OS Version: 15.7.8
• FreeTube version: 0.25.1 Beta

Additional context

• pnpm-related changes are obviously provisional and will be changed as soon as the next YouTube.js release lands.
• While loading comments now requires a full session (in order to get sub-threads) just like getting video info, the session is bound to the initial comment request, so continuations should still be fast. Note the session is reused between continuations of the same comment thread request, i. e. one per video page refresh. Question is whether that should be of concern.

[CL-Jeremy]

This is largely ready for use if the functionality (viewing comments) is all that's needed.

Tested working when built against latest edge version of YouTube.js, unfolding at most 2 layers per load.

Screenshots

During the refactor, I chose to store all the state in the (newly factored-out) local Vue component instead of mutating/emitting values that the current level doesn't own. This has the negative effect of not caching any loaded data or continuation state when the DOM subtree is removed after pressing "Hide replies" (except top level). I currently plan to explore <KeepAlive> tag, but I might get reactions on the existing changes such as having done too much unnecessary/premature refactoring, etc., so I might as well wait a bit and see how UX may be improved (but I do stand behind my code with 0 AI usage up till now, if that matters).

Also tested (largely, can't exactly confirm regression) working with latest dev version of Invidious (https://inv.nadeko.net, currently only comments via API, it's for testing anyway) with flattened replies as before. I can only say I fixed a few obvious mistakes based on testing/upstream docs.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[CL-Jeremy]

pnpm 11 makes a good point about risks of supply chain attacks, though this is currently irrelevant for this draft PR.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.