👷 Update dependency typescript to v7 - #189
Conversation
|
There was a problem hiding this comment.
PR Review — Score: 2.5 / 5
This Renovate PR bumps the dev-only typescript dependency from 5.9.3 to 7.0.2 across the root workspace, playground, e2e app, and all seven integration fixtures. There are no SDK source or runtime changes, but the upgrade is not merge-ready as written. I would not approve until the typescript-eslint peer-dependency conflict is resolved and the integration fixture lockfiles are regenerated.
Why 2.5: The scope is limited to dev tooling (no customer-facing behavior change), and root/e2e/playground lockfiles were updated consistently. However, two concrete blockers remain: typescript-eslint@8.64.0 declares typescript >=4.8.4 <6.1.0 and relies on the classic TS compiler API that TypeScript 7 does not expose, and all seven e2e/integration/apps/*/package.json files now request 7.0.2 while their yarn.lock files still pin 5.9.3 (Renovate's artifact-update warning matches this). GitLab CI was still running when this review was posted.
Why not 5: TypeScript 7 is a major compiler rewrite (native Go port) with ecosystem gaps — type-aware ESLint cannot run against it today. The PR also ships an incomplete lockfile update for the integration fixtures that exercise every supported bundler/packager path, so merging would not actually validate TS 7 across the matrix this repo depends on.
Findings
- [Blocking] typescript-eslint peer conflict — Root
package.jsonpairstypescript@7.0.2withtypescript-eslint@8.64.0, whose peer range is<6.1.0and whose type-aware rules require the classic compiler API absent in TS 7. - [Blocking] Integration fixture lockfile drift — All seven
e2e/integration/apps/*/package.jsonfiles request 7.0.2 but theiryarn.lockfiles still resolvetypescript@5.9.3; Renovate could not regenerate them. - [Minor] Staged adoption path — Microsoft's recommended TS 7 transition keeps TS 6 for tooling (ESLint, declaration emit) and runs the native compiler side-by-side; consider that pattern or defer until
typescript-eslintsupports TS 7.
Sent by Cursor Automation: electron-sdk reviews
| "rollup-plugin-dts": "6.4.1", | ||
| "tslib": "2.8.1", | ||
| "typescript": "5.9.3", | ||
| "typescript": "7.0.2", |
There was a problem hiding this comment.
Blocking — typescript-eslint is incompatible with TypeScript 7.
typescript-eslint@8.64.0 (still on this line in the same hunk) declares peerDependencies.typescript: ">=4.8.4 <6.1.0". TypeScript 7 is a native Go compiler that no longer exposes the classic programmatic API (ts.Extension, ts.ModuleKind, etc.) that @typescript-eslint/typescript-estree loads at module init time.
Installing or linting with both packages resolved to TS 7 typically fails — either a peer-resolution error or a runtime crash in typescript-estree (see typescript-eslint#12518).
Suggested fix: Follow the TypeScript 7 side-by-side guidance: keep typescript on 6.x for ESLint/tooling peers, add a separate alias (e.g. typescript-7 or @typescript/native-preview) for the native compiler, and point build/typecheck scripts at the TS 7 binary explicitly. Alternatively, close/defer this PR until typescript-eslint widens its peer range.
| "electron-builder": "26.15.3", | ||
| "electron-vite": "5.0.0", | ||
| "typescript": "5.9.3" | ||
| "typescript": "7.0.2" |
There was a problem hiding this comment.
Blocking — package.json / yarn.lock mismatch across all integration fixtures.
This file now requests "typescript": "7.0.2", but e2e/integration/apps/electron-vite/yarn.lock (and the other six integration app lockfiles) still resolve typescript@npm:5.9.3. The same drift exists in electron-builder-vite, electron-vite-esm, forge-esbuild-cjs, forge-esbuild-esm, forge-vite, and forge-webpack.
Renovate's artifact-update comment on this PR documents the failed lockfile regeneration (missing integration-sdk.tgz in its sandbox). A yarn install in each fixture directory after building the SDK tarball should regenerate the locks so CI actually exercises TS 7 in the bundler/packager matrix described in docs/REVIEW.md.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d436c3905f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| "rollup-plugin-dts": "6.4.1", | ||
| "tslib": "2.8.1", | ||
| "typescript": "5.9.3", | ||
| "typescript": "7.0.2", |
There was a problem hiding this comment.
Keep TypeScript within supported peer ranges
In the root project, this bump installs TypeScript 7 while the existing build/lint tooling still declares narrower peer support: rollup-plugin-dts@6.4.1 only accepts ^4.5 || ^5.0 || ^6.0, and typescript-eslint@8.64.0 accepts >=4.8.4 <6.1.0 in the committed yarn.lock. Because yarn build uses rollup-plugin-dts for declaration bundling and yarn lint uses typescript-eslint, this leaves the main CI toolchain in an unsupported peer state; update those tools to versions that support TypeScript 7 or keep TypeScript on a supported major.
Useful? React with 👍 / 👎.
| "electron": "41.1.0", | ||
| "electron-builder": "26.15.3", | ||
| "typescript": "5.9.3", | ||
| "typescript": "7.0.2", |
There was a problem hiding this comment.
Regenerate integration app lockfiles
This manifest bump was applied to the integration apps, but I checked e2e/integration/apps/*/yarn.lock and each committed lockfile still records the app workspace dependency as typescript: "npm:5.9.3" with a typescript@npm:5.9.3 resolution. When an integration app is installed with lockfile validation, the manifest and lockfile now disagree, and the committed locks do not reproducibly test the requested TypeScript 7 setup; regenerate and commit the lockfiles for all changed integration app manifests.
Useful? React with 👍 / 👎.
| "style-loader": "4.0.0", | ||
| "ts-loader": "9.6.2", | ||
| "typescript": "5.9.3", | ||
| "typescript": "7.0.2", |
There was a problem hiding this comment.
Keep forge-webpack on a compiler-API TypeScript
For the forge-webpack integration app, this TypeScript 7 bump is incompatible with the webpack pipeline I checked: both webpack configs feed .ts files through ts-loader in transpileOnly mode, which relies on TypeScript's transpileModule compiler API, while TypeScript 7.0 does not ship the JavaScript compiler API. Once this app is installed with the bumped manifest, electron-forge package/dev for this fixture cannot transpile through ts-loader; keep this app on TypeScript 6 or switch it to a loader/transpiler that supports TypeScript 7.
Useful? React with 👍 / 👎.
d436c39 to
8cc43a0
Compare
8cc43a0 to
762cce3
Compare


This PR contains the following updates:
5.9.3→7.0.2Release Notes
microsoft/TypeScript (typescript)
v7.0.2Compare Source
v6.0.3: TypeScript 6.0.3Compare Source
For release notes, check out the release announcement blog post.
Downloads are available on:
v6.0.2: TypeScript 6.0Compare Source
For release notes, check out the release announcement blog post.
Downloads are available on:
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.