Upgrade docs to Nextra 4 and Next.js 15 #967
Conversation
|
WalkthroughThe update spans multiple configuration, documentation, and source code changes. A new linter rule was added while the Next.js configuration was restructured and dependency versions upgraded. API documentation was revised with an updated method signature for the handler and new onCreation documentation along with related types. Several markdown files had their custom Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant CH as CacheHandler
participant Hook as onCreationHook
Dev->>CH: Call onCreation(onCreationHook)
CH->>Hook: Invoke hook with CacheCreationContext
Hook-->>CH: Return CacheHandlerConfig (or Promise thereof)
CH-->>Dev: Return configured CacheHandler instance
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
⏰ Context from checks skipped due to timeout of 90000ms (2)
🔇 Additional comments (2)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
docs/cache-handler-docs/src/app/api-reference/handler/page.mdx (1)
4-7: Critical: UpdategetMethod Signature in Type Definition.There is an inconsistency between the type definition and the documented parameters. The type for the
getmethod currently does not include the additionalimplicitTagsparameter described below. This discrepancy should be resolved to prevent confusion.Suggested change:
- get: (key: string) => Promise<CacheHandlerValue | null | undefined>; + get: (key: string, implicitTags: string[]) => Promise<CacheHandlerValue | null | undefined>;
🧹 Nitpick comments (4)
docs/cache-handler-docs/src/app/api-reference/on-creation/page.mdx (1)
44-61: Comprehensive onCreation Usage Example.The example provided shows how to configure multiple cache handlers and a TTL policy. Adding inline comments within the example might further improve clarity, but the overall demonstration is effective.
docs/cache-handler-docs/src/app/installation/page.mdx (1)
139-139: Punctuation Improvement Suggestion
A static analysis hint flagged a potential missing comma in the sentence around line 139 in the instrumentation instructions. Although the sentence "The duration of this process may vary based on the number and size of pages, routes, and fetch calls." reads well, please review the punctuation to ensure maximum clarity (a comma after "routes" might help further, if needed).🧰 Tools
🪛 LanguageTool
[uncategorized] ~139-~139: Possible missing comma found.
Context: ...ages, routes, and fetch calls. For more information refer to the [Populating the Cache with...(AI_HYDRA_LEO_MISSING_COMMA)
docs/cache-handler-docs/src/mdx-components.js (1)
5-10: Add TypeScript types and documentation for better maintainability.The component merging logic is well-implemented, but could benefit from additional clarity.
Consider adding TypeScript types and JSDoc documentation:
+/** + * Merges theme MDX components with custom components. + * Custom components take precedence over theme components. + * @param {Record<string, React.ComponentType>} components - Custom MDX components + * @returns {Record<string, React.ComponentType>} Merged MDX components + */ -export function useMDXComponents(components) { +export function useMDXComponents(components: Record<string, React.ComponentType>) { return { ...themeComponents, ...components, }; }docs/cache-handler-docs/src/app/layout.tsx (1)
16-21: Consider using a more semantic element for the logo.Using a
<pre>tag for the logo might not be the most semantic choice. Consider using a more appropriate element like<span>or creating a styled logo component.- logo={<pre>@neshca/cache-handler</pre>} + logo={<span className="font-mono">@neshca/cache-handler</span>}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
docs/cache-handler-docs/public/favicon-16x16.pngis excluded by!**/*.pngdocs/cache-handler-docs/public/favicon-32x32.pngis excluded by!**/*.pngdocs/cache-handler-docs/src/app/icon.pngis excluded by!**/*.pngpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (26)
biome.json(1 hunks)docs/cache-handler-docs/next.config.ts(1 hunks)docs/cache-handler-docs/package.json(1 hunks)docs/cache-handler-docs/src/app/_meta.ts(3 hunks)docs/cache-handler-docs/src/app/api-reference/handler/page.mdx(1 hunks)docs/cache-handler-docs/src/app/api-reference/on-creation/page.mdx(1 hunks)docs/cache-handler-docs/src/app/functions/nesh-classic-cache/page.mdx(1 hunks)docs/cache-handler-docs/src/app/handlers/experimental-redis-cluster/page.mdx(1 hunks)docs/cache-handler-docs/src/app/handlers/local-lru/page.mdx(1 hunks)docs/cache-handler-docs/src/app/handlers/redis-stack/page.mdx(1 hunks)docs/cache-handler-docs/src/app/installation/page.mdx(6 hunks)docs/cache-handler-docs/src/app/layout.tsx(1 hunks)docs/cache-handler-docs/src/app/page.mdx(2 hunks)docs/cache-handler-docs/src/app/redis/page.mdx(1 hunks)docs/cache-handler-docs/src/app/troubleshooting/page.mdx(3 hunks)docs/cache-handler-docs/src/app/usage/_meta.ts(1 hunks)docs/cache-handler-docs/src/app/usage/build-id-as-prefix-key/page.mdx(2 hunks)docs/cache-handler-docs/src/app/usage/creating-a-custom-handler/page.mdx(1 hunks)docs/cache-handler-docs/src/app/usage/development-environment/page.mdx(1 hunks)docs/cache-handler-docs/src/app/usage/on-demand-revalidation/page.mdx(2 hunks)docs/cache-handler-docs/src/app/usage/opt-out-cache-on-build/page.mdx(1 hunks)docs/cache-handler-docs/src/app/usage/populating-cache-on-start/page.mdx(4 hunks)docs/cache-handler-docs/src/mdx-components.js(1 hunks)docs/cache-handler-docs/src/pages/_app.tsx(0 hunks)docs/cache-handler-docs/theme.config.jsx(0 hunks)docs/cache-handler-docs/tsconfig.json(1 hunks)
💤 Files with no reviewable changes (2)
- docs/cache-handler-docs/src/pages/_app.tsx
- docs/cache-handler-docs/theme.config.jsx
✅ Files skipped from review due to trivial changes (9)
- docs/cache-handler-docs/src/app/usage/on-demand-revalidation/page.mdx
- docs/cache-handler-docs/src/app/page.mdx
- docs/cache-handler-docs/src/app/usage/development-environment/page.mdx
- docs/cache-handler-docs/src/app/usage/opt-out-cache-on-build/page.mdx
- docs/cache-handler-docs/src/app/handlers/redis-stack/page.mdx
- docs/cache-handler-docs/src/app/troubleshooting/page.mdx
- docs/cache-handler-docs/src/app/redis/page.mdx
- docs/cache-handler-docs/src/app/usage/creating-a-custom-handler/page.mdx
- docs/cache-handler-docs/src/app/usage/populating-cache-on-start/page.mdx
🧰 Additional context used
🪛 LanguageTool
docs/cache-handler-docs/src/app/installation/page.mdx
[uncategorized] ~139-~139: Possible missing comma found.
Context: ...ages, routes, and fetch calls. For more information refer to the [Populating the Cache with...
(AI_HYDRA_LEO_MISSING_COMMA)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: redis-strings
- GitHub Check: redis-stack
🔇 Additional comments (39)
docs/cache-handler-docs/src/app/usage/_meta.ts (1)
5-5: LGTM! Documentation clarity improved.The addition of a proper title for the development environment section enhances the documentation navigation structure.
docs/cache-handler-docs/package.json (4)
7-8: Enhanced Documentation Scripts.
The "build:docs" script now runs "next build" followed by a pagefind command to generate search indexing, and "dev:docs" includes the "--turbo" flag to potentially improve dev server performance. Verify that the pagefind output directory and turbo flag behavior meet your project’s workflow expectations.
14-18: Upgrade Core Dependencies.
The dependencies have been updated to Next.js 15.1.6, Nextra 4.2.4 (and its theme), and React/ReactDOM 19.0.0. These upgrades are significant and may introduce breaking changes relative to the previous versions. Please ensure that all integrations, custom configurations, and component usages have been thoroughly tested against these new versions.
24-25: Update Type Definitions.
The devDependencies now include updated type definitions for react and react-dom (@types/react to 19.0.8 and @types/react-dom to 19.0.3) which should align well with React 19.0.0. Confirm that the project builds without type errors post-upgrade.
27-27: Addition of Pagefind Dependency.
The new dependency "pagefind" at version 1.3.0 has been added to support the search indexing feature in the build process. Make sure that its integration with the build script is functioning as intended.biome.json (1)
24-25: Updated Linter Style Configuration.
The linter settings now disable the "useNamingConvention" rule and add the "noImplicitBoolean" rule set to "off". This change relaxes code style constraints in these areas; ensure that this aligns with your team's coding standards and that any rationale is documented elsewhere if needed.docs/cache-handler-docs/next.config.ts (2)
1-1: LGTM! Well-structured Next.js configuration.The configuration is properly typed and includes essential settings for static export, base path, image optimization, and environment variables.
Also applies to: 6-13
15-17: Verify Nextra 4 default configuration.The empty configuration object suggests reliance on Nextra 4 defaults. Please ensure this meets your documentation requirements.
✅ Verification successful
🌐 Web query:
What are the default configuration options in Nextra 4?💡 Result:
Nextra 4 provides several default configuration options across its core functionality and theme implementations. Here are the key default settings: ## Static Exports - Default output directory: `out` in project root [2] - Image optimization disabled by default (`images.unoptimized: true`) for static exports [2] ## Syntax Highlighting - Copy code button disabled by default (`defaultShowCopyCode: false`) [3] - Default themes: - Dark mode: `nord` - Light mode: `min-light` [3] ## Sidebar Configuration - Default menu collapse level: `2` (collapses second-level folders) [6] - Auto-collapse enabled by default for inactive routes (`autoCollapse: true`) [6] ## Theme Defaults ### Docs Theme - Default layout includes: - Responsive navbar with logo placement - Footer with MIT license notice - SEO-optimized HTML structure [10] - Default docs repository base URL points to GitHub repository template [10] ### Blog Theme - Default color schemes: - Dark background: `#0f172a` - Light background: `#fefce8` [7] - Includes RSS feed generation by default [7] ## Core Configuration - Markdown/MDX handling enabled by default with: - Automatic page map generation - Built-in components (Head, Banner, ThemeSwitch) [7][10] - Default metadata includes title from layout configuration [7][10] To override these defaults, modify your `next.config.mjs` file: ```javascript import nextra from 'nextra' const withNextra = nextra({ theme: 'nextra-theme-docs', themeConfig: './theme.config.jsx', mdxOptions: { rehypePrettyCodeOptions: { theme: { dark: 'github-dark', light: 'github-light' } } } }) export default withNextra({ // Next.js config overrides }) ``` These defaults provide sensible starting points while maintaining flexibility through configuration overrides. The system uses localStorage for persistent settings where applicable, falling back to defaults when no custom configuration exists[1][6]. Citations: - 1: https://rakis-docs.vercel.app/core-code-and-interfaces/detailed-analysis/settings-and-configuration - 2: https://nextra.site/docs/guide/static-exports - 3: https://nextra.site/docs/guide/syntax-highlighting - 4: https://docs.madoc.io/developers/extensions/project-templates - 5: https://github.com/shuding/nextra/issues/3970 - 6: https://www.nft2npc.com/docs/docs-theme/theme-configuration - 7: https://nextra.site/docs/blog-theme/start - 8: https://github.com/shuding/nextra/issues/250 - 9: https://github.com/shuding/nextra/issues/3990 - 10: https://nextra.site/docs/docs-theme/start
Nextra 4 Defaults Verified
The empty configuration object is indeed relying on Nextra 4’s built-in defaults. The defaults include settings for static exports (e.g., output directory set to "out", image optimization disabled), syntax highlighting (default themes and copy code behavior), sidebar configuration, theme defaults for both docs and blog, as well as core Markdown/MDX handling features. If these default behaviors align with your documentation and project requirements, then continuing to use an empty configuration object is appropriate.docs/cache-handler-docs/src/app/_meta.ts (3)
1-3: LGTM! Improved type safety with MetaRecord.Good use of the Nextra MetaRecord type for better type checking of the navigation structure.
17-17: LGTM! Cleaner title formatting.Good cleanup of titles by removing redundant "↗" symbols and ensuring consistent naming.
Also applies to: 21-21, 35-35, 41-41, 45-45
49-50: LGTM! Clean export style.Good practice using a named constant with explicit export.
docs/cache-handler-docs/tsconfig.json (1)
18-18: LGTM! Proper TypeScript configuration.Good addition of next.config.ts to ensure type checking of the Next.js configuration file.
docs/cache-handler-docs/src/app/handlers/local-lru/page.mdx (1)
16-18: LGTM! Clear warning using standard markdown.Good use of standard markdown note syntax and clear warning about production usage limitations.
docs/cache-handler-docs/src/app/usage/build-id-as-prefix-key/page.mdx (2)
1-3: Clear and Concise Introduction.The header and introductory text clearly set the context for using a build ID as a key prefix. No issues found.
41-43: Consistent Documentation Note Format.Replacing the previous component with the Markdown note block (
> [!NOTE]) is implemented cleanly and aligns with the new documentation style.docs/cache-handler-docs/src/app/api-reference/on-creation/page.mdx (2)
1-2: Clear and Focused Header.The header “onCreation” immediately informs the reader about the documented functionality.
9-13: Accurate Type Definition for OnCreationHook.The TypeScript snippet clearly defines the
OnCreationHooktype with the expected parameters and return type, making it easy for developers to understand the function’s contract.docs/cache-handler-docs/src/app/handlers/experimental-redis-cluster/page.mdx (2)
3-19: Comprehensive Code Snippet.The JavaScript snippet demonstrates how to instantiate and configure the experimental Redis cluster handler with all necessary parameters (e.g., keyPrefix, timeoutMs). The example is clear and informative.
21-23: Warning Block Format Updated.The switch to a Markdown warning block (
> [!WARNING]) effectively communicates the experimental nature of this handler. This change is consistent with the updated documentation style.docs/cache-handler-docs/src/app/functions/nesh-classic-cache/page.mdx (2)
7-9: Consistent Note Block Update.Replacing the former Callout component with a Markdown note block (
> [!NOTE]) maintains consistency across documentation files while clearly emphasizing important usage details.
37-80: Detailed Example Provided.The example usage of
neshClassicCachethoroughly illustrates its integration within an API route, including error handling and response processing. The example is clear and useful.docs/cache-handler-docs/src/app/api-reference/handler/page.mdx (2)
19-29: Detailed Parameter Explanation forgetMethod.The extended description of the
getmethod parameters—including the newimplicitTagsarray—is thorough and helps clarify its purpose. Once the type definition is updated, the documentation will be fully consistent.
70-72: Informative Note on Tag Storage.The note explaining that remote cache stores may require separate indexing for tags is a valuable addition. It provides important context for performance considerations.
docs/cache-handler-docs/src/app/installation/page.mdx (9)
1-1: Heading Update: Title Introduction
The main title "# Getting Started with@neshca/cache-handler" is clear and engaging. It aligns with the documentation’s intent.
5-8: Section Heading Consistency & Version Clarification
The "## Prerequisites" heading is now uniform with other major sections. However, note that the listed Next.js version requirement ("13.5.1 or newer (below 15.0.0)") seems at odds with the PR objective to upgrade documentation for Next.js 15. Please verify and update this requirement to avoid confusion.
11-12: Quick Start Installation Section
The "## Quick Start Installation" section is well delineated and provides clear code examples. Ensure that these examples have been tested in a Next.js 15 environment.
25-25: Manual Installation Section Clarity
The "## Manual installation" heading is appropriately introduced. The provided command snippets are clear; just verify that they remain valid for projects using Next.js 15.
41-48: Basic Custom Configuration Clarity
The "## Basic Custom Configuration" section and its embedded code snippet provide a good walkthrough for creating and configuring a cache handler file. Double-check that the code sample maintains compatibility with the updated Next.js and Nextra setups.
90-93: Refined Note Formatting for Import Guidance
The conversion from a custom Callout to a standard markdown note (using "> [!NOTE]") is well executed. The note clearly warns against importing@neshca/cache-handlerin client components, which is crucial for proper usage.
135-138: Instrumentation Note Clarity
The note regarding the use of theNEXT_RUNTIMEenvironment variable and dynamic import is clear and helpful. This formatting change improves consistency across the documentation.
141-141: Running Your Application Section
The "## Running Your Application" heading introduces the production build instructions effectively. The commands appear standard; ensure they have been validated under the new Next.js 15 setup.
152-152: Next Steps Section – Clear Navigation Forward
The "## Next Steps" section offers relevant pointers for further exploration of features and troubleshooting. This addition aids users in navigating the broader documentation effectively.docs/cache-handler-docs/src/mdx-components.js (2)
1-3: LGTM! Clear import and initialization.The import statement and theme components initialization are well-structured. The comment helpfully indicates theme flexibility.
1-10: 🌐 Web query:What is the recommended way to customize MDX components in Nextra 4?💡 Result:
To customize MDX components in Nextra 4, create an **`mdx-components.js`** (or .tsx) file at your project root and implement these key patterns: ### Core Customization Method 1. **Export `useMDXComponents` function** Merge default theme components with your customizations: ```jsx import { useMDXComponents as getThemeComponents } from 'nextra/mdx-components' export function useMDXComponents(components) { return { ...getThemeComponents(), h1: ({ children }) => ( <h1 style={{ fontSize: '2.5rem', color: '#1a202c' }}> {children} </h1> ), ...components } } ``` ### Common Customizations **Component overrides** Specify replacements for markdown elements using their HTML tag names: ```jsx export function useMDXComponents(components) { return { a: ({ href, children }) => ( <a href={href} className="custom-link"> {children} </a> ), code: ({ children }) => ( <code className="syntax-highlight">{children}</code> ) } } ``` **Image optimization** Wrap MDX images with Next.js Image: ```jsx import Image from 'next/image' export function useMDXComponents(components) { return { img: (props) => ( <Image {...props} alt={props.alt || ''} sizes="100vw" style={{ width: '100%', height: 'auto' }} /> ) } } ``` ### File Location Options - **Root directory**: `/mdx-components.js` - **Src directory**: `/src/mdx-components.js` - Supports `.js`, `.jsx`, and `.tsx` extensions[1][3] ### Advanced Patterns **Theme integration** When using custom themes, access theme components through composition: ```jsx import { TOC } from './custom-toc' export function useMDXComponents(components) { return { wrapper: ({ children, toc }) => ( <div className="content-wrapper"> {children} <TOC items={toc} /> </div> ) } } ``` Key considerations: - Merging strategy preserves default functionality while adding customizations[1][4] - Component overrides apply globally to all MDX content[3][7] - Works with both Pages Router and App Router configurations[8][10] For TypeScript users, leverage MDX's type definitions: ```typescript import type { MDXComponents } from 'mdx/types' export function useMDXComponents(components: MDXComponents): MDXComponents { // Type-safe customizations } ``` Citations: - 1: https://nextra.site/docs/file-conventions/mdx-components-file - 2: https://www.youtube.com/watch?v=Av5120MvQk4 - 3: https://nextjs.org/docs/pages/building-your-application/configuring/mdx - 4: https://nextra.site/docs/custom-theme - 5: https://nextra.site - 6: https://github.com/shuding/nextra/issues/3329 - 7: https://nextra.site/docs/guide/markdown - 8: https://github.com/shuding/nextra/issues/2023 - 9: https://mdxjs.com - 10: https://the-guild.dev/blog/nextra-4docs/cache-handler-docs/src/app/layout.tsx (5)
1-5: LGTM! Imports are correctly structured for Nextra 4.The imports are properly organized and include all necessary components and types for the layout implementation.
23-37: LGTM! Footer implementation follows best practices.The footer correctly implements:
- Dynamic year calculation
- Secure external link attributes
- Proper link targeting
39-45: LGTM! Type definition and function signature are correct.The implementation follows Next.js 15 app router conventions with proper typing and async support.
7-14: Verify version compatibility information.The banner announces version compatibility changes. Let's verify this information against the official documentation.
✅ Verification successful
🌐 Web query:
What are the supported Next.js versions for Nextra 4?💡 Result:
Nextra 4 requires **Next.js 15** or newer[1][3][4]. This version alignment is necessary because Nextra 4 exclusively uses Next.js' App Router architecture introduced in later versions, discontinuing support for older Pages Router setups[3][5]. Key compatibility details: - **Next.js 15.1.x** is explicitly referenced in migration examples and bundle size comparisons[3] - Earlier Next.js versions (14 and below) aren't compatible due to fundamental architectural changes in routing and rendering systems - The App Router dependency requires features only available since Next.js 13.4's stable App Router release[6], but Nextra 4 specifically targets v15 optimizations A compatibility table shows: | Nextra Version | Supported Next.js Versions | Router Type | |----------------|----------------------------|-------------| | Nextra 4 | 15+ | App Router | | Nextra 3 | 13-14 | Pages Router| The requirement stems from Nextra 4's integration of modern features like Turbopack support[3], hybrid rendering optimizations[1], and build-time MDX processing enhancements[7]. Developers must upgrade both Next.js and React (minimum React 18) to use Nextra 4 effectively[3][5]. Citations: - 1: https://nextra.site - 2: https://nextjs.org/docs/architecture/supported-browsers - 3: https://the-guild.dev/blog/nextra-4 - 4: https://endoflife.date/nextjs - 5: https://nextra.site/docs - 6: https://nextjs.org/blog - 7: https://nextra.site/docs/guide/ssg - 8: https://www.npmjs.com/package/nextra?activeTab=dependents - 9: https://github.com/shuding/nextra/issues/2600 - 10: https://nextra.site/about
Verification: The version compatibility information is consistent with official documentation.
The banner accurately indicates that version 1.9.0 is the final release supporting Next.js 13.5.1–14.x and that the upcoming 2.0.0 release will require Next.js 15—aligning with Nextra 4’s requirement of Next.js 15 or newer.
46-62: Track the React types issue and verify hydration warning suppression.Two points to consider:
- The
suppressHydrationWarningmight be unnecessary. Verify if it's still needed in Next.js 15.- There's a ts-expect-error comment about React v19 types that should be tracked.
Would you like me to create an issue to track the React types compatibility update once React 19 is released?
✅ Verification successful
🌐 Web query:
Is suppressHydrationWarning still needed in Next.js 15 with React 18?💡 Result:
Next.js 15 requires **React 19** and cannot be used with React 18 ([6][9]). While `suppressHydrationWarning` remains valid for unavoidable mismatches (like timestamps or browser extensions), its usage depends on context: ### Key Points 1. **Next.js 15 + React 19 Compatibility** - Next.js 15 uses React 19 by default ([3][6][9]). - Downgrading to React 18 breaks compatibility ([6]). 2. **When to Use `suppressHydrationWarning`** - Still needed for unavoidable mismatches (e.g., client-only data like `Date()` or browser extensions modifying HTML) ([1][4][7][8][10]). - Example: ```jsx <time suppressHydrationWarning>{new Date().toLocaleString()}</time> ``` 3. **Next.js Hydration Improvements** - Enhanced error messages in Next.js 15 help identify mismatches faster ([3]). - Fix root causes first (e.g., invalid HTML nesting) before using `suppressHydrationWarning` ([4][7]). ### Recommendation - **Avoid** if possible by fixing structural issues or using `useEffect`/client-side rendering for dynamic content ([1][4]). - **Use sparingly** as a last resort for non-critical mismatches ([8][10]). For projects forced to use React 18, stick with Next.js ≤14.x ([6]). Citations: - 1: https://sentry.io/answers/hydration-error-nextjs/ - 2: https://willcodefor.beer/posts/rhyd - 3: https://nextjs.org/blog/next-15-rc?ck_subscriber_id=807462252 - 4: https://dev.to/ramunarasinga/suppresshydrationwarning-what-is-it-2edd - 5: https://themobilereality.com/blog/hydration-ssr-with-react-18 - 6: https://www.wisp.blog/blog/can-nextjs-15-app-router-be-used-with-react-18 - 7: https://www.koladechris.com/blog/hydration-failed-because-the-initial-ui-does-not-match-what-was-rendered-on-the-server - 8: https://react.dev/reference/react-dom/client/hydrateRoot - 9: https://nextjs.org/blog/next-15-1 - 10: https://dev.to/pains_arch/hydration-error-when-installing-nextjs-15-1eb3
Hydration Warning and React Types Update
• Next.js 15 now mandates React 19, so the current usage of suppressHydrationWarning is acceptable when unavoidable mismatches occur—its application should, however, be minimized and only used for non-critical mismatches.
• The ts‑expect‑error comment indicates that the project pending update to React 19 types is being tracked. It’s advisable to create an issue or follow up once the React type definitions are available to remove this workaround.
1 participant
Summary by CodeRabbit
New Features
• Introduced a new linter rule for improved code style.
• Enhanced documentation layout with an updated release banner and improved MDX component integration, along with new topics on cache customization.
Chores
• Upgraded core dependencies and streamlined build/development scripts for enhanced performance and alignment with current standards.
Documentation
• Reorganized headings and reformatted content across API references, usage guides, and troubleshooting sections for clearer information and a more consistent presentation.
• Added detailed descriptions for new methods and parameters in the documentation.
• Updated formatting for notes and warnings throughout various sections for improved clarity.