Add a more direct error message when next is running on a platform that turbopack doesn't support
document supported turbopack platforms
## Testing
To test i just set `NEXT_TEST_WASM=1` and ran a build
```
Error: Turbopack is not supported on this platform (darwin/arm64) because native bindings are not available. Only WebAssembly (WASM) bindings were loaded, and Turbopack requires native bindings.
To use Next.js on this platform, use Webpack instead:
next dev --webpack
For more information, see: https://nextjs.org/docs/app/api-reference/turbopack#supported-platforms
at ignore-listed frames
```
so it should work. Messaging probably could be better (there is also a messge about not being able to set the lockfile) but this should be much better
Fixes#89305
<!-- 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 #
-->
---------
Co-authored-by: Joseph <sephxd1234@gmail.com>
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
## Summary
- update `experimental.adapterPath` docs to match current
`onBuildComplete` shape (`routing`, `buildId`, and latest output types)
- document `@next/routing` usage and note its experimental status
- add runtime entrypoint signature details for Node.js and Edge
(`handler(..., ctx)`)
- add a new PPR implementation section with markdown flow diagrams for
shell/resume stream composition and `requestMeta.onCacheEntryV2` cache
updates
- link to `nextjs/adapter-vercel` as the reference adapter example
### What?
`use` is not a hook. It's highlighted in the doc
> Unlike React Hooks, use can be called within loops and conditional
statements like if. Like React Hooks, the function that calls use must
be a Component or Hook.
### Why?
It confuses consumers of Next.js and adds field provide misleading
proofs
### How?
Closes NEXT-
Fixes #
-->
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Co-authored-by: Joseph <sephxd1234@gmail.com>
## What?
Adds the `experimental.turbopackIgnoreIssue` configuration option, which allows developers to suppress specific Turbopack warnings and errors based on file path, issue title, and/or description patterns. Filtered issues are hidden from both CLI output and the error overlay.
## Why?
Developers need a way to suppress noisy or expected warnings from Turbopack without disabling all warnings. This is useful for:
- Suppressing warnings from third-party code, generated files, or optional dependencies
- Reducing noise in development server output
- Hiding expected issues from the error overlay
## How?
### Configuration → Filtering Pipeline
1. **Config types** (`packages/next/src/server/config-shared.ts`, `config-schema.ts`):
Each rule has a required `path` (glob string or RegExp) and optional `title`/`description` (exact string or RegExp). All specified fields must match (AND logic).
2. **RegExp serialization** (`packages/next/src/build/swc/index.ts`):
Converts RegExp objects to `{ source, flags }` and glob strings to `{ type: 'glob', value }` for transfer to Rust.
3. **Rust deserialization** (`crates/next-core/src/next_config.rs`):
`TurbopackIgnoreIssueRule`, `TurbopackIgnoreIssuePathPattern`, and `TurbopackIgnoreIssueTextPattern` types deserialize the config. A `turbopack_ignore_issue_rules()` turbo-tasks function converts them to `IgnoreIssue` rules with proper cache invalidation.
4. **Issue filtering** (`turbopack/crates/turbopack-core/src/issue/mod.rs`):
`IssueFilter` is a turbo-tasks value that holds both severity filters and ignore rules. `IgnoreIssuePattern` supports exact string, glob, and regex matching (using `turbo-esregex` for ES-style regex). Matching issues are excluded before severity filtering.
5. **Integration** (`crates/next-api/src/project.rs`, `route.rs`, `empty.rs`):
`Endpoint::project()` trait method provides access to the project config. `issue_filter()` builds the `IssueFilter` from project config. All issue collection points use the project's dynamic filter instead of the previous hardcoded `NEXT_ISSUE_FILTER`.
### Documentation
- New docs page: `docs/01-app/03-api-reference/05-config/01-next-config-js/turbopackIgnoreIssue.mdx`
- Updated Turbopack reference page with experimental options table: `docs/01-app/03-api-reference/08-turbopack.mdx`
### Testing
E2E test suite (`test/development/app-dir/turbopack-ignore-issue/`):
- **With config**: verifies matching warnings are suppressed from CLI output, matching errors are suppressed from the error overlay, and unrelated pages still compile normally
- **Without config**: verifies warnings and errors appear when no rules are defined
### Dependencies
- Added `turbo-esregex` for ES-style regex support in Rust
## Example
```js
// next.config.js
module.exports = {
experimental: {
turbopackIgnoreIssue: [
{ path: '**/vendor/**' },
{ path: 'app/**', title: 'Module not found' },
{ path: /generated\/.*\.ts/, description: /expected error/i },
],
},
}
```
There’s an inconsistency in the docs:
[unstable_cache](https://nextjs.org/docs/app/api-reference/functions/unstable_cache)
has already been replaced by use cache, so I think the documentation
should be updated accordingly.
I’d appreciate it if you could look into this, should that be the case.
@icyJoseph
<!-- 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 #
-->
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
This pull request makes minor documentation improvements to the
`robots.mdx` API reference, correcting a typo and clarifying the
description of `robots.js` route handler behavior.
- Documentation clarity and typo fixes:
* Corrected "Route Handlers" to "Route Handler" in the description of
`robots.js` and updated the explanation for clarity.
* Fixed the spelling of "customise" to "customize" for consistency with
American English.* Fixed spelling on some words of the robots.mdx
documentation:
- Handlers (plural) to Handler (singular)
- customise = customize
<!-- 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 #
-->
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
• [x] Run pnpm prettier-fix to fix formatting issues before opening the
PR.
• [x] 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?
Fix a broken link in the ISR guide by switching to a site-absolute
/docs/... URL for the res.revalidate reference.
Why?
Without the leading /, the link can resolve as a relative path and break
depending on where it’s rendered.
How?
Update the ISR guide link target to a site-absolute
/docs/pages/guides/incremental-static-regeneration#on-demand-validation-with-resrevalidate.
Closes NEXT-
Fixes #
-->
This PR adds error handling for nested `"use cache"` where the inner
cache has a very short lifetime (zero `revalidate` or `expire` under 5
minutes) but the outer cache doesn't have an explicit `cacheLife()`
call.
Short-lived caches become "dynamic holes" that are excluded from
prerenders. When such a cache is nested inside another `"use cache"`
without an explicit `cacheLife`, the outer cache's lifetime would
silently become short too via
[propagation](https://nextjs.org/docs/app/api-reference/functions/cacheLife#nested-caching-behavior),
which can lead to unexpected behavior. To prevent this accidental
misconfiguration, Next.js now throws an error during prerendering,
requiring developers to explicitly declare their intent by adding
`cacheLife()` to the outer cache.
The implementation tracks whether `revalidate` and `expire` were
explicitly set via `hasExplicitRevalidate` and `hasExplicitExpire` flags
on the collected cache result. Errors are wrapped with
`wrapAsInvalidDynamicUsageError` to capture proper stack traces and
prevent userland try/catch from suppressing the build error.
Documentation has been updated with a new "Prerendering behavior"
section in the `cacheLife` API reference explaining how short-lived
caches become dynamic holes, and a "Nested short-lived caches"
subsection with examples showing how to fix the error.
closes NAR-761
Restores Server Function logging to be enabled by default during
development, as originally implemented in #88277. The change to opt-in
in #89321 was overly conservative. The implicit default in #88277 was an
intentional design decision.
Users can still opt out via `next.config.js`:
```js
module.exports = {
logging: {
serverFunctions: false,
},
}
```
For `'use cache'` Server Functions called from the client, the logging
still needs more work. We'll disable it for those in a follow-up PR
rather than gating the entire feature.
Also fixes a pre-existing error where `'verbose'` from the deprecated
`experimental.browserDebugInfoInTerminal` config wasn't properly
normalized to `logging.browserToTerminal`. This was now surfaced because
the default `logging` value object was not typed as `LoggingConfig`.
<!-- 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 #
-->
I noticed the snippets were slightly broken when copying them to an app.
<!-- 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 #
-->
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Server Function logging (#88277) is now opt-in, consistent with how
fetch logging works. This reduces noise in development logs by default.
Additionally, for `'use cache'` Server Functions called from the client,
the logging needs more work to be useful. Keeping it opt-in avoids
exposing incomplete functionality by default.
Server Function logging can be enabled in `next.config.js`:
```js
module.exports = {
logging: {
serverFunctions: true,
},
}
```
### What?
This PR adds support for the `type` option in Turbopack rules, enabling users to set the module type directly without requiring a custom loader. This mirrors webpack's [`type`](https://webpack.js.org/configuration/module/#ruletype) option (e.g., `type: 'asset/resource'`).
Users can now configure how files are processed by setting the module type directly:
```js
// next.config.js
module.exports = {
turbopack: {
rules: {
'*.svg': {
type: 'asset',
},
},
},
}
```
When using type: 'asset', importing the file returns its URL:
```
import svgUrl from './icon.svg'
export default function Page() {
return <img src={svgUrl} alt="Icon" />
}
```
More types are available. See docs
### What?
Adds support for TypeScript PostCSS configuration files in Turbopack.
### Why?
Users can write their PostCSS configuration in TypeScript for better
type safety and IDE support. This was already supported in webpack but
was missing in Turbopack.
### How?
Added the following TypeScript config file names to Turbopack's PostCSS
config detection:
- `postcss.config.ts`, `postcss.config.mts`, `postcss.config.cts`
- `.postcssrc.ts`, `.postcssrc.mts`, `.postcssrc.cts`
- `.config/postcssrc.ts`, `.config/postcssrc.mts`,
`.config/postcssrc.cts`
Also updated the Turbopack documentation to reflect the supported config
file extensions (`.js`, `.mjs`, `.cjs`, `.ts`, `.mts`, `.cts`).
### Testing
Added e2e tests that verify the TypeScript PostCSS config is actually
loaded and applied by using a custom plugin that transforms colors.
Tests cover:
- `postcss.config.ts`
- `postcss.config.mts`
- `postcss.config.cts`
- `.postcssrc.ts`
This PR adds a draft guide for building public pages with Cache
Components and PPR.
Part of a 3-guide series on:
- Building public pages with shared data
- Building page variants with route params (`generateStaticParams`)
- Build private pages with user-specific data
Todo:
- [x] Link to glossary terms
- [x] Link to video
- [x] Link to demo + code
- Update Partytown documentation links from `builder.io` to `qwik.dev`.
- Update Partytown installation package reference in the guide.
<!-- 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
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening
the PR.
- [x] 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?
Updated Partytown documentation URLs and the installation package
reference in the `next/script` guide.
### Why?
Partytown documentation and packages have moved from `builder.io` to
`qwik.dev`. The old links were outdated, and the package reference
needed to be updated to `@qwik.dev/partytown` to ensure users install
the correct version.
### How?
Updated
[docs/01-app/02-guides/scripts.mdx](cci:7://file:///home/hanzala/Projects/personal/next.js/docs/01-app/02-guides/scripts.mdx:0:0-0:0)
to replace `partytown.builder.io` with `partytown.qwik.dev` and updated
the `npm install` instruction.
Closes NEXT-
Fixes #
Add next.js glossary so we can reference concepts in guides without
having to re-explain them. Guides should be succint, like a skill :)
Closes: https://linear.app/vercel/issue/DOC-5574/nextjs-glossary
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
### What?
Part of PACK-1007
Adds `condition.query` support to Turbopack's loader rules, enabling loaders to match based on import query strings (e.g., `import './file?raw'`). This mirrors webpack's `resourceQuery` functionality.
The `query` condition accepts either a string (exact match) or RegExp (pattern match).
Adds tests and documentation for the new `condition.query` option.
### How to use
```js
// next.config.js
module.exports = {
turbopack: {
rules: {
'*.txt': [
// String: exact match
{ condition: { query: '?raw' }, loaders: ['raw-loader'], as: '*.js' },
// RegExp: pattern match
{ condition: { query: /\?transform/ }, loaders: ['transform-loader'], as: '*.js' },
],
},
},
}
```
add link to the mcp client configuration details section before the code
block of example
---------
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: timneutkens <tim@timneutkens.nl>
Based on our metrics, the P99.9 for a source image is 47 MB so we can
adjust the default setting to be much lower (by changing from from 300
MB to 50 MB) in favor of reducing memory.
## Summary
Fixes#88291
The Pages Router fonts documentation was incorrectly showing App Router
examples (`app/layout.tsx`) which don't exist in Pages Router. This
confused users trying to use fonts with the Pages Router.
## Changes
Updated `docs/01-app/01-getting-started/13-fonts.mdx` to include proper
`<AppOnly>` and `<PagesOnly>` sections:
**For Pages Router users:**
- Added examples using `pages/_app.tsx` (Custom App) to wrap components
with font className
- Added examples using `pages/_document.tsx` (Custom Document) to apply
fonts to the `<html>` element
**For App Router users:**
- Wrapped existing `app/layout.tsx` examples in `<AppOnly>` sections
This follows the same pattern used in other shared documentation like
`docs/01-app/01-getting-started/11-css.mdx` which properly separates App
Router and Pages Router content.
## Description
This PR adds dedicated documentation pages for `useSearchParams` and
`useParams` hooks in the Pages Router documentation.
### Changes
- Added
`docs/02-pages/04-api-reference/03-functions/use-search-params.mdx`
- Added `docs/02-pages/04-api-reference/03-functions/use-params.mdx`
### Why
Both `useSearchParams` and `useParams` from `next/navigation` work in
the Pages Router, but this was not well documented. The only mention was
a brief note in the App Router docs and a migration section in the Pages
Router `useRouter` docs.
### What's Documented
For both hooks:
- Basic usage with the fallback UI pattern for handling `null` during
pre-rendering
- Return values and behavior differences from App Router
- Usage with `getServerSideProps` (where params are immediately
available)
- Examples for sharing components between App Router and Pages Router
For `useParams` specifically:
- Comparison with `router.query` (which includes both dynamic params and
query string params)
### Related Test
The existing test at `test/e2e/app-dir/params-hooks-compat` validates
that these hooks work in both routers.
Joseph
