Three runtime problems in `examples/cache-handler-redis`.
### 1. One new Redis connection per request, never closed
Next.js constructs the singular `cacheHandler` class once per request
(`new CurCacheHandler(...)` in `IncrementalCache`, which
`route-module.ts` creates per request). The example's constructor calls
`createClient()` + `connect()`, so every request opens a connection that
is never closed.
```
$ redis-cli client list | wc -l # before
102
$ for i in $(seq 1 10); do curl -s -o /dev/null localhost:3000/cet; done
$ redis-cli client list | wc -l
132 # +3 per request
```
With Redis' default `maxclients 10000`, a single instance runs out after
a few thousand requests.
### 2. Requests hang while Redis is unavailable
The README says the handlers "degrade gracefully when Redis is
unavailable, so the app still builds and runs, just without a shared
cache". At runtime they don't: with Redis stopped, every request on
every instance blocks until Redis comes back.
```
$ docker stop cache-handler-redis
$ curl -s -o /dev/null -m 60 -w "%{http_code} %{time_total}s\n" localhost:3000/cet
000 60.007305s # (uncapped: 188s, returned the moment Redis was started again)
```
Same when the app is started while Redis is down. Cause: node-redis
keeps retrying in the background and `client.connect()` does not settle
until a connection succeeds. Isolated:
```js
const c = createClient({ url: "redis://localhost:6379" }); c.on("error", () => {});
await Promise.race([c.connect(), new Promise(r => setTimeout(() => r("pending"), 15000))]);
// -> "pending" after 15s, isOpen=true isReady=false (redis@6.2.1)
```
Because each request built a new handler, each request awaited a fresh,
never-settling `connect()` in `getClient()`. `remote-cache-handler.js`
has one module-level client, but its `getClient()` awaits the same
promise, so it hangs the same way if the app starts while Redis is down.
### 3. `updateTag` never reaches other pages' remote entries
The remote handler's `get` never checks the entry's own tags. Next.js
only passes soft tags to `getExpiration`, and the `"use cache"` wrapper
only knows about tags revalidated in the current request, so
`updateTag("time-data")` from `/cet` left the `/gmt` entry stale on
every instance, including the one that ran it, until it expired
(`cacheLife` `expire: 3600`). The [`cacheHandlers`
docs](https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheHandlers#get)
say `get` should report an entry whose tag was invalidated as missing or
stale.
### Fix
- Hoist the client in `cache-handler.js` to module scope (the pattern
`remote-cache-handler.js` already uses).
- `getClient()` awaits the connect promise raced against a 1s
`unref()`'d timer (suggested in review), then returns the client when
`isReady` and `null` otherwise. Requests during startup still wait for
the connection, and a down Redis costs one bounded wait instead of
blocking every request. The client keeps retrying and `isReady` flips
back on its own.
- `disableOfflineQueue: true`, so a command issued while the connection
is down rejects immediately (`ClientOfflineError`) instead of being
queued for the 5s command timeout.
- Entry `get` / `set` catch the Redis call only and degrade to a miss.
- Remote `get` compares the entry's tags against their revalidation
timestamps (one `MGET`) and misses when any is newer, the same
comparison as the built-in handler. `getExpiration` returns `Date.now()`
when Redis can't answer, so the entry is discarded rather than served.
- `revalidateTag` / `updateTags` throw when Redis isn't ready, so an
invalidation that never reached Redis surfaces as an error instead of a
success whose entries come back once Redis does.
### After
Two `next start` instances on one Redis, same script on `next@16.3.5`
and `16.4.0-canary.35` (identical results), canary's handlers vs this
PR:
| scenario | before | after |
| --- | --- | --- |
| `updateTag` from `/cet`, read `/gmt` on both instances | stale |
refreshed |
| `revalidateTag("time-data", "max")` | neither page refreshed | both
refreshed |
| tag lookup fails | 500 | 200, regenerated |
| request while Redis is stopped | no response | 200, uncached |
| `updateTag` while Redis is stopped | no response | 500, error logged |
| app started without Redis | no response | first ISR read waits ≤1.1s
once |
| Redis connections, 200 requests | 173 → 773 | 7 → 7 |
| `/cet` under load (autocannon, 10 connections × 10s, `16.3.5`) | 332
req/s, hits Redis `maxclients` | 1,106 req/s median, p99 20ms, 3
connections |
| 10 readers during 20 `updateTag`s: reads served a value from before a
completed invalidation | 3,089 of 3,089 | 0 of 33,899 |
| Redis down ~4s under load | timeouts, caching doesn't come back | 0
errors, caching resumes |
The tag check costs one Redis round trip per remote hit (−9 to −13% on a
route that only reads one remote entry). Handler-level cases, full
tables and the benchmark breakdown are in [this
comment](https://github.com/vercel/next.js/pull/98716#issuecomment-5724918096).
Verify locally:
- Copy the example to a local directory
- Install deps
- docker compose up -d
- npm run build && npm run start
- navigate to localhost:3000/cet (or gmt)
- open the Redis view (link in localhost:3000/cet)
- revalidate data on /cet or /gmt
- verify it on the Redis view
I had to update the app to async params, updateTag, and write the
handler in such a way that it solved:
```
⨯ TypeError: p.segmentData.get is not a function
at ignore-listed frames
⨯ Error: failed to pipe response
```
Also adding docs edits with this caveat.
An agent review, and cross checking with a community implementation,
surfaced, that we had to read tags from
`data.headers['x-next-cache-tags']`. This agent review added a few
comments, I think they are useful, but can cut down if needed.
Last but not least, had to update the Time API endpoint (former no
longer worked).
## Summary
This PR improves the accessibility of the Ant Design example by adding
an accessible label to the icon-only `Link`.
### Changes
- Added `aria-label="Home"` to the icon-only link.
### Why
The link currently renders only an icon, so it does not provide an
accessible name for assistive technologies. Adding an `aria-label` makes
its purpose clear to screen reader users without changing the visual
appearance.
### Before
Screen readers announce the element as an unlabeled link.
### After
Screen readers announce the link as **"Home"**.
Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
## Summary
While reviewing the examples in the Next.js repository for potential
improvements, I noticed a redundant `justify-content` declaration in the
`.submit` styles.
## Changes
- Removed the redundant `justify-content: flex-end` declaration.
- Kept `justify-content: space-between`, which overrides the previous
declaration.
## Testing
No functional changes. This is a CSS cleanup only.
Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
## Summary
This PR improves the accessibility of the `with-apivideo-upload` example
by associating form labels with their corresponding form controls using
the `htmlFor` attribute.
## Changes
- Added `htmlFor="link"` to the "Play button color" label.
- Added `htmlFor="linkHover"` to the "Buttons hover color" label.
- Added an `id` to the "Hide controls" checkbox and associated its label
using `htmlFor`.
## Why
Associating labels with their corresponding form controls improves
accessibility by:
- Allowing screen readers to correctly announce form labels.
- Enabling users to focus or toggle controls by clicking their labels.
- Following HTML and WCAG best practices for accessible forms.
## Before
- Labels were visually displayed but were not programmatically
associated with their respective inputs.
## After
- Each label is associated with its corresponding form control via
`htmlFor` and `id`, improving accessibility without changing
functionality.
### Testing
- Verified that clicking each label focuses or toggles the associated
control.
- No visual changes.
Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
## Summary
While reviewing the examples in the Next.js repository for potential
improvements, I noticed a typo in the error message displayed when an
unexpected error occurs.
## Changes
- Corrected `"An unexpected error happened occurred:"` to `"An
unexpected error occurred:"`.
## Testing
No functional changes. This is a text-only fix.
Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
## Summary
Fix the `cms-webiny` example so non-preview requests read
`NEXT_PUBLIC_WEBINY_API_URL`, matching the README, deploy button, and
`.env.local.example`. The previous `NEXT_PUBLIC_WEBINY_API_UR` typo
caused the default API endpoint to resolve to `undefined`.
## Verification
- `rg -n
"NEXT_PUBLIC_WEBINY_API_UR|NEXT_PUBLIC_WEBINY_API_URL|NEXT_PUBLIC_WEBINY_PREVIEW_API_URL"
examples/cms-webiny`
- `git diff --check`
- Not run: full example runtime (`cms-webiny` requires external Webiny
API credentials)
Attribution: This change was originally authored by @tianma-if in
#95413.
<!-- NEXT_JS_LLM_PR -->
Co-authored-by: tianma <tianma@tianmadeMac-mini.local>
- new guide, Auth w/ Cache Components
- iron-session example w/ Cache Components
TODO:
- [x] opt-out from the instant requirements
- [x] e2e for the example, using instant helper
---------
Co-authored-by: Aurora Scharff <66901228+aurorascharff@users.noreply.github.com>
Co-authored-by: Aurora Scharff <aurora.sofie@gmail.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Fixes#86951
Removes the deprecated legacy `url.parse()` API (DEP0169) from the
custom-server example. The `parsedUrl` parameter is optional, so the
simplest fix is to remove the `parse()` call and pass only `(req, res)`
to the handler, matching the docs code block that was already updated in
#86986.
## For Contributors
### Fixing a bug
- Fixes #(open or reference an issue if one exists, otherwise omit)
- No tests required — this is an `examples/` change only
- No custom error links needed — failures are surfaced via Apollo's
built-in error state
---
## Summary
- `PostList` destructured `data` before checking `loading`/`error`, so
the component threw when `data` was `undefined` (e.g., on the initial
fetch or after a query error) instead of showing the loading/error UI.
- Move the `error`/`loading`/`!data` guard clauses above the `data`
destructuring and `loadMorePosts` definition, and add a `!data` check so
the component never accesses properties on an undefined value.
- Bump `graphql` (`14.5.8` → `16.13.1`) and `lodash` (`4.17.20` →
`4.17.23`) in the example's `package.json` to pick up fixes in
dependencies the example relies on.
## Note:
Initially this PR suppose to target upstream DB issue
### What?
Fix the `cms-contentful` example to use the async APIs introduced in
Next.js 15:
- Await `draftMode()` in `app/page.tsx`, `app/posts/[slug]/page.tsx`,
and
`app/api/disable-draft/route.ts`
- Update `params` type to `Promise<{ slug: string }>` and await it in
`app/posts/[slug]/page.tsx`
### Why?
In Next.js 15, `draftMode()` from `next/headers` became async and must
be awaited.
Page `params` are also now typed as a `Promise`. The example was using
the old
synchronous patterns, causing the build to fail and the app to not work
when running against the latest
version of Next.js -- this example project uses latest version of
next.js in the package.json.
### How?
Awaited `draftMode()` at each call site and updated the `params` type
signature to
`Promise<{ slug: string }>` with a corresponding `await`.
Closes NEXT-
Fixes #
Log the version of next _before_ evaluating the config in `next build`
just like `next dev`
Also, if `withRspack` is used, print a simple line saying that the
bundler has changed.
## What?
Fixes a typo in the preview message.
- This is page is a preview.
+ This page is a preview.
## Why?
The current text contains a grammatical error that is shown when preview
mode is enabled.
## Testing
* Verified the updated text renders correctly.
* No functional changes.
## Summary
Modernizes the `examples/with-ably` example off the deprecated Pages
Router and `@ably-labs/react-hooks` package, onto the App Router and the
React hooks that ship with ably-js v2.
The previous example created the Realtime client at module scope inside
`pages/_app.tsx`, which caused connections to be created during SSR. The
rewrite creates it inside a `useEffect` in a client component
(`app/ably-client-provider.tsx`), gated by an `AblyReadyContext` so
consumer components don't try to call `ably/react` hooks before the
provider is in place.
## Notable changes
- Replace Pages Router with App Router.
- Upgrade `ably` to v2; drop `@ably-labs/react-hooks` (hooks now ship as
`ably/react`).
- Bump React, react-dom and their `@types` to v19 to match
recently-modernized examples like `with-supabase`.
- `app/api/createTokenRequest/route.ts` now returns 400 when `clientId`
is missing rather than coalescing to a shared `"NO_CLIENT_ID"` value.
- Various improvements to README.md
## How I tested these changes
Ran the example with Chrome and Firefox. Verified in two browser
windows:
- Pub/sub: messages published from one window appear in both.
- Server publish: `POST /api/send-message` round-trips and broadcasts.
- Presence: events propagate between windows.
- No errors or warnings in browser console or dev console.
Co-authored-by: Fiona Corden <fiona.corden@ably.com>
## Summary
Replaces the Cloudinary-backed image gallery example with a Vercel
Blob–backed equivalent. The migration is driven by the broader move of
[`vercel/nextconf-image-gallery`](https://github.com/vercel/nextconf-image-gallery)
(the deployed companion to this example) off Cloudinary.
- Renamed `examples/with-cloudinary` → `examples/with-vercel-blob` via
`git mv` (history preserved).
- Images are discovered at build time via the `@vercel/blob` SDK's
`list()` API, then probed with
[`sharp`](https://github.com/lovell/sharp) for dimensions and to
pre-generate base64 blur placeholders. `next/image` (Vercel's image
optimizer) handles resizing — no Cloudinary `c_scale,w_*` transform
URLs.
- `ImageProps` is now `{ id, url, width, height, blurDataUrl }` (was `{
public_id, format, ... }`).
- `utils/cachedImages.ts` does the listing + dimension probe + blur
placeholder generation.
- Removed `utils/cloudinary.ts` and `utils/generateBlurPlaceholder.ts`.
- `next.config.js` `remotePatterns` now allows
`*.public.blob.vercel-storage.com`.
- Deps: dropped `cloudinary`, `imagemin`, `imagemin-jpegtran`; added
`@vercel/blob` and `sharp`.
- `.env.local.example` reduced to a single `BLOB_READ_WRITE_TOKEN`.
- README rewritten: blob description, deploy-button env, setup steps,
references.
## Test plan
- [x] `npx create-next-app --example with-vercel-blob ./blob-app` clones
cleanly
- [x] After populating a blob store and `.env.local`, `npm run dev`
renders the gallery with blur placeholders
- [x] `npm run build` succeeds (sharp probe + placeholder generation
runs at build time)
- [x] Vercel deploy button flow prompts only for `BLOB_READ_WRITE_TOKEN`
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
### 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
Eddy (Frontend Engineer)
