Upgrade docs site to Next 16 / Fumadocs 16, clear all audit findings#57
Conversation
…findings The docs site was on Next 15.5.15 with 16 known vulnerabilities (7 high), including several DoS and SSRF advisories patched in later releases and an image-cache exhaustion CVE fixed only in Next 16. - next 15.5.15 -> 16.2.9, eslint-config-next aligned - fumadocs-core/ui 15.8.5 -> 16.9.3, fumadocs-mdx 12.0.3 -> 15.0.11 - source loader updated to the new generated .source/server entry - eslint config migrated to eslint-config-next's native flat configs (FlatCompat breaks against v16), dropping the @eslint/eslintrc shim - postcss floor raised to ^8.5.15 plus overrides for the postcss copy pinned inside next and brace-expansion@5, leaving pnpm audit clean Verified: pnpm build (all 17 pages prerender), pnpm lint, tsc --noEmit, pnpm audit clean.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe PR modernizes the documentation site configuration across multiple coordinated changes: TypeScript path aliasing is updated to wildcard matching for ChangesDocumentation System Upgrade
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/package.json`:
- Around line 13-17: Update the docs and codebase to account for Next.js 16
breaking changes: review and update any middleware.ts to proxy.ts (and adjust
exports/registration), audit request handlers (e.g., any server/edge functions,
getServerSideProps-like handlers or custom Request/Response code) to ensure
async APIs are properly awaited (add missing await where Request/Response
streaming or async body parsing is used), and verify any usages of Next-specific
middleware or edge headers follow the Next 16 API surface; focus on files
referencing middleware.ts, proxy.ts, server/edge request handlers, and any
functions that call fetch/Request/Response without awaiting their async
operations.
In `@docs/tsconfig.json`:
- Line 20: The tsconfig option "jsx" is set to "react-jsx" but Next.js 16
expects "preserve"; update the compilerOptions.jsx value from "react-jsx" to
"preserve" in docs/tsconfig.json (or instead switch to using a separate
IDE/type-checking tsconfig and reference it via typescript.tsconfigPath) so
Next's compiler handling remains intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6ad5cb7b-73b4-4c29-b123-d67296774163
⛔ Files ignored due to path filters (1)
docs/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
docs/eslint.config.mjsdocs/package.jsondocs/postcss.config.mjsdocs/src/lib/source.tsdocs/tsconfig.json
| "fumadocs-core": "16.9.3", | ||
| "fumadocs-mdx": "15.0.11", | ||
| "fumadocs-ui": "16.9.3", | ||
| "lucide-react": "^0.544.0", | ||
| "next": "15.5.15", | ||
| "next": "16.2.9", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify Next.js 16 + React 19 + Fumadocs 16 compatibility
# Check Next.js 16.2.9 peer dependencies
echo "=== Next.js 16.2.9 peer dependencies ==="
npm view next@16.2.9 peerDependencies
# Check Fumadocs 16.9.3 peer dependencies
echo "=== Fumadocs core 16.9.3 peer dependencies ==="
npm view fumadocs-core@16.9.3 peerDependencies
echo "=== Fumadocs UI 16.9.3 peer dependencies ==="
npm view fumadocs-ui@16.9.3 peerDependencies
echo "=== Fumadocs MDX 15.0.11 peer dependencies ==="
npm view fumadocs-mdx@15.0.11 peerDependencies
# Check for any reported compatibility issues
echo "=== Searching npm for Next 16 + React 19 compatibility notes ==="
npm view next@16.2.9 | grep -i reactRepository: StrobeLabs/eth.zig
Length of output: 1505
🌐 Web query:
Next.js 16 release notes and breaking changes from Next.js 15
💡 Result:
Next.js 16, released on October 22, 2025 [1][2], introduces significant architectural changes and breaking updates compared to Next.js 15. The latest stable version as of June 10, 2026, is 16.2.7 [3][4]. Key Breaking Changes and Updates: Async Request APIs: Next.js 16 fully removes the temporary synchronous compatibility for request APIs introduced in version 15 [5][6]. Developers must now await the following APIs, which are provided as promises: cookies, headers, draftMode, and parameters (params, searchParams) in layouts, pages, and route handlers [7][8][6]. Metadata image routes (e.g., opengraph-image) and sitemap functions also receive params or id as promises [5][7][6]. Architecture and Bundling: Turbopack is now the default bundler for both development and production, replacing Webpack [9]. While an escape hatch exists for migration via --webpack flags, the long-term goal is a full transition to Turbopack [9]. Routing and Middleware: The middleware.ts file is deprecated and renamed to proxy.ts to better reflect its function at the network boundary [5][8][9]. Caching Model: The framework has evolved its caching strategy, replacing previous experimental flags (like experimental.ppr, dynamicIO, and useCache) with a consolidated Cache Components programming model [8][9]. Configuration and Removals: - Runtime configuration (publicRuntimeConfig, serverRuntimeConfig) is removed; developers should use standard.env environment variables [8]. - Several next/image defaults were changed, including minimumCacheTTL (default bumped from 1 min to 4 hours) and imageSizes [1][7]. - Maximum redirects for images are now capped at 3 by default [8]. - The next/legacy/image component and images.domains configuration are deprecated [5][8]. - ESLint flat config is now the default [1][7]. - Automatic scroll-behavior: smooth is enabled by default; users can opt out via data attributes [8]. For a full migration, consult the official Next.js 16 Upgrade Guide [7], which provides specific codemods and manual steps for handling these structural shifts.
Citations:
- 1: https://github.com/vercel/next.js/releases/tag/v16.0.0
- 2: https://eosl.date/eol/product/nextjs/
- 3: https://github.com/vercel/next.js/releases/tag/v16.2.7
- 4: https://www.npmjs.com/package/next
- 5: https://rc.nextjs.org/docs/app/guides/upgrading/version-16
- 6: https://github.com/vercel/next.js/blob/v16.2.1/docs/01-app/02-guides/upgrading/version-16.mdx
- 7: https://nextjs.org/docs/app/guides/upgrading/version-16
- 8: https://nextjs.org/blog/next-16
- 9: https://dev.to/pockit_tools/nextjs-16-migration-guide-turbopack-proxy-cache-components-and-every-breaking-change-explained-35ci
docs/package.json: peer-deps are compatible with Next.js 16 + React 19 + Fumadocs 16, but Next 16 migrations still need review
Peer dependency ranges match:
next@16.2.9supportsreact/react-dom^19.0.0fumadocs-core@16.9.3/fumadocs-ui@16.9.3requirenext: 16.x.xandreact/react-dom: ^19.2.0fumadocs-mdx@15.0.11supportsnext: ^15.3.0 || ^16.0.0andreact: ^19.2.0(andfumadocs-core: ^16.7.0)
Still ensure the codebase handles Next.js 16 breaking changes (e.g., async request APIs needing await, and middleware.ts → proxy.ts), since that’s the likely remaining source of breakage beyond peer dependency compatibility.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/package.json` around lines 13 - 17, Update the docs and codebase to
account for Next.js 16 breaking changes: review and update any middleware.ts to
proxy.ts (and adjust exports/registration), audit request handlers (e.g., any
server/edge functions, getServerSideProps-like handlers or custom
Request/Response code) to ensure async APIs are properly awaited (add missing
await where Request/Response streaming or async body parsing is used), and
verify any usages of Next-specific middleware or edge headers follow the Next 16
API surface; focus on files referencing middleware.ts, proxy.ts, server/edge
request handlers, and any functions that call fetch/Request/Response without
awaiting their async operations.
| "resolveJsonModule": true, | ||
| "isolatedModules": true, | ||
| "jsx": "preserve", | ||
| "jsx": "react-jsx", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for Next.js 16 JSX transform documentation or examples in the codebase
rg -n -C3 --type=json '"jsx"' --glob '!node_modules' --glob '!.next'Repository: StrobeLabs/eth.zig
Length of output: 398
🌐 Web query:
What JSX compiler option should be used in tsconfig.json for Next.js 16 with React 19?
💡 Result:
For a Next.js 16 project, the recommended jsx compiler option in tsconfig.json is "preserve" [1][2][3]. While you may see recommendations to use "react-jsx" to enable the automatic runtime for type-checking purposes [4][5], Next.js is designed to manage the JSX transformation itself using its own optimized compiler (SWC) [1][2][3]. When you run next dev or next build, Next.js will automatically detect and, if necessary, reset the jsx option in your tsconfig.json to "preserve" to ensure it maintains control over the JSX transformation process [1][2]. If you are experiencing type-checking errors in your editor (such as warnings about missing React imports when using JSX), these are typically issues with IDE configuration or TypeScript versioning rather than a requirement to change the jsx setting [1][5]. To resolve such issues, ensure your TypeScript version is up to date and that your project dependencies, particularly @types/react and @types/react-dom, are correctly aligned with the version of React (React 19) you are using [6]. Next.js automatically configures the environment to handle JSX correctly, and manually overriding the jsx option is generally discouraged as it may be overwritten by the framework [1][2].
Citations:
- 1: https://stackoverflow.com/questions/79046311/next-js-automatically-resets-tsconfig-json-jsx-option-causing-react-import-wa
- 2: fix(turbopack/transform_options): enforce default react runtime vercel/next.js#48400
- 3: Next.js sets invalid and irrelevant tsconfig options. vercel/next.js#45617
- 4: codewithdhruba01/GamaAI@e5c7fb3
- 5: Use the automatic runtime for type checking vercel/next.js#83159
- 6: https://rc.nextjs.org/docs/app/guides/upgrading/version-16
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the relevant tsconfig section around the jsx option
sed -n '1,120p' docs/tsconfig.json | cat -n
# Find any other tsconfig files that might be used by Next.js (root or app/package dirs)
find . -maxdepth 4 -name 'tsconfig*.json' -print
# Check if docs/tsconfig.json is referenced anywhere
rg -n --glob '!node_modules/**' -S 'docs/tsconfig\.json|extends\s*:\s*.*tsconfig\.json' .Repository: StrobeLabs/eth.zig
Length of output: 1227
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) List all tsconfig files in the repo (small enough)
find . -name 'tsconfig*.json' -print
# 2) Check if any tsconfig extends docs/tsconfig.json (or references it)
rg -n --glob '!node_modules/**' --glob '!**/.next/**' -S \
'extends\s*:\s*["\047].*tsconfig.*["\047]|docs/tsconfig\.json|tsconfig\.json' .
# 3) Check common entrypoints for tsconfig usage
rg -n --glob '!node_modules/**' --glob '!**/.next/**' -S \
'"tsconfig"' package.json next.config.* **/*.{js,ts,mjs,cjs} . || trueRepository: StrobeLabs/eth.zig
Length of output: 360
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) List all tsconfig files
find . -name 'tsconfig*.json' -print
# 2) Direct references to docs/tsconfig.json
rg -n --glob '!node_modules/**' --glob '!**/.next/**' -S 'docs/tsconfig\.json' . || true
# 3) Look for Next.js TypeScript config path overrides
rg -n --glob '!node_modules/**' --glob '!**/.next/**' -S 'tsconfigPath' . || true
# 4) Show any Next config files
find . -maxdepth 4 \( -name 'next.config.*' -o -name '*next*.config.*' \) -printRepository: StrobeLabs/eth.zig
Length of output: 106
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show next config (first ~200 lines)
sed -n '1,220p' docs/next.config.mjs | cat -n
# Search for tsconfig references in repo (excluding node_modules/.next)
rg -n --glob '!node_modules/**' --glob '!**/.next/**' -S 'tsconfig\.json|tsconfigPath|jsx\s*:' .
# Search for Next's "typescript" config block
rg -n --glob '!node_modules/**' --glob '!**/.next/**' -S 'typescript\s*:' docs/next.config.mjs . || trueRepository: StrobeLabs/eth.zig
Length of output: 2992
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# List package.json files
find . -name 'package.json' -print
# If docs/package.json exists, show Next/React versions
if [ -f docs/package.json ]; then
echo "---- docs/package.json ----"
sed -n '1,220p' docs/package.json | cat -n
fi
# Look for Next version in lockfile too (ts search avoids huge output)
rg -n 'next@|next":' docs/pnpm-lock.yaml | head -n 50 || true
# Search for any other tsconfig.json in Next app roots (in case of monorepo)
find . -maxdepth 4 -name 'tsconfig.json' -printRepository: StrobeLabs/eth.zig
Length of output: 5079
🌐 Web query:
Next.js 16 tsconfig compilerOptions jsx preserve react-jsx automatic runtime SWC resets tsconfig jsx option
💡 Result:
In Next.js, the compilerOptions.jsx setting in tsconfig.json dictates how the TypeScript compiler handles JSX during type checking, while Next.js itself uses its own optimized SWC (Speedy Web Compiler) pipeline to transform JSX for the browser [1][2][3]. As of Next.js 16, the recommended and default jsx configuration in tsconfig.json is react-jsx [4]. This setting enables the React automatic runtime for type checking, which is required to correctly validate JSX without needing to manually import React in every file [5][4]. Regarding the behavior of Next.js automatically "resetting" or "overwriting" your tsconfig.json: 1. Historical Context: In older versions of Next.js, the framework would often automatically enforce "jsx": "preserve" in your tsconfig.json [6][2]. This was because Next.js managed the transformation internally via SWC/Babel, and setting the tsconfig to preserve prevented the TypeScript compiler from attempting its own JSX transformation, which could conflict with the build pipeline [2]. 2. Current Behavior: With the shift toward modern standards and improved integration, recent versions (including Next.js 16) now prefer and may enforce react-jsx [4]. When Next.js detects TypeScript in your project, it may automatically modify your tsconfig.json to ensure mandatory options—such as jsx, moduleResolution, and isolatedModules—are set to values compatible with the Next.js architecture [4][6][7]. If you find your tsconfig.json being repeatedly reverted, it is typically because Next.js has identified a configuration mismatch that prevents it from guaranteeing a successful build [6]. If you need a specific configuration for other tools (like Jest or custom scripts) that conflicts with Next.js's requirements, the recommended approach is to maintain a base tsconfig.json that Next.js manages, and use a separate, extended tsconfig file for those specific tools, or rely on tool-specific configuration files (e.g., jest.config.js) to handle the necessary overrides [2][8].
Citations:
- 1: https://github.com/vercel/next.js/blob/v14.2.3/packages/next/src/build/swc/options.ts
- 2: jsx was set to preserve (next.js implements its own optimized jsx transform) vercel/next.js#19155
- 3: https://github.com/vercel/next.js/blob/0c3aa188e6dfa37eaa8510e9d6b5fb2e5c93c4a7/packages/next/src/build/swc/options.ts
- 4: vercel/next.js@7aa5d16
- 5: Use the automatic runtime for type checking vercel/next.js#83159
- 6: https://stackoverflow.com/questions/79046311/next-js-automatically-resets-tsconfig-json-jsx-option-causing-react-import-wa
- 7: vercel/next.js@aa3ba7e
- 8: https://nextjs.org/docs/pages/api-reference/config/typescript
🌐 Web query:
Next.js 16 tsconfig compilerOptions jsx preserve react-jsx what does Next enforce
💡 Result:
In Next.js 16, the standard tsconfig.json template typically specifies "jsx": "preserve" [1]. Next.js manages the transformation of JSX internally using its own optimized build process, which enables the automatic JSX runtime [2][3]. The key distinction regarding jsx options in tsconfig.json is between how TypeScript handles type checking and how Next.js handles code transformation [4]: 1. Next.js Requirement: Next.js prefers "jsx": "preserve" in your tsconfig.json because it wants to retain the JSX syntax so that its own internal compiler (or Turbopack) can handle the transformation [2][3]. If you explicitly change this to "react-jsx" to satisfy IDE warnings, Next.js may overwrite or warn you about this setting because it implements its own optimized transform [2][3]. 2. TypeScript Runtime: Despite the "preserve" setting, Next.js uses the automatic JSX runtime for the final output [4][3]. 3. IDE/Type Checking: Some TypeScript versions or IDE configurations may trigger errors suggesting you use "react-jsx" (e.g., complaining about the need for an explicit import React for fragments) [2]. While setting "jsx": "react-jsx" in tsconfig.json solves these type-checking issues, it conflicts with the Next.js recommended configuration [2][4]. In summary, Next.js generally enforces or recommends "jsx": "preserve" to ensure the build pipeline controls the JSX transformation [2][3]. If you encounter IDE errors while using "preserve", ensure your TypeScript environment and dependencies are up to date, as modern Next.js environments are designed to handle the automatic runtime during the build phase regardless of the "preserve" setting [4][3].
Citations:
- 1: https://vercel-next-js.mintlify.app/api-reference/config/typescript
- 2: https://stackoverflow.com/questions/79046311/next-js-automatically-resets-tsconfig-json-jsx-option-causing-react-import-wa
- 3: fix(turbopack/transform_options): enforce default react runtime vercel/next.js#48400
- 4: Use the automatic runtime for type checking vercel/next.js#83159
🌐 Web query:
next 16.2.9 automatically resets tsconfig jsx option preserve
💡 Result:
Next.js intentionally and automatically sets the jsx option in your tsconfig.json to "preserve" [1][2]. This is not a bug unique to version 16.2.9, but rather a long-standing behavior where Next.js enforces its own optimized JSX transform [1][3][4]. When you run Next.js (e.g., via next dev or next build), the framework checks your tsconfig.json and updates mandatory fields to ensure they align with Next.js requirements [1][2]. If it detects that jsx is set to anything other than "preserve", it will overwrite it and display a message in your terminal noting the change [1][5]. If you are experiencing editor warnings (such as issues with React auto-imports or TypeScript validation) because of this setting, it is generally recommended to address the issue within your development environment rather than by modifying the tsconfig.json file, as Next.js will continue to reset it [1][3]. Common approaches for managing this behavior include: 1. Ensure your IDE (e.g., VS Code) is using the workspace version of TypeScript rather than a globally installed or "nightly" version that may conflict with the project's configuration [1][3]. 2. For testing frameworks like Jest, you can override the configuration specifically for the test environment (e.g., in your jest.config.js) rather than changing the base tsconfig.json [6][7]. 3. Verify that your project dependencies, particularly @types/react and @types/react-dom, are up to date, as newer versions of TypeScript often handle the "preserve" setting correctly for editor features [8][3].
Citations:
- 1: https://stackoverflow.com/questions/79046311/next-js-automatically-resets-tsconfig-json-jsx-option-causing-react-import-wa
- 2: Change default typescript moduleResolution to bundler to match nextjs heuristics of using webpack/turbopack vercel/next.js#75805
- 3: VS Code auto-import of React Components broken in VS Code (Next.JS + React 17 JSX + TypeScript incompatibility) vercel/next.js#27212
- 4: Next.js sets invalid and irrelevant tsconfig options. vercel/next.js#45617
- 5: fix(turbopack/transform_options): enforce default react runtime vercel/next.js#48400
- 6: Testing with typescript + jest + ts-jest vercel/next.js#8663
- 7: Next.js tsconfig.json conflicts /
tsconfigincorrectly camel-cased on docs website kulshekhar/ts-jest#2805 - 8: https://github.com/vercel/next.js/blob/v16.2.1/docs/01-app/02-guides/upgrading/version-16.mdx
🌐 Web query:
next.config typescript tsconfig jsx react-jsx preserve next 16
💡 Result:
In Next.js, the jsx compiler option in tsconfig.json is automatically managed by the framework [1][2]. While historically defaulted to preserve [1], recent updates to Next.js (including the transition toward react-jsx in newer versions) reflect the framework's optimized JSX transformation process [3][4]. Next.js automatically enforces its required TypeScript configuration to ensure compatibility with its internal build pipeline [1][2]. If you attempt to manually change the jsx option in your tsconfig.json, Next.js will typically detect the change and revert it to the framework's preferred setting upon running next dev or next build [1][2]. Key points regarding this behavior: 1. Automatic Management: Next.js treats tsconfig.json as a managed file [1][2]. When you start the development server or run a build, Next.js checks your configuration and updates mandatory fields—such as jsx—to ensure they align with how Next.js compiles your code [1][2]. 2. Evolution of the jsx Setting: The framework has moved toward the react-jsx setting to utilize the automatic JSX runtime [3][4]. This runtime does not require you to manually import React in every file that uses JSX [4], aligning with modern React standards. 3. Custom Configurations: If you need to use a different TypeScript configuration for specific tasks, you can use the typescript.tsconfigPath option in your next.config.ts (or next.config.js) file to point to a custom tsconfig file [5][6][7]. This allows you to maintain a separate configuration for specialized build processes or tooling without conflicting with the main Next.js managed tsconfig.json [8][9]. 4. IDE Warnings: If you encounter IDE warnings (e.g., in VS Code) suggesting you import React despite using a fragment, it is often due to a mismatch between your local TypeScript version or editor settings and the Next.js managed configuration [1]. Ensure your IDE is using the project's workspace version of TypeScript rather than a global or nightly version [1]. If you are upgrading to Next.js 16, ensure your project meets the minimum requirement of TypeScript 5.1.0 or higher [10]. Always allow Next.js to manage your primary tsconfig.json to prevent build-time incompatibilities [1][2].
Citations:
- 1: https://stackoverflow.com/questions/79046311/next-js-automatically-resets-tsconfig-json-jsx-option-causing-react-import-wa
- 2: jsx was set to preserve (next.js implements its own optimized jsx transform) vercel/next.js#19155
- 3: vercel/next.js@7aa5d16
- 4: Use the automatic runtime for type checking vercel/next.js#83159
- 5: https://nextjs.org/docs/15/app/api-reference/config/typescript
- 6: https://nextjs.org/docs/app/api-reference/config/typescript
- 7: https://vercel-next-js.mintlify.app/api-reference/config/typescript
- 8: https://nextjs.org/docs/pages/api-reference/config/typescript
- 9: https://nextjs.im/docs/app/api-reference/config/typescript/
- 10: https://rc.nextjs.org/docs/app/guides/upgrading/version-16
Align docs/tsconfig.json JSX option with Next.js 16 (jsx: "preserve")
docs/tsconfig.json sets compilerOptions.jsx to "react-jsx", but Next.js 16 expects "preserve" since it manages JSX via its own compiler (and may overwrite this setting). Switch jsx back to "preserve" or use a separate tsconfig for IDE/type-checking needs (via typescript.tsconfigPath) instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/tsconfig.json` at line 20, The tsconfig option "jsx" is set to
"react-jsx" but Next.js 16 expects "preserve"; update the compilerOptions.jsx
value from "react-jsx" to "preserve" in docs/tsconfig.json (or instead switch to
using a separate IDE/type-checking tsconfig and reference it via
typescript.tsconfigPath) so Next's compiler handling remains intact.
1 participant
What
Upgrades the docs site from Next 15.5.15 / Fumadocs 15.8.5 to Next 16.2.9 / Fumadocs 16.9.3 and clears every
pnpm auditfinding (previously 16 vulnerabilities, 7 high, per the dependabot alerts on main).Why
The pinned Next 15.5.15 carried multiple high-severity advisories (DoS via Server Components, middleware bypass, SSRF in WebSocket upgrades, cache-exhaustion CVE-2026-27980 fixed only in Next 16). PostCSS sat below the 8.5.10 XSS patch. This also supersedes dependabot #52.
How
next15.5.15 → 16.2.9,eslint-config-nextaligned to 16.2.9fumadocs-core/fumadocs-ui→ 16.9.3,fumadocs-mdx→ 15.0.11 (Next 16 peer support)src/lib/source.tsnow imports the new generated.source/serverentry (fumadocs-mdx 14+ layout); tsconfig alias updatedFlatCompatthrows a circular-structure error against v16 — and the now-unused@eslint/eslintrcwas removedpostcssfloor raised to ^8.5.15, with pnpm overrides for the postcss copy bundled inside next (<8.5.10) andbrace-expansion@5(<5.0.6)Verification
pnpm build: all 17 docs pages prerender (SSG)pnpm lintandtsc --noEmit: cleanpnpm audit: No known vulnerabilities found (was 2 low / 7 moderate / 7 high)🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes