build(eslint-config-fluid): update @typescript-eslint to v8

[tylerbutler]

Updates @typescript-eslint packages from v7 to v8 with necessary rule migrations and configuration adjustments.

Changes

• Update @typescript-eslint/eslint-plugin and @typescript-eslint/parser to v8
• Migrate rule: no-throw-literal → only-throw-error
• Remove deprecated and deleted rules: ban-types, no-empty-interface, and others
  • I removed all typescript-eslint rules that are deleted or deprecated. This resulted in some trivial changes to the config of some rules (rulesets often keep the old, even deleted, rules around for awhile "just in case" -- they just set them to "off" -- so we'll still see them in the printed configs).
• Update codebase for new rule requirements (explicit returns, type annotations)

Test plan

• CI passes with updated ESLint configuration
• All lint errors resolved across codebase

[Copilot]

Pull Request Overview

Updates the TypeScript ESLint plugin from v7.18.0 to v8.18.2, adapting configuration to handle breaking changes in the new major version. The update removes deprecated rules and introduces new ones for better TypeScript code quality.

Key changes:

• Upgrade TypeScript ESLint plugin and parser to v8.18.2
• Replace deprecated no-throw-literal with only-throw-error rule
• Remove deprecated ban-types and no-empty-interface rules and their disables
• Add no-restricted-types rule to discourage null usage in favor of undefined

Reviewed Changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
package.json	Updates TypeScript ESLint dependencies to v8.18.2
base.js	Removes deprecated rule configurations and adds new v8-compatible rules

Files not reviewed (1)

• common/build/eslint-config-fluid/pnpm-lock.yaml: Language not supported

[tylerbutler]

@jason-ha This rule seems to be triggered on a lot of presence code with the typescript-eslint upgrade in this PR. My hunch is they're false positives, but I didn't look closely. I am not inclined to do a deep investigation on most issues until we're on a stable/supported version of the stack. But since this is a custom rule, it could also be a bug there, or something else.

I could also make them warnings for now instead of disabling, so they could be investigated more deeply. Or if you think a deeper investigation is warranted and should be blocking, I'm open to discussing.

@Josmithr FYI.

[Josmithr]

Last I recall, that rule still had lots of issues and is disabled in a lot of places across the repo. Could use some investment, I think.

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  249533 links
    1776 destination URLs
    2013 URLs ignored
       0 warnings
       0 errors