This ensures we don't normalize locales in the URL with the
skipMiddlewareUrlNormalize flag enabled so that casing redirects can be
applied correctly for locales.
Turbopack starts up the router process with all ENV values, but the edge
function definition didn't list any `env` keys for the function
invocation. So, middleware couldn't access any ENV values.
Turbopack doesn't currently have a way to determine what ENV keys are
actually used by the source program, so I'm just passing everything
defined. I'm not sure if that's an issue during dev (I could see it
being one for the build process, but that doesn't matter for this case).
Fixes#47766
Fixes WEB-831
Fixes WEB-834
This ensures we check if a path is `appRouter` during prefetching so
that we can trigger hard navigations quicker when routing from pages ->
app. An additional config is also exposed to allow configuring the
potential false positive rate for the client filter.
x-ref: [slack
thread](https://vercel.slack.com/archives/C017QMYC5FB/p1680225393243459)
Paired with https://github.com/vercel/turbo/pull/4329, this implements
streaming responses for App and API renders. This is accomplished by
sending an initial `headers` message (carrying the status code and
headers list), N `body-chunk` messages of bytes, and a final `body-end`
message to signal completion.
Once sent to Turbopack, these chunk messages will be streamed out of the
node rendering process directly into the HTTP server's response.
Closes WEB-27
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Fixes an issue with newer app directory usage:
```
Failed to compile.
../../node_modules/next/dist/server/future/route-handlers/app-route-route-handler.d.ts:11:15
Type error: ',' expected.
```
---------
Allow to use relative paths which starting with dot (e.g. `./[paths]`) for urls under `metadata.alternates`.
This allow user to simplify setting `canonical` or other such like `languages` once in root layout with `metadataBase` and a simple relative path, then next.js will resolve it with current pathname of the page.
For example
```js
export const metadata = {
metadataBase: new URL('https://mydomain.com'),
alternates: {
canonical: './'
}
}
```
Then:
for page `/` it will generate `https://mydomain.com`;
for page `/about` it will generate `https://mydomain.com/about`
as your cononical url
Closes NEXT-897
### Minor changes
- always remove trailing slash for `URL.href`
## What
This fix serves to address issues where multiple `Set-Cookie` headers
were combined in some runtimes.
## Why
This is because `set-cookie` behaves differently than other headers in
some cases.
Eg. when iterating on a `Headers` instance, multiple set-cookie headers
are folded. To set them correctly, we need to split them. But it'd not
be enough to naively split on the first occurrence, because `,` is a
valid cookie value when for example it's used in `Expires` in a date
string.
So we use a method to correctly detect where to split the cookie.
This should fix all runtimes.
Note, the spec now has `Headers#getSetCookie` which should be preferred
if it's present. https://github.com/whatwg/fetch/pull/1346. We are using
the [`edge-runtime`](https://github.com/vercel/edge-runtime), so this
should be fixed upstream and then reused in Next.js in the future.
## How
Wherever we can, we reuse the `fromNodeHeaders` and `toNodeHeaders`
methods that have the correct implementation. This should be preferred
in the future in other parts of the codebase. We fixed some related TS
issues as well.
Fixes#46579, supersedes #40579
fix NEXT-735 ([link](https://linear.app/vercel/issue/NEXT-735))
---------
Co-authored-by: Balázs Orbán <info@balazsorban.com>
### What?
This PR adds an internal compile time flags for the `next-swc`, which exposes two runtime apis into next.js to initialize heap-profiling enabled memory allocator and teardown those once next.js exits. While there are newly added 2 js interfaces (`initHeapProfiler`, `teardownHeapProfiler`) underlying napi binary itself have compile time flags to actually enable those feature: any user who runs npm-published next.js cannot enable this features with any kind of runtime configuration. Only manually built next-swc binary with specific flag can enable this. Since this is primarily for the CI testing workflow only, those flag / configs are not visibily exposed as well.
### Why?
It is for some experiments on the CI to see if it can observe some of memory pressure issues (WEB-593, WEB-804) while it is not easily reproducible on the local machines.
Based on some suggestions from @sokra, this serves to unify the Route Handlers and Route Modules to provide a unified interface for defining route modules and handlers and defining their dependancies.
Adding default metadata before causes duplicated metadata tags when
adding server inserted html. Remove the ones in the not found boundary
Now we use same way to render metadata to render the default metadata in
error html
Fixes the issue introduced in #47404
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
- Provide a default `metadataBase`
- Always resolve urls that could be resolved as absolute with
`metadataBase`, e.g. tw/og urls, canonical urls
- Give a warning in dev mode if user doesn't provide one in dev
- Error if you don't have it but it's required in production
On production it will leverage `VERCEL_URL` if users expose it to the
deployment
### Why?
OG image urls are required to be absolute urls instead of relative urls.
For metadata image conventions we let users don't have to provide
`metadataBase` explicitly when they expect it should be the origin of
their next app.
### How?
Closes NEXT-887
---------
### What?
Followup for #47630 , use ts namespace to group MetadataRoute.
`MetadataRoute['xxx']` -> `MetadataRoute.xxx`
### Why?
namespace is convenient to write for these grouped types such as
`MetadataRoute.Robots`. And `MetadataRoute` itself is not actually a
type. So it can be conveniently typed by ts users.
### How?
Closes NEXT-912
---------
just took a bit of banging my head against the wall 👀
the `'dynamic route/page check'` route resolves `fsRoutes` (which leads to an object with `{pages: undefined}` because the route doesn't have the list of pages(?))
that route only gets enabled if you have fallback rewrites though
### What?
- Add not found boundary to app router
- Move `head` cache back to app router
### Why?
We want the head to be rendered separately from body, previously to be
able to use `redirect()` and `notFound()` in `generateMetadata` we move
the head cache into layout-router to be wrapped by not found and
redirect boundaries. Since redirect boudary is already moved to
app-router, so we only need to add not found boundary and move head
cache to app router.
Notice: there's a limitation that we can't find the corresponding not
found of page if you throw notFound in generateMetadata, the root layout
+ root/default not found will be used to generate the 404 page
### How?
Closes NEXT-864
Fixes#46738
fix NEXT-888 ([link](https://linear.app/vercel/issue/NEXT-888))
---------
Previously, `next start` was incorrectly trying to optimize an empty `src` prop.
This PR fixes the behavior so that empty `src` will automatically set `unoptimized` (same behavior as data urls).
fix NEXT-915 ([link](https://linear.app/vercel/issue/NEXT-915))
Fixed issue where `require` will return a Promise if (and only if) there
is an ESM module imported in `instrumentation.ts`:
61cd219f15/packages/next/src/server/next-server.ts (L212)
Had to move stuff to async function from constructor, but luckily we
already have `prepare`.
### What / Why / How?
In a project with `"type": "module"` in `package.json` and a `compilerOptions.moduleResolution` of `Node16` or `NodeNext` in `tsconfig.json`, running `tsc` will yield errors like the following:
```
.next/types/app/[...not_found]/page.ts:1:40 - error TS2307: Cannot find module 'next/dist/lib/metadata/types/metadata-interface' or its corresponding type declarations.
1 import type { ResolvingMetadata } from 'next/dist/lib/metadata/types/metadata-interface';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.next/types/app/layout.ts:2:24 - error TS2835: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean '../../../app/layout.jsx'?
2 import * as entry from '../../../app/layout'
~~~~~~~~~~~~~~~~~~~~~
.next/types/app/layout.ts:3:40 - error TS2307: Cannot find module 'next/dist/lib/metadata/types/metadata-interface' or its corresponding type declarations.
3 import type { ResolvingMetadata } from 'next/dist/lib/metadata/types/metadata-interface'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
These files are checked because of the following `tsconfig.json` line which Next.js adds:
```diff
{
"include": [
+ ".next/types/**/*.ts",
]
}
```
Adding the extensions will make it work with these projects and still maintain backwards compatibility with other TypeScript / module configurations.
### What?
This PR vendors @vercel/og and export `ImageResponse` from
`next/server`. When you render a opengraph image the below code snippets
will be legit:
```tsx
import { ImageResponse } from 'next/server'
export default function og() {
return new ImageResponse(<div style={{ width: '100%', height: '100%' }}>hello</div>)
}
```
### Why?
To make development more easier, user can directly use `@vercel/og`
Image Response with nextjs instead of install it and use it. This makes
building metadata icons, og or twitter images more convenient.
### How?
Closes NEXT-899
<!-- 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 or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### 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?
Part of WEB-736.
This PR refactors imports to turbopack to turbo-binding, as same as we
used to do with next-binding. Current next-binding in this repo doesn't
make sense anymore and removed. There are no functional changes. This'll
reducwe surface for the imports and also will make easier to run
integration test over latest turbopack.
Note swc dependency is not reflected in this PR yet - following PR will
update those imports.
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 or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### 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?
This PR fixes the issue where `next-types-plugin`'s typeguard files include unused imports, which was introduced by #47185 and might be problematic with certain configuration.
### Why?
We don't need `ResolvingMetadata` when `options.type` is `'route'` and `NextRequest` when `options.type` is `'page'`/`'layout'`, and so caused the issue.
### How?
Simply check whether `options.type` is `'route'` or `'page'`/`'layout'`.
Fixes#47646
This PR removes usage of `appPaths` in favor of `hasAppDir` to avoid the
issue where export does not read app manifest.
Fixes the error:
```
TypeError: Cannot read properties of undefined (reading 'cssModules')
```
fix NEXT-885 ([link](https://linear.app/vercel/issue/NEXT-885))
Previously the app route handler was included in the server bundle, and called into user code to execute the underlying handler logic. This PR serves to move the handler code into the bundle so that the Node.js environment more closely matches the Edge environment.
This also updates the Rust code for the new loader.
fix NEXT-712 ([link](https://linear.app/vercel/issue/NEXT-712))
Also refactors the `Errors` state into a reducer, which makes things a bit easier to reason about (in my opinion)
I tried adding an ID to the issue, so we don't have to stringify the whole issue, but unfortunately that duplicates (parsing issues)
the reason is probably that files get parsed twice, once for the client and once for the server side
### What?
- Besides existing `Metadata` type, expose `ResolvingMetadata` and `ResolvedMetadata` to `'next'`.
- Group `Robots` / `Sitemap` / `Manifest` these dynamic data routes types as `MetadataRoute` type and expose to `'next'`
### Why?
Allow users to type the more API easily, and grouping them to avoid type conflicts (e.g. we have `Robots` in metadata interface field, `MetadataRoute.Robots` can avoid conflicts)
### How?
Closes NEXT-908
### What?
Fix robots.txt generation
### Why?
Should support multiple allow/disallow rules, they should be generated in different lines
### How?
Closes NEXT-905
Fixes#47224
fix NEXT-905 ([link](https://linear.app/vercel/issue/NEXT-905))
