Repository navigation
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. The repo pins typescript 5.9.2, so `npm run 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. Removing it means `"src/*"` has to be written `"./src/*"`, which is the only other change. 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 in src/. Both vite.config.ts and vitest.config.ts declare the `@` alias themselves with path.resolve(__dirname, "./src"), so build and tests never read this setting at all; the change is type-level only. Verified: `tsc --noEmit` reports 0 errors before and after, with `@/` imports in 250 files under src/ still resolving. Re-checked under TypeScript 6.0.3: the deprecation is gone and no new diagnostic replaces it.
Owner
|
@codex review |
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. |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
farion1231
reviewed
Oct 22, 2026
farion1231
left a comment
Owner
There was a problem hiding this comment.
LGTM, thanks for your contribution!
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TypeScript 6 reports this as an error:
The repo pins
[email protected], sonpm run typecheckis quiet today. 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. That makes"src/*"→"./src/*"the only other change."ignoreDeprecations": "6.0"would also make the message go away, 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 anywhere undersrc/, only relative ones and the@/alias.Build and tests never read this setting at all. Both
vite.config.tsandvitest.config.tsdeclare the alias themselves:so the change is type-level only.
Verification
tsc --noEmit: 0 errors before, 0 after, with@/imports in 250 files undersrc/still resolving — if the alias had broken, that would be hundreds ofCannot find moduleerrors, not silence.