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))
### 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))
In #47328 we made the root level `/not-found.js` a special entry, to
override the page 404 during builds. However, it's possible that the
user has a valid `/not-found/page.js` route that might conflict with
this special entry. This PR changes the entry to be `/_not-found` so it
will never conflict with existing valid entries.
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.
fix NEXT-712 ([link](https://linear.app/vercel/issue/NEXT-712))
Previously to this PR, if an absolute path contained an `_` it would
ignore all app files. If for example the Next.js app was in a folder
named `/some/_directory` then today:
```
/some/_directory/app/page.js <- should 200, currently 404
/some/_directory/app/route.js <- should 200, currently 404
/some/_directory/app/_internal/route.js <- should 404, currently 200 in development
```
This also enables the same `_` functionality for app routes in
development. After this PR, we get:
```
/some/_directory/app/page.js <- 200
/some/_directory/app/route.js <- 200
/some/_directory/app/_internal/route.js <- 404
```
Adding OpenBSD and NetBSD platforms
Fixes: #44058
Probably needs more review I tried compiling the codebase as instructed
with pnpm
[here](https://github.com/dante-robinson/next.js/blob/canary/contributing/core/developing.md),
but turbo (a dependency of pnpm) has no BSD binary so I can't compile
the code on OpenBSD to test it however @gjskha mentioned in the issue he
added openbsd as a platform to get it working so in theory this change
should work and shouldn't break anything.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Currently in a client boundary file, we only explicitly export
individual fields in ESM (`export foo`) when the source type is
`module`. However in most of the time SWC gives the `auto` source type.
This PR improves the type detection a bit so if it's `auto` and we do
see ESM exports collected, we assume it's ESM and re-export these
fields.
Fixes#41940, fix NEXT-796
([link](https://linear.app/vercel/issue/NEXT-796)).
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Previously `next-swc` had relay transform inline, but it makes
maintenance harder. So this PR patches next-swc to use relay plugin from
`swc-project/plugins` repository.
Closes WEB-782
Fixes#47239
fix NEXT-883 ([link](https://linear.app/vercel/issue/NEXT-883))
### What?
Adds a warning when `useSearchParams` deopts the entire page to
client-side rendering.
When there is no Suspense boundary the entire page becomes client-side
rendered, you can learn more about that here:
https://beta.nextjs.org/docs/api-reference/use-search-params#static-rendering
### Why?
We've seen a few cases where people accidentally deopt the entire page
by calling `useSearchParams` as there was no indicator that this deopt
happened.
### How?
When the full page deopt happens the error is caught by the rendering
code so we warn there.
Closes NEXT-589
<!-- 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 #
-->
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 adds next-types-plugin's support for Route Handlers.
### Why?
Since `route.js` is somewhat like `page.js` and `layout.js`, I find it to be necessary that we also enable TS checks for these files as well.
### How?
Just changing the `createTypeGuardFile` function a bit and adding a few new tests, yeah.
More cleanup flowing out of the removal of the `target` option.
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Ensures `useParams` can be called in `pages`. In that case it returns
`null` similar to other navigation hooks that can't be backported.
### Why?
When migrating you can have components that are rendered in both `app`
and `pages`.
### How?
Uses the same approach as `useSearchParams` and `usePathname`. Type is
added to `navigation.d.ts` that overrides `next/navigation` only when
`pages` exist, that way applications built entirely on `app` don't get
the `null` type.
<!-- 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 #
-->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Removes `head.js` file convention in favor of built-in SEO support through `metadata`: https://beta.nextjs.org/docs/guides/seo
### Why?
The `head.js` convention was superseded by the built-in SEO support which is designed specifically for Server Components.
### How?
Removed the `head.js` handling in app-loader and the tests for it.
fix NEXT-812 ([link](https://linear.app/vercel/issue/NEXT-812))
### What?
This PR is another part of making parallel routes viable!
- enables some of the tests, partially only in dev (build fails because
the intersection routes are not implemented)
- introduces a new type of special file: a `default` file that can be
added to any segment, next to `page` etc, that will act as the
default/placeholder when a layout does not match
- this also fixes bugs when navigating within parallel routes
### Why?
### How?
<!-- 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 #
-->
fix NEXT-748 ([link](https://linear.app/vercel/issue/NEXT-748))
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Fixes issue with app directory that caused problems with `i18n` was
enabled. Previously, when you accessed a URL like `/blog/first-issue`,
you would expect it to hit the app route at `/app/blog/[slug]/page.tsx`,
but instead it internally attempted to access
`/app/{defaultLocale}/blog/[slug]/page.tsx` (where `{defaultLocale}` is
set in `next.config.js` via `i18n.defaultLocale`). This is because while
the path did not assume the locale, the domain/default was enough to
suggest it, causing the mismatch.
This adds a new internal parameter for tracking this _default_
assignment so it can be handled by the matcher correctly.
Fixes#46814Fixes#46841
fix NEXT-777 ([link](https://linear.app/vercel/issue/NEXT-777))
fix NEXT-834 ([link](https://linear.app/vercel/issue/NEXT-834))
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Revert some code in #47379 and finalize HOC support. We should require
the HOC to return a "use server" function, so there's no need to compile
the function call specially now.
To make that wrapping logic work, we need to allow passing a server
reference to another server reference. This usually happens in the
function closure in the HOC case, but ideally it's also allowed to
directly pass it as an argument. This requires adding React server DOM's
`encodeReply` and `decodeReply` and other corresponding changes,
including adding `busboy` (can probably be vendored?) as we need to
parse the multipart body now.
fix NEXT-808 ([link](https://linear.app/vercel/issue/NEXT-808))
([link](https://linear.app/vercel/issue/NEXT-808))
### What?
In `app` all directories starting with `_` are now considered private
and won't be routed.
E.g. `app/_components/page.js` -> does not route
If you want to have a route starting with an underscore like
`/_settings` you can use `%5F` which is the url encode version of `_`:
`app/%5Fsettings/page.js`-> does route
### Why?
Ensures that you can create directories that will never conflict with
Next.js internal naming. E.g. when additional conventions are added for
file names.
### How?
It's a bit more involved than you might expected:
- build
- While resolving entries by traversing `app` parts with `_` are ignored
- While normalizing entires `%5F` is replaced with `_`
- I've changed one case that was relying on the entry name for resolving
to use the full path to the file instead.
- dev
- Ignored paths with underscore from being generated as part of the
initial scan of the filesystem
- Updated development and production the route matcher to replace `%5F`
with `_` so that it matches the right path.
fix NEXT-798 ([link](https://linear.app/vercel/issue/NEXT-798))
([link](https://linear.app/vercel/issue/NEXT-798))
<!--
## 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 #
-->
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
introduce a new hook `useReportWebVitals` that would register a function to handle web-vitals metrics.
### Why?
next.js users who use [Axiom](https://axiom.co) has been [asking](https://github.com/axiomhq/next-axiom/issues/109) for this feature for nextjs 13, as it was working for nextjs 12.
This ensures we only honor cache entries from the in memory cache for up
to 2 seconds so that revalidates can correctly propagate and also
increases max fetch cache entry size to 2 MB. The `fetchCache` export is
also being detected in this PR but not yet honored which will be done in
a follow-up.
* Add `contenthash` as query (`?<hash>`) for dynamic image and icon
routes as well.
* Merge the metadata image info extration into 1 single loader, dynamic
and static image route will all pass through
`next-metadata-image-loader` to extract the image info such as size,
content type, etc.
* Applying same cache header from `@vercel/og`, for development we use
"no cache" header, for production, we use "long cache" header
Closes NEXT-882
This avoids the case that one can accidentally return a `Response` object in the Node.js runtime in `pages/api/`, that causes the request to hang forever.
This PR ensures the correct output is emitted during `next build` and
deprecates `next export`.
The `output: export` configuration tells it to emit exported html and
the `distDir: out` configures the output directory.
```js
module.exports = {
output: 'export',
distDir: 'out',
}
```
fix NEXT-868 ([link](https://linear.app/vercel/issue/NEXT-868))
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR refactors the types plugin a bit and adds support for optional match groups in rewrites and redirects:
```js
source: '/redirect(/v1)?/guides/:param/page'
```
Which will be created as two rules:
```ts
| `/redirect/guides/${SafeSlug<T>}/page`
| `/redirect/v1/guides/${SafeSlug<T>}/page`
```
fix NEXT-875 ([link](https://linear.app/vercel/issue/NEXT-875))
This PR continues the work of #45867, that treats the root-level `not-found.js` file inside app dir as the global 404 page, if it exists. Previously, it fallbacks to the /404 route inside pages (and the default one if `404.js` isn't specified).
In the implementation, we include `/not-found` in `appPaths` during the build, and treat it as the special `/404` path during pre-rendering. In the renderer, if the `/404` pathname is being handled, we always render the not found boundary.
And finally inside the server, we check if `/not-found` exists before picking up the `/404` component.
A deployed example: https://not-found-shuding1.vercel.app/balasdkjfaklsdf
fix NEXT-463 ([link](https://linear.app/vercel/issue/NEXT-463))
Default tags of `charset` and `viewport` should also be rendered in app
router error pages like not found pages.
Closes NEXT-869
This PR:
* Extract not found boundary to single component
* Add the default tags to `NotFoundErrorBoundary` rendering
* Fix duplicated `noindex` tag for streaming error rendering
This ensures the build spinner is correctly stopped in a TTY environment
and also adds regression tests for `app` and `pages` to ensure this
behaves as expected.
This updates our docker image to use the `jammy` tag instead of `focal`
to match the Ubuntu version to our CI.
Reverts vercel/next.js#47372
```
Error occurred prerendering page "/apple-icon". Read more: https://nextjs.org/docs/messages/prerender-error
Error: The `ImageResponse` API is not supported in this runtime, use the `unstable_createNodejsStream` API instead or switch to the Vercel Edge Runtime.
at new ImageResponse (/tmp/next-install-db63e2a2f25e9feda48affa69456fcbdde8d89bf94645e42abd2aa522224f432/.next/server/chunks/558.js:26416:19)
at appleIcon (/tmp/next-install-db63e2a2f25e9feda48affa69456fcbdde8d89bf94645e42abd2aa522224f432/.next/server/app/apple-icon/route.js:127:12)
```
https://github.com/vercel/next.js/actions/runs/4490842502/jobs/7899302486#step:6:305
Allow image responses returning from dynamic image routes for og/twitter
images, and icon/apple-icon images. This PR supports the basic
functionalities for nodejs runtime of image routes. `@vercel/og` is able
to be leveraged for generating dynamic image responses.
Close NEXT-264
Close NEXT-266
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
- Move span wrapping rendering closer to the user code and don't add
span when we have cache-hit
- Add `getStaticProps` span
- Add spans around API handlers (pages and app)
- Add `generateMetadata` span
- Clarify naming that we use `page` for entrypoints like
`/path/[param]/page` or `/path/[param]/layout`. And `route` for
`/path/[param]`
fix NEXT-857 ([link](https://linear.app/vercel/issue/NEXT-857))
### What?
Adds `useParams` to read the canonical parameters.
```tsx
'use client'
import { useParams } from 'next/navigation'
export default function Page() {
const { id } = useParams()
return (
<div>
<div id="param-id">{id}</div>
</div>
)
}
```
### Why?
Allows for accessing segment parameters for the entire page.
### How?
It uses a similar resolving of `useSelectedLayoutSegments` which resolve `children` and if `children` is not available the first available parallel route instead.
Closes NEXT-99
### What?
Adds the error boundary used to catch `redirect()` above the root
layout.
### Why?
Currently calling `redirect()` in the root layout causes `NEXT_REDIRECT`
to bubble up to the error boundary because we didn't have a
redirect-boundary above the place where the root layout is rendered
client-side.
### How?
- Moved redirect-boundary into a separate file
- Added redirect-boundary around the `cache.subTreeData` in app-router
(around the root layout)
fix NEXT-315 ([link](https://linear.app/vercel/issue/NEXT-315))
Fixes#42556
I've verified the reproduction shown in #42556 has been fixed earlier,
there was another report about calling `redirect()` in the root layout
and that's what this PR fixes.
Since that issue has many comments here's some additional context:
- `redirect()` can only be called during React component rendering.
- This means you can't run `redirect()` in `onClick` or `useEffect()`
handlers.
- Calling `redirect()` in a server component or during prerendering of
client components it will add the right meta tag to trigger a redirect
- `<meta httpEquiv="refresh" content={`0;url=${redirectUrl}`}>`
- Because of streaming rendering by the time your code runs the browser
will have already received the start of the stream and headers will have
been sent, as such you can't modify the headers, hence why the meta tag
is used instead of `location`.
- Calling `redirect()` in client components is supported while
rendering, e.g. if you have a condition:
```tsx
'use client'
import { useState } from 'react'
import { redirect } from 'next/navigation'
export function ClientComponent() {
const [clicked, setClicked] = useState()
if(clicked) {
redirect('/another-page')
}
return <>
<button onClick={() => setClicked(true)}>Click to redirect</button>
</>
}
```
<!-- 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 #
-->
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Currently, the client entry loader creates the code of `import {
createProxy } from "private-next-rsc-mod-ref-proxy"` and then we alias
it to the target file. This process is redundant and risky. If the
loader-created code is somehow marked as external (due to the effect of
both our complex external handling and `transpilePackages`), that alias
can't be correctly resolved.
Hence this PR simplifies it by creating the target import path directly
from the loader.
**Note that in the future we should change it directly on the SWC side,
and convert this loader to Rust.**
The `exportPathMap` feature has been unofficially deprecated for a long time since introducing `getStaticPaths()`.
For the `app` dir, the same can be accomplished with `generateStaticParams()`.
This PR adds a pretty error when using `exportPathMap` with `app` and updates documentation to reflect the current status.
fix NEXT-836 ([link](https://linear.app/vercel/issue/NEXT-836))
This marks all pages in development as supporting dynamic HTML. Detection for runtime violations of dynamic generation is completed during the production build.
Fixes#46356
fix NEXT-644 ([link](https://linear.app/vercel/issue/NEXT-644))
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
When using a "use server" module, only exporting async functions is
permitted. However, since we cannot perform static analysis on all
exported value types (e.g., `export const foo = condition ? A : B`), we
have added a runtime ensure function to validate that these are indeed
valid functions.
By implementing this, we can prevent any strange errors like "Can't
access $$typeof of undefined or null" that may arise when exporting
`undefined` or `null` from a server entry. Moreover, this measure helps
avoid any potential mistakes that may occur.
fix NEXT-865 ([link](https://linear.app/vercel/issue/NEXT-865))
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
We shouldn't detect icon/og/etc. metadata image convention as image dynamic routes under `pages/` dir, they should be only apply in `app/` dir. This PR changed the normalization rule that we only apply them when page is from `app/`. So when you're using `icon.js` under `pages/` it won't get effected.
We introduced static route `robots.txt` and dynamic route `robots.js` for metadata, it should still allow users to create their own customized version. This issue is caused by a route conflicts. Only append `/route` to page path when there's not ending with `/route`
Fixes#47198
Closes NEXT-850
- I noticed that on parallel routes, we kept refetching all the time the tree
- this was caused by the HMR ping interval + a mismatch on how we recreated the entrypoint path from the router state, causing the server to always invalidate the parallel route
- this fixes it to respect the format
fix NEXT-860 ([link](https://linear.app/vercel/issue/NEXT-860))
In preparation for improvements for the runtime support, this changes
the handle signature to _always_ return a response object.
fix NEXT-679 ([link](https://linear.app/vercel/issue/NEXT-679))
When a user exports a default function from a `route.ts` file, they may
think that this would be handled in the same way that our `pages/api/`
routes handled it. App Routes require an exported function for each HTTP
method instead.
This adds warnings to the development console when a user provides a
default export (or no HTTP method at all).
Future ideas:
- Error during production build when these conditions are met
fix#46375
fix NEXT-660 ([link](https://linear.app/vercel/issue/NEXT-660))
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Async functions can just be return without await.
### Why?
Is just cleaner. Not important and not crucial.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
There was a bug with supporting nested routes in the parallel routes
with named slots that made the request hang
### Why?
The request was hanging suspended on the router because the
`next-app-loader` was not finding the layout component and thus, it was
falling back to a component that returned null, tripping a bit of code
in the app router that suspended.
### How?
The fix was to fix the next-app-loader loader tree generation to account
for parallel routes
Closes NEXT-
Fixes #
<!-- 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 #
-->
fix NEXT-854 ([link](https://linear.app/vercel/issue/NEXT-854))
---------
Co-authored-by: Tim Neutkens <timneutkens@users.noreply.github.com>
**Description:**
I noticed that when a user is on a deployed next.js site, and a fresh
deployment is made, requests for ssg data fails w/ a 404. For prefetches
(hovering a link) this appears to be handled well, but when the user
actually clicks the link it wasn't being handled.
This doesn't seem to be a problem as the page still behaves as expected,
but the errors being generated are clogging sentry.
To fix this, I added a simple `.catch(() => false)` as the return value
didn't appear to be used at all.
I was able to verify that this works correctly by patching next in a
local project and deploying a few times then clicking around.
**Issues**
As far as I know there's no issue tracking this atm as I chatted w/ Tim
in slack and he was under the impression that all of the failures were
caught.
Console on page navigation before this change:
<img width="775" alt="image"
src="https://user-images.githubusercontent.com/4172067/226069042-afa3a23b-b575-4e81-8ec4-ac887e38444d.png">
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Makes searchParams part of the cache key for dynamic rendering
responses.
### Why?
Current the cache key only includes the pathname and not the
searchParams. This causes issues in a few cases:
- Navigation to `/dashboard` then clicking a link to
`/dashboard?sort=asc` works, but then when navigating back the cache
node for `/dashboard?sort=asc` is used instead of the content for
`/dashboard`.
- Navigation between different searchParams always had to be a hard
navigation as reusing a cache node would result in the wrong result.
### How?
Changed the leaf node's name from `''` to `'__PAGE__'` so that it can be
distinguished. Then used that `__PAGE__` marker to include the
searchParams into the cache key for that leaf node in all places it's
used.
Ideally the `__PAGE__` key becomes something that can't be addressed in
the pathname, since it still has to be serializable I'm thinking a
number would be best.
Given that the server just provides the cache key and the client only
reasons about rendering the tree the current approach of stringifying
the searchParams and making that part of the cache key could be replaced
with a hash of the stringified result instead.
fix NEXT-685 ([link](https://linear.app/vercel/issue/NEXT-685))
Fixes#45026
Fixes NEXT-688
Fixes#46503
- there's a warning that happens currently when compiling parallel
routes in dev because they all resolve to the same pathname and their
identity function is all the same
- I'm repurposing their identity fn to include the actual segment it's
referring to, instead of all of them
the `__next_prallelPaths` string doesn't seem to be used otherwise so I
think it's alright to rename
<!-- 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
- there's a warning that happens currently when compiling parallel
routes in dev because they all resolve to the same pathname
- 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-831
Fixes #
-->
fix NEXT-831 ([link](https://linear.app/vercel/issue/NEXT-831))
In React 18.3.0 or newer, we must user camelCase `fetchPriority` prop to avoid "Warning: Invalid DOM property".
In React 18.2.0 and older, we must use the lowercase `fetchpriority` prop to avoid "Warning: Invalid DOM property".
See https://github.com/facebook/react/pull/25927
This ensures revalidate can be fetch specific instead of cache key
specific and adds a test case to ensure config based revalidate isn't
overridden by fetch based revalidate.
* Add `manifest.webmanifest` and `manifest.(j|t)xs?` support for
manifest.json route
* Add `Manifest` type for it for autocomplete purpose.
Remove the exports for `SitemapFile` and `RobotsFile` globally, will
discuss how to re-export them with better naming later
Small fix for `Robots` typing, should allow `string | string[]` for user
agent of single Robots
Closes NEXT-839
---------
This serves to correct a specific issue related to multiple locales being specified in the pathname as well as some general i18n improvements.
- Multiple locales are now parsed correctly (only taking the first locale, treating the rest of the string as the pathname)
- `LocaleRouteNormalizer` has been split into `I18NProvider` and `LocaleRouteNormalizer` (tests added)
- Adjusted the `I18NProvider.analyze` method (previously `LocaleRouteNormalizer.match`) to require the `defaultLocale: string | undefined` to ensure consistent behaviour
- Added more comments around i18n
Resolves#39689, partially resolves#28642 (see notes below)
Inspired by #44627
In #28642 it was also asked to expose `server.headersTimeout`, but it is
probably not needed for most use cases and not implemented even in `next
start`. It was needed to change this option before
https://github.com/nodejs/node/issues/27363.
There also exists a rare bug that is described here
https://github.com/nodejs/node/pull/32329#issuecomment-614119125. To fix
this exposing `server.headersTimeout` might be required both in
`server.js` and in `next start`.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Currently all import CSS resources, including CSS modules, are imported lazily. This means that they can't be chunked as by definition of "lazy" they can be loaded separately.
This PR changes it to always use "eager" so if they're in the same entry, these CSS resources can be chunked together and reduce the total amount of requests. However the downside will be tree shaking, as not all modules in a chunk are used by one entry. Two entries can only share a part of it.
Since CSS modules won't have side effects this should be a good trade off.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Currently if `notFound()` or `redirect()` is called when the shell was already sent out, we can no longer change the status code and head tags. In that case we inject these specific meta tags into the HTML stream so specific agents can read them.
fix NEXT-220 ([link](https://linear.app/vercel/issue/NEXT-220))
Generated metadata icons through api routes instead of using webpack
emitting file. Each metadata image file will go through
`next-metadata-image-loader` to get the image basic info, and then it
will go through `next-metadata-route-loader` to be converted as a
routes.
Related to NEXT-264
Closes NEXT-810
When calling the server (via `callServer`), we concat all closure values
(`$$bound`) and arguments of the function call into one array on the
client. Hence on the server, we will have to compile the function
differently to support that.
With this change, the compiled function will have a `$$with_bound` flag
to indicate that if it accepts closure values. If so, the only argument
passed will be an array like `[...bound_values, ...fn_args]`, and we
compile the function parameters to `(closure, arg1 = closure[N], arg2 =
closure[N + 1], ...)` where `N` is the number of the closure
identifiers. This way we can still fill these arguments by only pass an
"bound + args" array. If it doesn't accept closure values, it will be
directly called with `...fn_args` so no compilation change needed.
The reason that we use `arg1 = closure[N]` is that this can support
complex patterns in parameters such as `f(closure, {a} = closure[1], [b]
= closure[2])`.
fix NEXT-487 ([link](https://linear.app/vercel/issue/NEXT-487))
In the case when the user configured `output: export` and used an API Route Handler that cannot be converted to static, Next.js must throw an error.
fix NEXT-823 ([link](https://linear.app/vercel/issue/NEXT-823))
Ensures that using `searchParams` opts into dynamic rendering.
Fixes#43077
fix NEXT-601 ([link](https://linear.app/vercel/issue/NEXT-601))
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1678838567947919)
Follow-up to https://github.com/vercel/next.js/pull/46317. The issue is
that, if:
- `experimental.clientRouterFilter` is enabled
- `i18n` is enabled with `defaultLocale` set
- Next.js router navigates to a path that (1) is the same as
`defaultLocale` and (2) will be redirected,
then:
- **Expected:** Should hard-navigate to this path without any locale
prefix (and then redirect occurs)
- **Actual:** Hard-navigates to this path with `defaultLocale` prefix,
even though it's not needed (and then redirect occurrs)
### Solution
This PR fixes the above issue by adding `defaultLocale` to `addLocale`
which is passed to `handleHardNavigation`. [`addLocale` skips adding the
locale if `locale` is equal to
`defaultLocale`](02125cf3b1/packages/next/src/shared/lib/router/utils/add-locale.ts (L17)).
### Fixing a bug
- [x] Related issues linked using `fixes #number`
- [x] Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Rename client reference plugins from `Flight*` to `ClientReference*`
* Rename `serverComponentManifest` to `clientReferenceManifest`
* Group the key/value in client reference manifest
* Update turbopack crates
fix NEXT-827 ([link](https://linear.app/vercel/issue/NEXT-827))
This aligns use of the next/font transform across the workspace under a
single crate, now called `next-transform-font`.
### What?
This PR introduces a new `--tailwind` flag to the `create-next-app` CLI,
to make it easier to bootstrap a Next.js app with Tailwind CSS
pre-configured. This is going to be the **default**. To opt-out of
Tailwind CSS, you can use the `--no-tailwind` flag.
### Why?
Tailwind CSS is one of the most popular styling solutions right now, and
we would like to make it easier to get started.
Currently, the closest you can come to this is by running `pnpm create
next-app -e with-tailwindcss` which will clone the
https://github.com/vercel/next.js/tree/canary/examples/with-tailwindcss
example. But that example is not configured for the App Router. This PR
will let you add Tailwind CSS to both `app/`, `pages/`, and start out
with TypeScript or JavaScript via the CLI prompts.
(Some community feedback
https://twitter.com/dev_jonaskaas/status/1632367991827443713,
https://twitter.com/samselikoff/status/1634662473331617794)
### How?
We are adding 4 new templates to the CLI bundle.
> Note: The styling is not pixel-perfect compared to the current
templates (using CSS modules) to require fewer overrides, but I tried to
match it as close as possible. Here are a few screenshots:
<details>
<summary><b>Current, light</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224733372-9dba86fe-9191-471d-ad9f-ab904c47f544.png"/>
</details>
<details>
<summary><b>Tailwind (new), light</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224733610-038d9d0f-634d-4b69-b5c2-a5056b56760c.png"/>
</details>
<details>
<summary><b>Current, dark, responsive</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224733790-9b4d730c-0336-4dbe-bc10-1cae1d7fd145.png"/>
</details>
<details>
<summary><b>Tailwind (new), dark, responsive</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224734375-28384bbc-2c3a-4125-8f29-c102f3b7aa1d.png"/>
</details>
#### For reviewers
This introduces 4 new templates, with a very similar code base to the
original ones. To keep the PR focused, I decided to copy over duplicate
code, but we could potentially create a shared folder for files that are
the same across templates to somewhat reduce the CLI size. Not sure if
it's worth it, let me know. Probably fine for now, but something to
consider if we are adding more permutations in the future.
---
~Work remaining:~
- [x] app+ts
- [x] layout
- [x] dark mode
- [x] media queries
- [x] animations
- [x] app+js
- [x] pages+ts
- [x] pages+js
- [x] prompt/config
- [x] deprecate Tailwind CSS example in favor of CLI
- [x] update docs
- [x] add test
- [x] add [Prettier
plugin](https://github.com/tailwindlabs/prettier-plugin-tailwindcss)
Closes NEXT-772
Related #45814, #44286
Previously when we move to metadata images to custom app routes, when the image files get imported, it matches the `next-image-loader` rule which accidentally generate a static file into media.
This PR appends the metadata reource query to the imported rerource, and then skip in the `next-metadata-route-loader` so they won't get applied by image loader or emit any unexpected assets
Ensures `router.refresh()` matches the upcoming `revalidatePath('/')`
api. This also ensures that when server context has changed it applies
to all routes, not just the one that triggered the refresh.
- When `router.refresh()` is called we fetch the full RSC payload from
the server (root layout till the page)
- The client-side router cache is fully invalidated, effectively making
it empty
- The client-side router prefetch cache is fully invalidated,
effectively making it empty
- RSC payload is applied to the state
fix NEXT-590 ([link](https://linear.app/vercel/issue/NEXT-590))
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
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 files from other directories are allowed into type `Route`.
### Why?
It is caused by the fact that `this.collectPage` only blocked files in `appDir` that are not `page.js` and `pages/`'s `_app.js`, `_document.js`,...
### How?
This fixes that by blocking files that are not in any of these directories as well.
Closes NEXT-
Fixes#47151
In short, this PR adds a 3rd layer to the server compiler. This extra
layer is for marking the modules when re-entering the server layer from
a client component. It is almost identical to the existing server layer
and it should have all the same bundling and runtime behaviors, but it's
still special because it's not allowed to enter the client layer again
from there.
Because of that, we create the extra entry for that new layer when the
client layer compilation finishes in the `finishModules` phase. The new
entry is handled normally as it's in the server layer. But the original
module in the client layer will be compiled specially as special no-op
exports, and will then be connected via the `callServer` wrapper.
fix NEXT-809 ([link](https://linear.app/vercel/issue/NEXT-809)).
This changes make sure that the `app-render` module isn't being imported
by too many unnecessary places, as we'll later move the renderer into a
worker.
Adds support for scrolling based on the [hash
fragment](https://en.wikipedia.org/wiki/URI_fragment) in client-side
navigations for the App Router, mirroring browser behavior.
- `#main-content` → scrolls to `id="main-content"` or
`name="main-content"` property
- `#top` → scrolls to the top of the page, this is a special case in
browsers.
- no hash → default scroll behavior, layout that changed
Fixes NEXT-658
<!-- 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 #
-->
fixes#44295
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This moves the position of action handling so it can continue page
rendering afterwards. And a `asNotFound` option is added to
`LayoutRouter` to indicate the router to opt into the root not-found
boundary, so not found pages can be programmatically rendered instead of
relying on route mismatching (this is also needed by NEXT-463 later).
Fixes NEXT-467.
Support top-level `robots.[ext]` and `sitemap.[ext]` with dynamic api
routes
* Use isAppRoute to determine api routes and metadata routes as metadata
routes are normalized as `<metadata>/route`
* Normalize path to auto append extension to pathname for sitemap.js and
robots.js
* Add typings `SitemapFile` and `RobotsFile`
* move the normalize logic together, reuse the `absolutePathToPage`.
Changes less when touching both dev-server/hot-reloader and next-server,
use the same utils to handle paths
Closes NEXT-262
---------
Fixes#46974
When `dynamicRouteTypes` or `staticRouteTypes` is empty, type `DynamicRoutes`/`StaticRoutes` fallbacks to type `string`, causing type `Route` to resolve to type `string` as well, meaning that the user can use any string as `href`. This fixes that by making those types fallback to type `never` instead, and if both `dynamicRouteTypes` and `staticRouteTypes` are empty, fallback to type `string`.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Not certainly sure about the reasonable limitation of this header. For example https://app-dir.vercel.app/context/books sends a state query of size ~110, consider an app with 100x more complicated nested, parallel and named segments, we still have a 3x extra room which should be enough.
Fixes NEXT-137.
This PR implements the route announcer for app directory. It almost uses
the same logic as the route announcer inside pages, with one notable
difference that the inner content node is now inside a shadow root. This
makes sure that it does as little impact as possible, to the
application. This is important as we no longer have the `__next`
wrapper.
Another thing worth mentioning is that the announced title is a global
singleton of the website. It shouldn't be affected by the concept of
layouts, but should be triggered when the router state (not just URL)
changes.
Closes NEXT-208.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR does two major changes:
1. Make sure both pages renderer and app renderer return `RenderResult`,
no more `null`. This was achieved with a new `null` type in the
constructor `new RenderResult(null)`, and a `.isNull()` method.
2. Remove all mutations of the `renderOpts` object inside renderers. To
pass extra information out, they need to be attached to the
`RenderResult` now. This also requires 1) to be done.
These changes are the initial steps to the isolated rendering worker
architecture. Besides those there're also some type improvements.
Fixes NEXT-807.
---------
Fixes#39330.
I've not added a new test, but extended the existing test instead (and
re-enabled it).
It seems to me that a custom next/image config was not considered during
static generation (which itself uses `next export`?) before. Adding the
config to `renderOpts` in `packages/next/src/export/index.ts` resolves
the issue.
### Fixing a bug
When a timeout occurs the `handleDisconnect` can be called twice on my
machine (Chrome 110.0.5481.178). Once by the timeout code, and once by
the `onerror` handler, possibly triggered by the `source.close()` call.
This leads to every timeout triggering twice as many clients, which
quickly explodes to websocket reconnections spamming the network tab of
devtools. This trivial fix resolves the issue.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Set the output bundle file path to `/<metadata route>/route.js` to align with other custom app routes, in order to make it easier being handled by app routes in both nextjs and vercel
`mdx-bundler` is used for server-side transformation of MDX files and currently using it within server components will throw a `Module parse failed: Unexpected token` error.
Adding `serverComponentsExternalPackages: ['mdx-bundler']` to `next.config.js` fixes the issue, but it's probably good to add to the default exclusion list as `mdx-bundler` is a relatively popular approach for using MDX in Next.js apps.
fixes#46893
### What?
fixing compile issue reguarding the dompurify package.
### Why?
To allow the usage of dompurify
### How?
Added jsdom and canvas to the external packages list which are used by dompurify and throw errors if not added to this list.
Generate `/favicon.ico` route when favicon.ico is placed into `app/`.
Still collect favicon metadata image information through
metadata-image-loader but don't emit the file to static dist anymore.
Also collect favicon through metadata routes, and render it as static
routes. Also remove the `hash` we generated before, not needed anymore.
Change metadata static routes rendering process: collect static metadata
assets, read the buffer of the file data and return it in the response.
Closes NEXT-791
This PR adds Zod to the precompiled libraries, and use it to create schemas for the router state tree for validation. In other planned features/changes, Zod will also be used to do run-time data validation.
Fixes NEXT-135.
<!--
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:
-->
## Bug
fix#46948
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: Seiry Yu <seiry@squareup.com>
Support top level static `robots.txt` and `sitemap.xml` as metadata
route in app directory. When those files are placed in top root
directory
Refactored a bit the page files matching logic, to reuse it between dev
server and build
Closes NEXT-267
`test/development/acceptance-app/hydration-error.test.ts` has a lot of tests because I ported all the tests in https://github.com/facebook/react/blob/main/packages/react-dom/src/__tests__/ReactDOMHydrationDiff-test.js. Running all those tests takes a lot of time, and to include all the different cases is overkill.
This PR removes most tests but keeps one test case per type of hydration error, and also one using suspense. This makes more sense, it should only test that all the different hydration error messages are picked up.
This ensures we leverage the fetch cache when calling
`generateStaticParams` and also ensures paths with
`generateStaticParams` without `dynamicParams = false` don't error when
only partial params are provided.
x-ref: [slack
thread](https://vercel.slack.com/archives/C035J346QQL/p1678149362238089)
Add unique identifier `@app@` / `@pages@` / `@root@` for entry key of on
demand entries, so that they'll be unique for each path when the page
key is similar bewteen app and pages like (`"app/page"` and
`"pages/page"` will both end up with `/page`)
## Bug
Follow up for #46736
Closes NEXT-472
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
---------
This updates to no longer skip caching POST or authed requests with the
fetch cache and instead we bail when `cookies()` or `headers()` is used
prior which is a better heuristic to signal user specific data would be
related to the fetch request.
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1678130069138849)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
This PR makes `typedRoutes` stricter by constraining generics in `Route` to type string. I've also made generating types for routes a bit more efficient by moving `redirects` and `rewrites`'s processing to the plugin's constructor since `rewrites` and `redirects` don't change in both dev and prod.
I've also been trying to fix a bug where route types doesn't generate all the routes (some appear, some don't), but I've got no clues since that doesn't seem easy to reproduce (perhaps it only happens in my case?)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Since we have 2 server compilers (node and edge), the `serverActions`
object will always get overridden by the second compilation during `next
build`. Like the client reference manifest, we need to have 2 objects
for each compiler and merge them when outputting the asset.
Besides that, to avoid `export default` being tree-shaken as unused
export, I changed the loader to use CJS `module.exports` instead. Can't
easily figure out a proper way for now but we plan to create separate
worker for the action endpoint and this will be gone then.
Fixes NEXT-759, read NEXT-761 for the full future plan.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Fixes#43605
Fixes NEXT-325
Fixes NEXT-193
This ensures that when the `fetch()` for the RSC payload gets redirected
server-side to a URL that fails CORS (e.g. an external url). This
catches the error and returns the url that was fetches to be
hard-navigated. This also covers other cases like when the host can't be
reached.
Added a note to add a test for this later as it depends on having a
deployment without CORS.
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
## Background
In the early days, `next export` was created when Next.js was SSR-only in order to statically export your pages for self hosting where no server was available. However, around the time `getStaticProps()` and `getStaticPaths()` were introduced, Next.js began [automatically generating static pages](https://nextjs.org/docs/advanced-features/automatic-static-optimization) (SSG first and SSR opt-in) during `next build`. This meant there were very few reasons to use `next export` and it started to become a stale feature.
## Problem We Need To Solve
Users targeting `next export` currently have a really bad experience. They start a new project and use all the features Next.js has to offer because they all features work with `next dev`. Then when development is finished and it comes time to deploy, running `next build && next export` will fail with errors for [unsupported features](https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features).
## Solution
This PR introduces a new configuration option, `output: 'export'`, to indicate that the user intends to run `next export`.
With this change, Next.js can fail fast during `next dev` if any [unsupported features](https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features) are used, thereby improving developer experience with instant feedback.
```js
/**
* @type {import('next').NextConfig}
*/
const nextConfig = {
output: 'export',
}
module.exports = nextConfig
```
Similar to #46328 but with `hasServerComponents: false` for the compiler
so RSC syntax constrains don't apply here.
Note that since we don’t bundle external modules in API routes, we can't
resolve to `react-server` so that one will be tricky.
Fixes NEXT-625
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Related NEXT-472
When you have `app/page.js` and `pages/page.js`, the `pagePath` are the
same, which is `/page`. This will result require cache conflicts. When
you visit the `app/` page first, then the `pages/` page, the 2nd request
will still get the app dir page module, which result in server error.
Solution: use different cache key of pagePathCache for pages/ and 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:
-->
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
For requests made via the edge runtime, they will not contain the
`originalRequest` object used by the request storage to enable
headers/cookie access. This uses the request object passed when in the
edge runtime.
Love the change made in #46666! This PR tries to refactor it by adding
an abstraction `pluginState` object. For the build process, it's just a
serializable field that we can attach to the result and resume it as the
state at the process beginning. For Webpack plugins, it's an object with
all the needed states and their initial values.
The proxy is for lazily initializing these states so they're still
global variables, but always initialized after the worker resumes the
plugin state.
This way we no longer need to import these plugins from the build
worker, and mutate each module export field:
`Object.assign((flightPluginModule as any)[field], (serializedFlightMaps
as any)[field])`.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Since it's perfectly valid to do an authorized request during revalidate we shouldn't consider this a reason to throw the static to dynamic error during runtime. If an authorized request is done during build and caching isn't enabled for a path it will still bail from being turned into a Prerender.
x-ref: [slack thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1677734108126679)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
This updates our experimental `webpackBuildWorker` config to use
separate process for each compilation to reduce memory usage building up
from all compilers sharing same process.
x-ref: [slack thread](https://vercel.slack.com/archives/C04S835KUC9)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
fixes#46611
this PR fixed customer dist type(`distDir` option in next.config.js) in
`tsconfig.json` will be a hard coded absolute path issue which is a bug
from PR #46249
since dist type only be added when user using app dir, to reproduce this
issue you need to make `app dir` toggle on and add a `distDir` option in
`next.config.js` file
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
---------
<!--
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:
-->
# Description
fixes#31159fixes#44553
Path aliases defined in `tsconfig.json` or `jsconfig.json` are not
automatically configured to work with Jest. This means that these
aliases have to be defined in multiple places.
This PR configures the SWC Jest transform to handle the `baseUrl` and
`paths`, so that users don't need to configure a `moduleNameMapper` for
Jest.
~This PR intends to make the experience more seamless by automatically
configuring Jest's `moduleNameMapper` and `moduleDirectories` based on
the settings in a project's `tsconfig`/`jsconfig`.~
~Users will be able to supply their own configuration for these fields,
if they have use-cases that require manual configuration.~
~The implementation is taken from the [`paths-to-module-name-mapper`
function in
`ts-jest`](5a0880add0/src/config/paths-to-module-name-mapper.ts).~
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [x] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
This implements middleware support for Turbopack's route resolver. In
https://github.com/vercel/turbo/pull/3930, I'm updating the data that we
pass to include a new `MiddlewareConfig`, which includes the files
needed for invoking the edge function and the matchers extracted from
the middleware's static `export config = {}`.
~~This needs to wait for https://github.com/vercel/turbo/pull/3930 to
land first~~ Merged.
Fixes https://linear.app/vercel/issue/WEB-624
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!--
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:
-->
Cleaned up duplicate code around async storage. Also fixed some types:
- Changed `supportsDynamicHTML: boolean`
- Changed `revalidate: false | number | undefined`
