chore(tsconfig): drop baseUrl so app/tsconfig survives TypeScript 7 - #6057
Conversation
TypeScript 6 reports it as an error: Option 'baseUrl' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error. app/ pins typescript 5.8.3, so the current typecheck is quiet, but an editor running a newer TypeScript flags it, and it becomes a hard failure whenever the pin moves to 7. baseUrl here only anchors `paths`, and `paths` has not needed it since TypeScript 4.4 — entries resolve relative to the tsconfig that declares them. Two of the three had to gain a "./" prefix; the third was already relative. Chose this over `"ignoreDeprecations": "6.0"`: that key silences the message for one major version and has to be revisited, while this makes the config correct. Nothing relies on baseUrl for bare-specifier resolution — there are no `from "src/..."`-style imports under app/src. vite.config.ts declares the alias itself with `"@": resolve(__dirname, "src")`, so the build never reads this setting; the change is type-level only. Verified: tsc --noEmit gives byte-identical output before and after (7 errors either way, all from packages/tauri-plugin-ptt, which resolves its own deps outside app/). No `Cannot find module '@/...'` appears, with 33 files under app/src importing through the alias. Re-checked under TypeScript 6.0.3: the deprecation is gone and nothing replaces it.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe app TypeScript configuration removes ChangesTypeScript path resolution
Estimated code review effort: 1 (Trivial) | ~2 minutes Suggested reviewers: Merge Risk: ⚪ Minimal · up to The TypeScript configuration update removes the deprecated option and keeps aliases explicitly relative, with no remaining merge-readiness risk identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
A rabbit reads each line, Comment |
|
The red
Exactly one test in that full run failed — Filed separately as #6064, with a deterministic reproduction. It is unrelated to |
|
You have reached your Codex usage limits for security reviews. Please try again later. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
TypeScript 6 reports this as an error:
app/pinstypescript@5.8.3, so the current typecheck is quiet. An editor running a newer TypeScript flags it now, and it becomes a hard failure the moment the pin moves to 7.Why removing it rather than silencing it
baseUrlhere only anchorspaths, andpathshas not needed it since TypeScript 4.4 — entries resolve relative to the tsconfig that declares them. Two of the three entries gain a./prefix;tauri-plugin-ptt-apiwas already relative."ignoreDeprecations": "6.0"would also quiet it, but it buys one major version and has to be revisited. This makes the config correct instead.Why it is safe
baseUrlhas a second effect — it lets bare specifiers resolve against the base directory — so removing it can break imports that quietly relied on that. Checked: there are nofrom "src/…"-style imports underapp/src.vite.config.tsdeclares the alias itself:so the build never reads this setting; the change is type-level only.
Verification
tsc --noEmit -p app/tsconfig.jsongives byte-identical output before and after — 7 errors either way, all frompackages/tauri-plugin-ptt/guest-js, which resolves its own dependencies outsideapp/and is unrelated to this change. NoCannot find module '@/…'appears in either run, with 33 files underapp/srcimporting through the alias — a broken alias could not have been silent.Re-checked the same config under TypeScript 6.0.3: the deprecation is gone, and no new diagnostic replaces it.
app/tsconfig.node.jsonhas nobaseUrl, so it needed no change.Summary by CodeRabbit