Bump typescript from 6.0.3 to 7.0.2 in /web

[dependabot]

Bumps typescript from 6.0.3 to 7.0.2.

Commits

• See full diff in compare view

Maintainer changes

This version was pushed to npm by microsoft1es, a new releaser for typescript since your current version.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Greptile Summary

This PR bumps the typescript devDependency from 6.0.3 to 7.0.2. TypeScript 7 is a major architectural shift — the compiler is now a native Go binary, which removes the in-process JavaScript programmatic API that tools like typescript-eslint rely on for type-aware analysis.

• tsc compilation (npm run build): The tsconfig files use explicit target, module, and types settings that are compatible with TypeScript 7, so tsc -b should continue to work.
• ESLint type checking (npm run lint): typescript-eslint@8.61.1 declares typescript: \">=4.8.4 <6.1.0\" as a peer dependency and depends on TypeScript's in-process JS API, which does not exist in TypeScript 7.0. All type-aware lint rules will silently fail or throw at runtime.
• TypeScript 7 distribution model: 20 platform-specific optional binaries are now added as optional dependencies, and tsserver is replaced by LSP.

Confidence Score: 3/5

The tsc build step should survive the upgrade, but the ESLint linting step will lose all type-aware rule enforcement because typescript-eslint's required programmatic JS API does not exist in TypeScript 7's Go binary.

TypeScript 7 removes the in-process JavaScript API that typescript-eslint 8.x depends on. The peer dependency constraint (<6.1.0) is hard evidence that this combination is unsupported, and the lock file confirms npm worked around it by duplicating packages rather than resolving the conflict. Type-aware linting will be silently broken after this merge until typescript-eslint ships support for the TypeScript 7.1 programmatic API.

web/package.json and web/package-lock.json — the typescript-eslint peer dependency conflict needs to be resolved before merging.

Important Files Changed

Filename	Overview
web/package.json	Bumps typescript devDependency from ~6.0.2 to ~7.0.2; TypeScript 7 ships as a Go binary with no in-process JS API, breaking typescript-eslint type-aware rules
web/package-lock.json	Lock file updated to TypeScript 7.0.2 with 20 new platform-specific optional binaries; typescript-eslint sub-packages duplicated under node_modules/typescript-eslint/node_modules/ to work around the unresolvable typescript <6.1.0 peer dep constraint

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[npm run build] --> B[tsc -b]
    A --> C[vite build]
    B --> D{TypeScript 7.0.2 Go Binary}
    D -->|tsc CLI works| E[Type checking passes]
    C --> F[Bundle output]
    G[npm run lint] --> H[eslint .]
    H --> I[typescript-eslint 8.61.1]
    I --> J{Tries to load TS programmatic JS API}
    J -->|API does not exist in TypeScript 7.0 Go binary| K[Type-aware rules silently fail or throw]
    J -->|Expected in TS 7.1| L[API available]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[npm run build] --> B[tsc -b]
    A --> C[vite build]
    B --> D{TypeScript 7.0.2 Go Binary}
    D -->|tsc CLI works| E[Type checking passes]
    C --> F[Bundle output]
    G[npm run lint] --> H[eslint .]
    H --> I[typescript-eslint 8.61.1]
    I --> J{Tries to load TS programmatic JS API}
    J -->|API does not exist in TypeScript 7.0 Go binary| K[Type-aware rules silently fail or throw]
    J -->|Expected in TS 7.1| L[API available]

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
web/package.json:35
**TypeScript 7 programmatic API unavailable — typescript-eslint will break**

TypeScript 7.0 is built as a native Go binary and ships without the in-process JavaScript programmatic API that `typescript-eslint` (and all `@typescript-eslint/*` packages) depend on for type-aware lint rules. The stable JS API is not expected until TypeScript 7.1. As a result, any ESLint rule that requires type information will silently fail or throw at runtime — confirmed by the peer dependency constraint `typescript: ">=4.8.4 <6.1.0"` still present in all the `typescript-eslint` sub-packages in this lock file.

The Microsoft-recommended workaround for projects not yet ready to drop type-aware linting is a dual-package alias: keep `"typescript": "~7.0.2"` for the `tsc` binary while aliasing the programmatic package separately (`"typescript6": "npm:typescript@~6.0.2"` and pointing `typescript-eslint` at it via its `parserOptions.program` or the `TSESTREE_TYPESCRIPT` env var).

### Issue 2 of 2
web/package-lock.json:2949
**Unresolved peer dependency conflict in lock file**

The `typescript-eslint` entry at this line still declares `"typescript": ">=4.8.4 <6.1.0"` as a peer dependency, and npm resolved the conflict by nesting a separate copy of the `@typescript-eslint/*` packages under `node_modules/typescript-eslint/node_modules/`. This dual-copy structure means the top-level TypeScript 7.0.2 is visible to `tsc`, but `typescript-eslint` will still try to resolve the TypeScript package from the in-process JavaScript API — which does not exist in TypeScript 7's Go binary distribution. The ESLint type-checking step will either error out or silently skip all type-aware rules during `npm run lint`.

_{Reviews (1): Last reviewed commit: "Bump typescript from 6.0.3 to 7.0.2 in /..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[netlify]

❌ Deploy Preview for household-cfo failed.

Name	Link
🔨 Latest commit	28ea7ac
🔍 Latest deploy log	https://app.netlify.com/projects/household-cfo/deploys/6a53066837600a0008e933b6

[greptile-apps]

TypeScript 7 programmatic API unavailable — typescript-eslint will break

TypeScript 7.0 is built as a native Go binary and ships without the in-process JavaScript programmatic API that typescript-eslint (and all @typescript-eslint/* packages) depend on for type-aware lint rules. The stable JS API is not expected until TypeScript 7.1. As a result, any ESLint rule that requires type information will silently fail or throw at runtime — confirmed by the peer dependency constraint typescript: ">=4.8.4 <6.1.0" still present in all the typescript-eslint sub-packages in this lock file.

The Microsoft-recommended workaround for projects not yet ready to drop type-aware linting is a dual-package alias: keep "typescript": "~7.0.2" for the tsc binary while aliasing the programmatic package separately ("typescript6": "npm:typescript@~6.0.2" and pointing typescript-eslint at it via its parserOptions.program or the TSESTREE_TYPESCRIPT env var).

Prompt To Fix With AI

This is a comment left during a code review.
Path: web/package.json
Line: 35

Comment:
**TypeScript 7 programmatic API unavailable — typescript-eslint will break**

TypeScript 7.0 is built as a native Go binary and ships without the in-process JavaScript programmatic API that `typescript-eslint` (and all `@typescript-eslint/*` packages) depend on for type-aware lint rules. The stable JS API is not expected until TypeScript 7.1. As a result, any ESLint rule that requires type information will silently fail or throw at runtime — confirmed by the peer dependency constraint `typescript: ">=4.8.4 <6.1.0"` still present in all the `typescript-eslint` sub-packages in this lock file.

The Microsoft-recommended workaround for projects not yet ready to drop type-aware linting is a dual-package alias: keep `"typescript": "~7.0.2"` for the `tsc` binary while aliasing the programmatic package separately (`"typescript6": "npm:typescript@~6.0.2"` and pointing `typescript-eslint` at it via its `parserOptions.program` or the `TSESTREE_TYPESCRIPT` env var).

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Unresolved peer dependency conflict in lock file

The typescript-eslint entry at this line still declares "typescript": ">=4.8.4 <6.1.0" as a peer dependency, and npm resolved the conflict by nesting a separate copy of the @typescript-eslint/* packages under node_modules/typescript-eslint/node_modules/. This dual-copy structure means the top-level TypeScript 7.0.2 is visible to tsc, but typescript-eslint will still try to resolve the TypeScript package from the in-process JavaScript API — which does not exist in TypeScript 7's Go binary distribution. The ESLint type-checking step will either error out or silently skip all type-aware rules during npm run lint.

Prompt To Fix With AI

This is a comment left during a code review.
Path: web/package-lock.json
Line: 2949

Comment:
**Unresolved peer dependency conflict in lock file**

The `typescript-eslint` entry at this line still declares `"typescript": ">=4.8.4 <6.1.0"` as a peer dependency, and npm resolved the conflict by nesting a separate copy of the `@typescript-eslint/*` packages under `node_modules/typescript-eslint/node_modules/`. This dual-copy structure means the top-level TypeScript 7.0.2 is visible to `tsc`, but `typescript-eslint` will still try to resolve the TypeScript package from the in-process JavaScript API — which does not exist in TypeScript 7's Go binary distribution. The ESLint type-checking step will either error out or silently skip all type-aware rules during `npm run lint`.

How can I resolve this? If you propose a fix, please make it concise.