mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
### What? Remove outdated experimental status notices for `@next/routing` from the adapters documentation and package README. ### Why? `@next/routing` is no longer experimental, and the existing notices incorrectly tie its stabilization to the adapters API. ### How? Delete the obsolete notices while leaving the routing API documentation unchanged. ### Verification - `pnpm prettier --with-node-modules --ignore-path .prettierignore --write docs/01-app/03-api-reference/07-adapters/05-routing-with-next-routing.mdx packages/next-routing/README.md` - Repository lint-staged checks passed during commit - Not run: runtime tests (documentation-only change) <!-- NEXT_JS_LLM_PR -->
2.4 KiB
2.4 KiB
@next/routing
Shared route resolving package for Next.js.
Overview
This package provides a comprehensive route resolution system that handles rewrites, redirects, middleware invocation, and dynamic route matching with support for conditional routing based on headers, cookies, queries, and host.
Installation
npm install @next/routing
Usage
import { resolveRoutes } from '@next/routing'
const result = await resolveRoutes({
url: new URL('https://example.com/api/users'),
basePath: '',
requestBody: readableStream,
headers: new Headers(),
pathnames: ['/api/users', '/api/posts'],
routes: {
beforeMiddleware: [],
beforeFiles: [],
afterFiles: [],
dynamicRoutes: [],
onMatch: [],
fallback: [],
},
invokeMiddleware: async (ctx) => {
// Your middleware logic
return {}
},
})
if (result.resolvedPathname) {
console.log('Resolved pathname:', result.resolvedPathname)
console.log('Resolved query:', result.resolvedQuery)
console.log('Invocation target:', result.invocationTarget)
}
Route Resolution Flow
- beforeMiddleware routes - Applied before middleware execution
- invokeMiddleware - Custom middleware logic
- beforeFiles routes - Applied before checking filesystem
- Static pathname matching - Check against provided pathnames
- afterFiles routes - Applied after filesystem checks
- dynamicRoutes - Dynamic route matching with parameter extraction
- fallback routes - Final fallback routes
Route Configuration
Each route can have:
sourceRegex- Regular expression to match against pathnamedestination- Destination path with support for replacements ($1, $name)headers- Headers to apply on matchhas- Conditions that must matchmissing- Conditions that must not matchstatus- HTTP status code (3xx for redirects)
Redirects
When a route has:
- A redirect status code (300-399)
- Headers containing
LocationorRefresh
The routing will end immediately and return a redirect result with the destination URL and status code.
Has/Missing Conditions
Conditions support:
header- Match HTTP headerscookie- Match cookiesquery- Match query parametershost- Match hostname
Values can be:
undefined- Match if key exists- String - Direct string match
- Regex string - Match against regex pattern