<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
Update config files in the `with-docker` example inside the
`.dockerignore`
### Why?
They are outdated
### How?
Add lines
cc @icyJoseph
---------
Co-authored-by: Joseph <sephxd1234@gmail.com>
- Remove BuildKit cache mount on `.next/cache` that trapped fetch cache
in a volume unreachable by the runner stage
- Restore `mkdir .next && chown` in runner stage for writable prerender
cache
- Add commented-out `COPY .next/cache` line as opt-in for persisting
build-time fetch cache
- Apply same fixes to `Dockerfile.bun` (only needed the `mkdir`/`chown`,
it never had the BuildKit mount)
Closes#90648
This pull request updates the blog post rendering in the EdgeDB example
to use our `streamdown` library in static mode instead of
`react-markdown` for Markdown parsing and rendering.
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
## What?
Modernizes the existing `with-docker` example and adds a new
`with-docker-export-output` example demonstrating different Next.js
deployment strategies with Docker best practices:
1. **`with-docker` (updated)** - Modernized to use App Router,
TypeScript, Tailwind CSS v4, and comprehensive Docker best practices.
Now includes both Node.js and Bun Dockerfile options, Docker Compose
with profiles, BuildKit cache mounts, and extensive documentation.
2. **`with-docker-export-output` (new)** - Demonstrates Next.js static
export mode deployment with Docker, offering two serving options:
**Nginx** (production-grade) and **serve** package (Node.js-based,
simpler setup). Includes optimized Nginx configuration, BuildKit cache
mounts, and comprehensive documentation.
Both examples include detailed documentation explaining Docker best
practices, implementation decisions, and deployment guidance.
## Why?
The existing `with-docker` example was using the Pages Router and
lacked:
- Modern Next.js patterns (App Router, TypeScript)
- Detailed documentation explaining Docker best practices and
implementation decisions
- BuildKit cache mounts for optimized build performance
- Bun runtime support as an alternative to Node.js
- Docker Compose configurations for easier local development
- Clear documentation about Node.js image variant choices (slim vs
Alpine)
- Examples demonstrating static export mode
These updates serve as comprehensive references for developers who want
to understand:
- How to Dockerize Next.js applications for different deployment
scenarios
- Why certain choices are made and how to optimize Docker setups for
production
- When to use standalone mode vs static export mode
- How to choose between Node.js and Bun runtimes
- How to choose between different web servers (Nginx vs serve) for
static sites
## How?
### `with-docker` example (updated)
- **Migrated to App Router** with TypeScript and Tailwind CSS v4
- **Multi-stage Dockerfile** with three stages: dependencies
installation, build, and runtime
- **Bun support** via `Dockerfile.bun` with optimized configuration
- **BuildKit cache mounts** for package manager stores (`npm`, `yarn`,
`pnpm`, `bun`) and Next.js build cache
- **Security best practices** with non-root user execution (built-in
`node` and `bun` users)
- **Docker Compose configuration** with profiles for Node.js (default)
and Bun
- **Comprehensive `.dockerignore`** to minimize build context size
- **Detailed README** explaining standalone mode benefits, Node.js image
choices, and deployment guidance
- **Deleted** `with-docker-standalone-output` (merged into this example)
### `with-docker-export-output` example (new)
- **Two Dockerfile options:**
- `Dockerfile` - Nginx-based serving with `nginxinc/nginx-unprivileged`
for security
- `Dockerfile.serve` - Node.js serve package-based serving for simpler
deployments
- **Multi-stage builds** for both options with separate dependency,
build, and runtime stages
- **BuildKit cache mounts** for package manager stores and Next.js build
cache
- **Production Nginx configuration** (`nginx.conf`) with gzip
compression, caching headers, and security best practices
- **Docker Compose configuration** supporting both serving options via
profiles
- **Comprehensive README** explaining static export mode, trade-offs
between Nginx and serve
### Docker best practices implemented (both examples)
| Practice | Description |
|----------|-------------|
| Multi-stage builds | Optimal image size reduction |
| Layer caching | Package files copied first |
| Minimal build context | Comprehensive `.dockerignore` files |
| BuildKit cache mounts | Faster subsequent builds |
| Security hardening | Non-root user execution |
| Corepack | yarn/pnpm version management |
| Package manager auto-detection | npm, yarn, pnpm support |
| Node.js 24.13.0-slim | Clear upgrade guidance |
## Breaking Changes
> **Warning**
> - `with-docker` now uses App Router instead of Pages Router
> - `with-docker-standalone-output` has been removed (merged into
`with-docker`)
---
**Note:** After this PR is approved and merged, I plan to open a
follow-up PR to update the Next.js documentation with proper links to
these Docker examples.
---------
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Co-authored-by: kristiyan.velkov <kristiyan.velkov@ffw.com>
## Summary
Updates the `with-mysql` example to use latest versions of all
dependencies.
### What
- Migrate from Pages Router to App Router
- Update to React 19 and Next.js latest
- Update to Tailwind CSS v4 with `@import "tailwindcss"` syntax
- Update to Prisma 7 with `@prisma/adapter-planetscale` driver adapter
- Convert all files to TypeScript
- Remove unused API route and `vercel.svg`
- Update README to clarify this is for PlanetScale MySQL and link to
[vercel/postgres-next-starter](https://github.com/vercel/postgres-next-starter)
for Postgres users
### Why
The example was significantly outdated:
- Prisma 3.10.0 → Prisma 7 (latest)
- Tailwind 3.0.23 → Tailwind 4
- React 18.2.0 → React 19
- Pages Router → App Router
### How
Followed the official migration guides:
- [Prisma 7 upgrade
guide](https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-7)
- [PlanetScale quickstart with
Prisma](https://www.prisma.io/docs/getting-started/prisma-orm/quickstart/planetscale)
- Aligned configuration files with a fresh `create-next-app` output
## Related
N/A
## How to Test
```bash
cd examples/with-mysql
npm install
# Set up .env with your PlanetScale DATABASE_URL
npx prisma generate
npx prisma db push
npx prisma db seed
npm run dev
```
## Checklist
- [x] Tests and samples are included
- [x] Documentation is updated (README)
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
## What?
Add `suppressHydrationWarning` to the `<html>` element in the
blog-starter example.
## Why?
The ThemeSwitcher script runs before React hydration and adds `dark`
class and `data-mode` attribute to the `<html>` element, causing a
hydration mismatch error.
## How?
Add `suppressHydrationWarning` to the `<html>` element to tell React
this mismatch is intentional.
Fixes#74586
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
-->
(sorry for my bad english)
### What?
Change `/examples/with-docker/Dockerfile.bun` to use group/useradd
instead of addgroup/user.
### Why?
Currently, the `docker build` command results in an error
`/bin/sh: 1: addgroup: not found`.
(related issue: oven-sh/bun#25441)
### How?
I changed the addgroup/user command to user/groupadd as a workaround.
[#](https://github.com/oven-sh/bun/issues/25441#issuecomment-3668036074)
fixes#87722.
---------
Co-authored-by: Joseph <sephxd1234@gmail.com>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
## Summary
Correct spelling errors in the cms-agilitycms example, including the
image prop spelling and dependency imports.
Bug Fixes:
- Fix misspelled intersectionTreshold prop to intersectionThreshold in
the Image component and its useInView configuration
Enhancements:
- Rename dependancies.ts to dependencies.ts and update
requireComponentDependancyByName to requireComponentDependencyByName
across API and component imports
### Adding or Updating Examples
- [x] The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`.
See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
## Summary
Fix typos in code, styles, and documentation across multiple example
projects
Chores:
- Correct variable name typo in the with-slate example
(edtorState→editorState)
- Fix CSS/SASS class name misspellings (populer→popular, Serach→Search,
serachSelector→searchSelector)
- Update example documentation and comments to fix English typos (Data
SOUCE→SOURCE, accessiblity→accessibility, exchanges, doesn't, deploying,
validates, quickly)
### Adding or Updating Examples
- [x] The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`.
See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
### What?
Upgrade with-supabase example to be compatible with Next.js 16
### Why?
1. Users get console warnings about middleware vs proxy
2. Enabling Cache Components config results in build errors for async
behaviour outside Suspense boundary
3. Turbopack flag is default and therefore, no longer necessary on `npm
run dev`
### How?
1. Renamed all instances of `middleware` to `proxy`
2. Wraped async behaviour in Suspense boundaries
3. Removed --turbopack flag from `npm run dev`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Improve deobfuscation of 'imported module identifier' and attempt to deobfuscate error messages logged by the server.
Before
```
⨯ TypeError: (0 , __TURBOPACK__imported__module__$5b$project$5d2f$examples$2f$with$2d$turbopack$2f$app$2f$foo$2e$ts__$5b$app$2d$rsc$5d$__$28$ecmascript$29$__.foo) is not a function
at Page (app/page.tsx:5:6)
3 | export default function Page() {
4 | /** @ts-ignore */
> 5 | foo();
| ^
6 | return <h1>Hello, Next.js!</h1>;
7 | }
8 | {
```
after
```
⨯ TypeError: {imported module ./examples/with-turbopack/app/foo.ts}.foo is not a function
at Page (app/page.tsx:5:6)
3 | export default function Page() {
4 | /** @ts-ignore */
> 5 | foo();
| ^
6 | return <h1>Hello, Next.js!</h1>;
7 | }
8 | {
```
Similarly in devtools
before:

after

This is definitely an improvement but i am not sure i put the deobfuscation logic in the best place for the console case. Happy for feedback
Certain patterns in source code cause turbopack to scan the project directories for resources. This can go wrong when one of those patterns can traverse into .next (oroborous!).
There is no usecase for turbopack to read files from the distDir during analysis and we can prevent that with a simple filter at the FileSystem layer which is what this PR does. Given the recent `build/dev` split this is a little subtle, so i added a new property to `NextConfigComplete` so we always pass the original `distDir` down even when we are performing the `dev` split.
The semantics of this are implemented at the filesystem layer which means:
* writing into a 'denied_path' is an error
* reading a denied path is 'not found'
* reading the parent directory of a denied path filters it.
Closes PACK-5593
Closes#84734
Fixes environmental variable names in `with-supabase` example README to
match the actual `.env.example` file.
Updates `NEXT_PUBLIC_SUPABASE_ANON_KEY` to
`NEXT_PUBLIC_SUPABASE_PUBLISHABLE_OR_ANON_KEY` in two locations.
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
### What?
This PR removes the automatic ESLint linting that previously ran during `next build`. The documentation has been updated to reflect this change.
### Why?
As part of Next.js 16, we're removing the automatic build-time linting that was previously included in the build process. This gives developers more control over when linting runs by explicitly invoking their linter via npm scripts.
### How?
- Updated documentation to clarify that automatic build-time linting has been removed in Next.js 16
- Removed the `runLint` parameter and related linting code from the build process
- Removed the `verifyAndLint.ts` file which is no longer needed
- Simplified type checking code by removing lint-related functionality
- Removed ESLint telemetry during builds
### What?
Replaces:
```ts
// @ts-ignore locales are readonly
const locales: string[] = i18n.locales;
```
with:
```ts
const locales = Array.from(i18n.locales);
```
### Why?
Avoids suppressing TypeScript errors via @ts-ignore.
Array.from safely creates a mutable copy without modifying the readonly
original, making the code cleaner and more type-safe.
### How?
Used Array.from(i18n.locales) instead of a forced type assertion.<br>
<br>
No functional change, purely a lint-/type-safety improvement.
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
## Summary
Updated
`examples/with-docker-compose/next-app/prod-without-multistage.Dockerfile`
to use `node:lts-alpine` instead of `node:18-alpine`, since Node 18 is
reaching end of life and contains known vulnerabilities.
## Changes
- Updated base image in prod-without-multistage.Dockerfile from
`node:18-alpine` → `node:lts-alpine`
## How I Tested
- Built Docker image locally → worked successfully.
## Notes
Part of cleanup for outdated Docker examples.
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
### What?
This PR fixes a typo in the `with-mqtt-js` example
(`examples/with-mqtt-js/app/page.tsx`):
all occurrences of "incomming" have been corrected to "incoming" in
variables, refs, and JSX headings.
### Why?
The previous spelling "incomming" is incorrect in English. Correcting it
improves readability and professionalism in the example code.
### How?
- Renamed `incommingMessages` → `incomingMessages`
- Renamed `setIncommingMessages` → `setIncomingMessages`
- Renamed `incommingMessageHandlers` → `incomingMessageHandlers`
- Updated JSX headings and references accordingly
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
This PR adds an example on how to lint your app with Oxlint
### Why?
As an example to user another linter than Biome or ESLint.
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Co-authored-by: Joseph <sephxd1234@gmail.com>
## For Contributors
### Improving Documentation
This PR improves the Next.js examples by converting relative imports to
@ aliases, making them more readable and maintainable.
## Description
Fixes#83717 by converting deep relative imports to clean @ aliases in
Next.js examples.
Currently, Next.js examples use long relative imports like:
```typescript
import { i18n, type Locale } from "../../../i18n-config";
```
This PR updates them to use clean @ aliases:
```typescript
import { i18n, type Locale } from "@/i18n-config";
```
## Changes Made
- **Added path alias configuration** `"@/*": ["./*"]` to tsconfig.json
files
- **Converted deep relative imports** (d:) to clean @ aliases (`@/`)
- **Updated examples**:
- `i18n-routing` (specifically mentioned in issue #83717) - 5 files
- `with-typescript` - 2 files
- `with-grafbase` - 2 files
- `with-mongodb-mongoose` - 2 files
## Benefits
- **Improved readability**: `@/config` vs `../../../config`
- **Reduced errors**: No need to count `../` levels when refactoring
- **Better maintainability**: Easier to move files around
- **Modern standards**: Aligns with production Next.js practices
- **Better IDE support**: Enhanced autocomplete and navigation
## Examples of Changes
### Before:
```typescript
import { i18n, type Locale } from "../../../i18n-config";
import { getDictionary } from "../../get-dictionary";
import { grafbase } from "../../../lib/grafbase";
```
### After:
```typescript
import { i18n, type Locale } from "@/i18n-config";
import { getDictionary } from "@/get-dictionary";
import { grafbase } from "@/lib/grafbase";
```
## Testing
- TypeScript compilation works correctly
- @ imports resolve properly in IDE
- Runtime functionality preserved
- No breaking changes to example functionality
This change is purely a developer experience improvement and doesn't
affect runtime behavior.
---------
Co-authored-by: dharunr36 <dharunr.23aid@kongu.edu>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
### What?
Expanded the `with-docker` example for usage with `bun` and added build
instructions to the README.
### Why?
The existing example supports npm, yarn and pnpm, but not bun.
### How?
- Add a separate Dockerfile.bun placed next to the existing Dockerfile,
which is more sensible for the existing solution.
- Dockerfile.bun uses the official oven/bun base image (different
runtime/tooling than node:18-alpine), so a separate file should be
clearer.
- Existing Docker commands in the README remain unchanged, because
Docker still uses the existing Dockerfile by default.
- The bun example can be built with: `docker build -f Dockerfile.bun -t
nextjs-docker .`
Related to #78465, #82998
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Co-authored-by: Joseph <sephxd1234@gmail.com>
This PR updates all example Dockerfiles that were using `node:18-alpine`
to `node:20-alpine`
to align with current LTS and address known issues in Node 18 images.
- examples/with-docker/Dockerfile
- examples/with-docker-compose/next-app/prod.Dockerfile
- examples/with-docker-compose/next-app/dev.Dockerfile
- examples/with-docker-multi-env/docker/development/Dockerfile
- examples/with-docker-multi-env/docker/production/Dockerfile
- examples/with-docker-multi-env/docker/staging/Dockerfile
I verified local builds for each example. No behavior changes;
docs/examples only.
https://github.com/vercel/next.js/issues/78465
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
The `legacyBehavior` prop of the `Link` component has been deprecated
since #77473. For Next.js 16, we're finally removing support for it.
Consequently, we're also removing support for the `passHref` prop, which
was only useful in conjunction with the `legacyBehavior` prop.
A [codemod is
available](https://nextjs.org/docs/app/guides/upgrading/codemods#new-link)
to help you automatically upgrade your codebase.
reverts #77473
---------
Co-authored-by: Sebastian Sebbie Silbermann <sebastian.silbermann@vercel.com>
What?
This PR updates the dependency "prettier" from version 3.2.5 to version
3.6.2. It also modifies other scripts by using the pnpm run prettier-fix
after updating the dependency.
Why?
This is updated to benefit from the changes and fixes introduced in the
newer versions of prettier, from versions 3.3 to 3.6.
How?
The package has been updated using pnpm install prettier@latest, and the
files other than package.json and pnpm-lock.json have been modified
using the script pnpm run prettier-fix.
This PR does only have formatting changes introduced by the updated
dependency
This PR is the same as #82719 , with fixes implemented to prevent
prettier to modifiy symlink files
## What
This PR updates
`examples/with-supabase/components/tutorial/fetch-data-steps.tsx` to
include a missing step about enabling Row Level Security (RLS) and
creating a simple read policy for the `notes` table.
Fixes: #82218
## Why
Currently, the tutorial shows how to:
- create a `notes` table
- insert data
- query data from Next.js
However, since RLS is enabled by default in Supabase, new users will get
`permission denied` errors when querying data unless they configure
policies.
The official Supabase Next.js quickstart docs already mention this:
https://supabase.com/docs/guides/getting-started/quickstarts/nextjs
Adding this step will help newcomers understand why RLS is required and
how to set it up.
## Changes
- Added a new `<TutorialStep>` in `fetch-data-steps.tsx`:
- Explains that RLS is enabled by default
- Shows SQL snippet to enable RLS + create a public read policy
- Links to the Supabase RLS docs
## Checklist
- [x] Added RLS tutorial step
- [x] Verified formatting matches other tutorial steps
- [x] Added links to relevant Supabase docs
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
## Problem
The project was experiencing npm dependency resolution conflicts when
running `npm install`, caused by incompatible @types/node versions
between Vite 7.1.3 and the existing project dependencies.
Fixes: https://github.com/vercel/next.js/issues/82779
**Error Details:**
- Vite 7.1.3 requires `@types/node@"^20.19.0 || >=22.12.0"`
- Project was using `@types/node@20.10.4`
- This created a peer dependency conflict, preventing clean installs
## Solution
Updated `@types/node` from `20.10.4` to a compatible version that
satisfies Vite 7.x requirements while maintaining compatibility with
Vitest 3.2.4.
## Changes Made
- Updated `@types/node` version in package.json
- Verified compatibility with all existing dependencies
- Confirmed tests still pass with deprecation warnings (React.act import
warnings - separate issue)
## Testing
- [x] `npm install` runs without errors
- [x] `npm test` passes all existing tests
- [x] No breaking changes to existing functionality
## Additional Notes
This fix resolves the immediate dependency conflict. The React.act
deprecation warnings in tests are a separate issue and should be
addressed in a future PR by updating test imports from
`react-dom/test-utils` to `react`.
Details Issue:
1]
npm test
> test
> vitest
The CJS build of Vite's Node API is deprecated. See
https://vite.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated
for more details.
DEV v1.0.4
/home/hareesh/learn-frontend/front-open-source/next.js/examples/with-vitest
stderr | app/blog/[slug]/page.test.tsx > App Router: Works with dynamic
route segments
Warning: `ReactDOMTestUtils.act` is deprecated in favor of `React.act`.
Import `act` from `react` instead of `react-dom/test-utils`. See
https://react.dev/warnings/react-dom-test-utils for more info.
stderr | app/page.test.tsx > App Router: Works with Server Components
Warning: `ReactDOMTestUtils.act` is deprecated in favor of `React.act`.
Import `act` from `react` instead of `react-dom/test-utils`. See
https://react.dev/warnings/react-dom-test-utils for more info.
stderr | app/counter.test.tsx > App Router: Works with Client Components
Warning: `ReactDOMTestUtils.act` is deprecated in favor of `React.act`.
Import `act` from `react` instead of `react-dom/test-utils`. See
https://react.dev/warnings/react-dom-test-utils for more info.
stderr | __tests__/Home.test.tsx > Pages Router
Warning: `ReactDOMTestUtils.act` is deprecated in favor of `React.act`.
Import `act` from `react` instead of `react-dom/test-utils`. See
https://react.dev/warnings/react-dom-test-utils for more info.
2]
npm install
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving: vite@7.1.3
npm error Found: @types/node@20.10.4
npm error node_modules/@types/node
npm error dev @types/node@"20.10.4" from the root project
npm error peerOptional @types/node@"^18.0.0 || ^20.0.0 || >=22.0.0" from
vitest@3.2.4
npm error node_modules/vitest
npm error dev vitest@"^3.2.4" from the root project
npm error
npm error Could not resolve dependency:
npm error peerOptional @types/node@"^20.19.0 || >=22.12.0" from
vite@7.1.3
npm error node_modules/vite
npm error peer vite@"^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" from
@vitejs/plugin-react@4.7.0
npm error node_modules/@vitejs/plugin-react
npm error dev @vitejs/plugin-react@"^4.2.1" from the root project
npm error vite@"^5.0.0 || ^6.0.0 || ^7.0.0-0" from vitest@3.2.4
npm error node_modules/vitest
npm error dev vitest@"^3.2.4" from the root project
npm error
npm error Conflicting peer dependency: @types/node@24.3.0
npm error node_modules/@types/node
npm error peerOptional @types/node@"^20.19.0 || >=22.12.0" from
vite@7.1.3
npm error node_modules/vite
npm error peer vite@"^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" from
@vitejs/plugin-react@4.7.0
npm error node_modules/@vitejs/plugin-react
npm error dev @vitejs/plugin-react@"^4.2.1" from the root project
npm error vite@"^5.0.0 || ^6.0.0 || ^7.0.0-0" from vitest@3.2.4
npm error node_modules/vitest
npm error dev vitest@"^3.2.4" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency
resolution.
npm error
npm error
npm error For a full report see:
npm error
/home/hareesh/.npm/_logs/2025-08-19T17_17_17_782Z-eresolve-report.txt
npm error A complete log of this run can be found in:
/home/hareesh/.npm/_logs/2025-08-19T17_17_17_782Z-debug-0.log
---------
Co-authored-by: Joseph <sephxd1234@gmail.com>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
# Improve Content Security Policy Documentation
This PR comprehensively improves the Next.js Content Security Policy
(CSP) documentation to address community feedback from Reddit and GitHub
discussions about gaps in the current documentation.
## Changes Made
### 1. Enhanced Nonce Flow Explanation
- Added detailed section explaining how Next.js automatically detects
and applies nonces during server-side rendering
- Clarified the 3-step process: middleware generation → Next.js
extraction → automatic application
- Explained that developers don't need to manually add nonces to every
script tag
### 2. Static vs Dynamic Rendering Documentation
- Added comprehensive section explaining performance implications of
using nonces
- Documented that nonces force all pages into dynamic rendering
- Explained trade-offs: slower page loads, increased server load, no CDN
caching
- Added guidance on when to use nonces vs alternatives
### 3. Experimental SRI (Subresource Integrity) Documentation
- Documented the experimental `sri.algorithm` configuration option
- Explained hash-based CSP as an alternative to nonces that preserves
static generation
- Included configuration examples and benefits/limitations
- Noted that SRI is webpack-only, App Router only, and experimental
### 4. Development vs Production Considerations
- Added section addressing environment-specific CSP requirements
- Documented need for `'unsafe-eval'` in development for HMR
- Provided conditional CSP examples based on NODE_ENV
### 5. Comprehensive Troubleshooting Section
- Added solutions for error pages that don't work with strict CSP
- Documented third-party script integration with CSP
- Included common CSP violation fixes
- Added examples for both App Router and Pages Router
### 6. Practical Examples
- Static site with hash-based CSP using SRI
- Dynamic site with nonce-based CSP
- Mixed approach for different page types
- Environment-aware CSP configuration
### 7. Enhanced Pages Router Documentation
- Added `_document.tsx` nonce access example
- Improved `getServerSideProps` examples
- Added third-party script integration examples
## Community Feedback Addressed
This PR directly addresses the Reddit thread feedback about:
- ❌ "it is not clear that the nonce is then picked up by the rest of the
pages" → ✅ Added detailed nonce flow explanation
- ❌ "it is not clear that the pages therefore are not statically
generated anymore" → ✅ Added static vs dynamic rendering section
- ❌ "The solution of being able to provide the sha256 hashes... is not
supported, and it is not mentioned in the documentation" → ✅ Added
experimental SRI documentation
- ❌ Poor documentation of strict CSP implementation → ✅ Added
comprehensive examples and troubleshooting
## Technical Details
- **File Modified**: `docs/01-app/02-guides/content-security-policy.mdx`
- **Lines Added**: 642 insertions
- **Maintains**: Existing documentation structure and Next.js
conventions
- **Supports**: Both App Router and Pages Router with appropriate
switcher components
## Testing
- Verified all code examples use correct Next.js APIs and patterns
- Ensured documentation follows existing Next.js docs structure
- Confirmed all referenced configuration options exist in the codebase
- Validated that experimental features are properly marked as such
---
**Link to Devin run**:
https://app.devin.ai/sessions/e7e5fa95dc0146b3ab79aac72c53ed13
**Requested by**: lee@vercel.com
---------
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Co-authored-by: lee@vercel.com <lee@vercel.com>
Co-authored-by: Joseph Chamochumbi <joseph.chamochumbi@vercel.com>
### What?
Fix the signatures of `useMDXComponents`.
### Why?
The `useMDXComponents` function is always called without any arguments.
It’s also always supposed to be a named export, not a default export.
It’s also called during render. Defining React components during render
is an anti-pattern. All components that were previously defined inside
of `useMDXComponents`, are now defined outside of the function.
### How?
Manual fixes.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Joseph <sephxd1234@gmail.com>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Updates the `with-supabase` example to use the new and much faster (when
project is configured with asymmetric JWT support)
`supabase.auth.getClaims()` function instead of `getUser()`.
---------
Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>
- A Next.js starter app using [Prisma
Postgres](https://www.prisma.io/postgres) and Prisma ORM
This PR adds a new example demonstrating how to integrate Prisma ORM
with a Next.js application. The example includes:
- Setup instructions for Prisma Postgres
- Example models and queries
- Basic CRUD operations using Prisma
---------
Co-authored-by: Nikolas <nikolas.burk@gmail.com>
Co-authored-by: Alex Martin <alex.martin@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>