build: raise frontend typescript to 6

[shivoomiess]

Description

Upgrades the frontend to TypeScript 6.0 and bumps the @typescript-eslint toolchain to ^8.66.0 to support it. Includes the small source and config adjustments required for the codebase to type-check cleanly under TS 6.

Motivation and Context

TypeScript 6 brings stricter type-checking (notably tighter generic variance) and changes to default behaviour (no automatic @types/* inclusion, and deprecation errors for options slated for removal in TS 7). Staying current keeps us on supported tooling and surfaces latent type issues early. This is the base of a larger upgrade stack (React 19 → MUI 9 → mobile-responsive).

How Has This Been Tested

• npm run generate:sdk then tsc --noEmit — passes with no errors.
• npm run lint (frontend tsc --noEmit && eslint .) — clean.
• Verified no behavioural change in the touched components (the removed
  || 'DRAFT' branch in ProposalContainer was provably unreachable dead code).

Fixes

Changes

• package.json
  • typescript ^4.7.4 → ^6.0.3, moved from dependencies to devDependencies.
  • @typescript-eslint/eslint-plugin, @typescript-eslint/parser, typescript-eslint → ^8.66.0 (TS 6 parser support).
• tsconfig.json
  • Added "ignoreDeprecations": "6.0" to silence TS 7 removal errors for target, moduleResolution and baseUrl (temporary; tracked separately).
  • Added "types": ["node", "vite/client"] since TS 6 no longer auto-includes @types/* globals.
• MultistepWizard.tsx — validationSchema type Yup.AnyObjectSchema
  → Yup.ISchema<unknown> (concrete object schemas are no longer assignable to AnyObjectSchema under TS 6's stricter variance checking; unknown avoids any and the eslint suppression).
• ProposalContainer.tsx — removed unreachable || 'DRAFT' fallback (a JSX element is always truthy).
• QuestionaryDetails.tsx — TableRowData fields JSX.Element | string | null → React.ReactNode.

Depends on

None — this is the base of the upgrade stack, based directly on develop. (PRs #1746, #1747, #1758 are stacked on top of this one.)

Tests included/Docs Updated?

• I have added tests to cover my changes.
• All relevant doc has been updated

Follow-up: migrating the deprecated tsconfig options before TS 7 is tracked in UserOfficeProject/issue-tracker#1706.

[yoganandaness]

NOTE: It is a Stacked PR

develop <-- typescript upgrade <-- react upgrade <-- mui, table upgrade <-- mobile view

1. Each PR is functional and can be reviewed individually.
2. Merging is sequential. With the bottom PR being merged into develop, following with next bottom

[zacharyjhankin]

do we need to move it out of the dependencies list into dev dependencies in the same PR as updating the version? I guess it is probably fine, but no reason to cause more potential problems for ourselves in one go.

Maybe someone in the colab uses it in a prod pipeline for example.

I don't really mind, just worth flagging

[yoganandaness]

I think the Dockerised app is being used and hence it wouldn't cause problems. I could be wrong as well.

Also I thought it would avoid overloading the node_modules. btw in backend, typescript is situated in devDependencies.

[zacharyjhankin]

Can delete "| string "

[jekabs-karklins]

The PR is good, but I did change the title to speciffically indicate that the upgrade is only for Frontend.
And that is what I would like to flag is that the backend still sits on TS5. Although not a big issue, I would suggest uppgrading BE to 6 in the near future to keep both code bases consistent.

Interstingly I found also that validation library includes TypeScript as a peer dependnecy from ts-jest

$npm why typescript
typescript@5.9.3 dev peer
node_modules/typescript
  peer typescript@">=4.3 <7" from ts-jest@29.4.11
  node_modules/ts-jest
    dev ts-jest@"^29.1.1" from the root project

[yoganandaness]

The PR is good, but I did change the title to speciffically indicate that the upgrade is only for Frontend. And that is what I would like to flag is that the backend still sits on TS5. Although not a big issue, I would suggest uppgrading BE to 6 in the near future to keep both code bases consistent.

Interstingly I found also that validation library includes TypeScript as a peer dependnecy from ts-jest

$npm why typescript
typescript@5.9.3 dev peer
node_modules/typescript
  peer typescript@">=4.3 <7" from ts-jest@29.4.11
  node_modules/ts-jest
    dev ts-jest@"^29.1.1" from the root project

Thanks. Here is the ticket UserOfficeProject/issue-tracker#1707