Repository navigation
Conversation
TypeScript 6 reports it as an error, which is what an editor shows today:
jsconfig.json(3,5): Option 'baseUrl' is deprecated and will stop
functioning in TypeScript 7.0. Specify compilerOption
'"ignoreDeprecations": "6.0"' to silence this error.
In both configs baseUrl only anchors `paths`, and every path is already
written relatively ("./src/*", "./open-sse", "./open-sse/*", "./*"), so
deleting the line is the whole change.
Unlike a type-only project this one is load-bearing: Next reads these
files to resolve modules. It is still safe, and the fallback is exact.
next/dist/build/load-jsconfig.js:
if (jsConfig?.compilerOptions?.baseUrl) { ...explicit... }
else if (implicitBaseurl) { baseUrl: implicitBaseurl, isImplicit: true }
where implicitBaseurl is dirname(jsconfig.json) — the repo root for the
main app and gitbook/ for the docs app, which is what "." resolved to.
JsConfigPathsPlugin is installed either way, so `paths` keep working.
The one behaviour that does change is in webpack-config.js:
// Only add the baseUrl if it's explicitly set in tsconfig/jsconfig
if (resolvedBaseUrl && !resolvedBaseUrl.isImplicit)
webpackConfig.resolve.modules.push(resolvedBaseUrl.baseUrl)
so bare specifiers no longer resolve against the project root. Nothing
uses that. Scanning 1132 files in the main app and 14 in gitbook for
non-relative imports that are neither covered by `paths` nor present in
node_modules leaves only optional npm packages (figlet, gradient-string,
chalk-animation, got-scraping, lowdb) and bun:sqlite — no local module.
Verified by building, not by reading:
main app `next build` -> Compiled successfully in 28.0s, 137 static
pages, 0 resolution errors
gitbook `next build` -> Compiled successfully in 7.7s
gitbook's build then fails while prerendering, identically with and
without this change: components/LanguageSwitcher.js calls useEffect at
line 27 but imports only useState and useLayoutEffect. That is
pre-existing on master and left alone here.
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, which is what an editor shows today:
Both
jsconfig.jsonandgitbook/jsconfig.jsonare affected. In each,baseUrlonly anchorspaths, and every path is already written relatively ("./src/*","./open-sse","./open-sse/*","./*"), so deleting the line is the whole change — one line per file.I picked this over
"ignoreDeprecations": "6.0", which buys one major version and then has to be revisited.Why this is safe, when it is not merely a type-level setting
Next reads these files to resolve modules, so this one is load-bearing. The fallback is exact —
next/dist/build/load-jsconfig.js:implicitBaseurlisdirname(jsconfig.json)— the repo root for the main app,gitbook/for the docs app. That is precisely what"."resolved to.JsConfigPathsPluginis installed either way, sopathskeep working.One behaviour genuinely changes, in
webpack-config.js:so bare specifiers no longer resolve against the project root. Nothing here uses that. I scanned every import in 1132 files (main app) and 14 (gitbook) for non-relative specifiers that are neither matched by
pathsnor present innode_modules. What remains is only optional npm packages —figlet,gradient-string,chalk-animation,got-scraping,lowdb— plusbun:sqlite. No local module.Verification — by building, not by reading
next build→ ✓ Compiled successfully in 28.0s, 137 static pages, 0 resolution errorsnext build→ ✓ Compiled successfully in 7.7sOne thing you may want to know about, unrelated to this PR
gitbook's build compiles but then fails while prerendering:components/LanguageSwitcher.jscallsuseEffectat line 27 but imports onlyuseState, useLayoutEffect. It looks like a call site missed when fix(eslint): resolve setState-in-effect errors… converted the others.I confirmed it is pre-existing by building
gitbookonmasterwithout this change and getting the identical error, and thegitbook-pagesworkflow has been failing onmastersince that commit. It is out of scope here, so I left it alone — happy to send the one-line fix separately if useful.