[Feature]: Upgrade repo to TS 6.0.3

[mainframev]

Area

Tooling

Describe the feature that you would like added

Upgrade the Fluent UI monorepo from TypeScript 5.7.3 to TypeScript 6.0 and resolve the release's breaking changes and deprecations so that the repository remains on a supported compiler path and is prepared for TypeScript 7.0

The migration should include:

• Update the root TypeScript dependency and version pins in maintained starter templates
• Replace deprecated moduleResolution: node/node10 settings with the appropriate modern strategy:
  • bundler for browser or bundler-owned projects
  • nodenext for projects executed directly by Node.js
• Remove deprecated baseUrl settings and rewrite paths entries where needed so existing aliases resolve identically.
• Audit tsconfigs that rely on ambient @types discovery and add minimal explicit types entries such as node, jest, or webpack-env
• Verify that rootDir, module, target, strictness, side-effect import checking, and other changed defaults are explicit wherever repository behavior must remain stable
• Fix source-level errors caused by TypeScript 6.0 inference or syntax changes
• Update the workspace generators/templates

Additional context

TypeScript 6.0 is a transition release for the native TypeScript 7.0 compiler. Options deprecated in 6.0 will be removed in 7.0, so addressing the migration now avoids coupling the compiler upgrade with a larger future configuration rewrite.

Current repository findings:

• The root package.json pins TypeScript to 5.7.3
• The Vite React Components starter template uses ~5.7.3
• Shared configs use deprecated moduleResolution: node
• The main, v8, merged-path, and Web Components base configs use deprecated baseUrl
• Central configs already set strict and rootDir explicitly, but project-level configs still need to be audited for the new types: [] default and other changed defaults

TypeScript 6.0 release notes:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-6-0.html#breaking-changes-and-deprecations-in-typescript-60

stableTypeOrdering may be useful temporarily to diagnose TypeScript 6.0-to-7.0 declaration differences, but it should not be enabled permanently because the TypeScript documentation notes a potentially significant type-checking cost

Have you discussed this feature with our team

No response

Validations

• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

Priority

Medium