Like #53880 did for `next dev`, this adds support to `next build` to
send a high-level subset of the next trace to a remote endpoint. This
can contain sensitive information, and it is **opt-in** and must be
provided when `next build` is invoked.
If a forwarded server action redirects, don't attempt to follow the
redirect as it can lead to errors. For example, if the forwarded request
followed a redirect to the same URL and had to forward the request
again, it'd hit a loop. The redirect will be handled by the
`X-Action-Redirect` which will be set when the forwarded action hits the
`createRedirectRenderResult` case.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3243
### What
- closes#65052
Emitting warning itself is correct, however
- we emit warning multiple times
- missing additional detail to provide link to the docs
PR fixes those 2.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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?
When pages are rendered using partial prerendering (PPR), they can
easily trigger cases that attempt to interrupt static rendering. If a
user calls `fetch` from within a `unstable_cache` callback with `cache:
"no-store"`, we currently break out, as that fetch operation is called
within a cached callback.
### Why?
Without this change, using `unstable_cache` would have limited affect
when dealing with external code that explicitly sets `cache: "no-store"`
preventing it from utilizing the user-specified-cache.
### How?
This modifies the fetch patching so it doesn't bail static rendering due
to dynamic fetches within an `unstable_cache` callback.
Closes NEXT-3220
Critters uses the `info` logLevel by default. This means that when you
enable the experimental `optimizeCss` property, your production logs
will be polluted with their logs
This sets the log level to warn by default in production, and allows
configuration via an environment variable
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
A common pattern for parallel routes is breadcrumbs. For example, if I
have a lot of dynamic pages, and I want to render a parallel route that
renders as a breadcrumb to enumerate those dynamic params, intuitively
I'd reach for something like `app/@slot/[...allTheThings]/page.tsx`.
Currently however, `[...allTheThings]` would only match params to a
corresponding `app/[allTheThings]/page.tsx`. This makes it difficult to
build the breadcrumbs use-case unless you re-create every single dynamic
page in the parallel route as well.
This adds handling to provide unmatched catch-all routes with all of the
params that are known. For example, if I was on
`/app/[artist]/[album]/[track]`, and I visited `/zack/greatest-hits/1`,
the parallel `@slot` params would receive: `{ allTheThings: ['zack',
'greatest-hits', '1'] }`
Fixes#62539
Closes NEXT-3230
## What?
Ensures paths that have spaces in them in `NODE_OPTIONS` are handled. An
example of that is VS Code's debugger which adds:
```
--require "/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/bootloader.js"
```
Currently the output is cut off and causes: `invalid value for
NODE_OPTIONS (unterminated string)`.
Related issue: https://github.com/vercel/next.js/issues/63740
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3226
---------
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
Co-authored-by: Ethan Arrowood <ethan@arrowood.dev>
### What
Cookies set/updated/removed in middleware won't be accessible during the
render in which they were set
### Why
Middleware will properly set a `set-cookie` header to inform the client
of the cookie change, but this means the `AsyncLocalStorage` context
containing the cookies value wouldn't be updated until the next time the
request headers were parsed. In other words, on the first request the
cookie would be sent but wouldn't be available in the `cookies()`
context. And then the following request would properly have the cookie
values.
### How
This uses a proxy on the `ResponseCookies` used in middleware to add a
middleware override header with the cookie value. When we instantiate
the cached cookies, we merge in whatever headers would have been set by
middleware, so that they're available in the same render that invoked
middleware.
### Test Plan
This changeset adds a test to confirm cookies set/deleted in middleware
are available in a single pass. Verified with a deployment
[here](https://vtest314-e2e-tests-ldx7olfl1-ztanner.vercel.app/rsc-cookies).
Fixes#49442
Closes NEXT-1126
This PR adds a new `experimental-test` command to Next.js CLI.
It has 3 main functions:
- auto installing missing playwright dependencies
- auto generating missing playwright config
- running tests via `playwright test`
I'm currently working on sharing a public RFC that will have more
information. I will link that here when its available.
Closes NEXT-3076 NEXT-3032
---------
Co-authored-by: samcx <sam@vercel.com>
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
This is related to the issue I encountered at
https://github.com/vercel/next.js/issues/63492.
The same problem from the issue exists in the App router and requires
this additional configuration (otherwise, users must manually add
`isolated-vm` (https://github.com/laverdet/isolated-vm) to their
`experimental.serverComponentsExternalPackages`).
Given how popular this package is, and based on a suggestion from
@feedthejim that I add this entry, I decided to raise this PR.
### Adding a feature
- Related issues/discussions are linked using `fixes #number`: yes
- Documentation added: yes
### What?
Add support to import attributes.
### Why?
The old import assertions syntax is deprecated and the proposal is
updated. See https://github.com/babel/babel/pull/15536
### How?
Add support to import attributes and keep old import assertions working
by using `@babel/plugin-syntax-import-attributes` with the
`deprecatedAssertSyntax` option.
Docs: https://babeljs.io/docs/babel-plugin-syntax-import-attributes
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Steven <steven@ceriously.com>
### What
The "auto" prefetching behavior differs between dev/prod, resulting in
confusing DX when configuring `experimental.staleTimes = { static: 0,
dynamic: 0 }`.
### Why
Prefetching is intentionally disabled in dev, but we still will create
an "auto" prefetch on navigation. When configuring
`experimental.staleTimes` to have a `0` value in both static/dynamic
cases (a pattern that isn't a good idea, but should still have
consistent DX), it means that any auto prefetching that happens is
effectively discarded immediately, as we also would also not be able to
re-use the loading data.
In prod, we would have created a "temporary" prefetch for this case,
which is effectively not a prefetch at all and gets the full RSC data.
However in dev, we've special-cased these prefetches to be "auto", so
the client won't ever receive fresh data after the first time the cache
is seeded.
### How
This removes the special-handling for dev to instead be similar to other
prefetches that are created ad-hoc, and marks it as a "temporary"
prefetch kind. This has the added benefit of not triggering 2 separate
RSC calls in dev when only one is really needed.
### Test Plan
Client cache tests were previously disabled in dev because caching
behavior does intentionally differ between dev/prod. But we can at the
very least assert that the "auto" prefetching behavior is consistent
between the two environments, so that's what has been added to the tests
here.
This also adds a test for the `experimental.staleTimes = { static: 0,
dynamic: 0 }` case.
x-ref:
https://github.com/vercel/next.js/discussions/54075#discussioncomment-9202650
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3209
This change allows disabling automatic `npm install`(or other supported
package managers).
Installing NextJS dependencies takes a long time and results in 0.5GB on
disk inside `node_modules`, it's not always what you want as sometimes
it's useful to delay dependency installation to a later time.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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?
Before: 25.71s
After: 11.05s (-57%)
## How?
Currently the system for isolation looks like this:
- Copy `packages` folder to an isolated directory
- Run `pnpm pack` for all folders in `packages`
- Collect the pack files, add them as `dependencies` in package.json of
the isolated application
- Run `pnpm install`
Because the `next-swc` (Turbopack + SWC, yes we still need to rename the
package) binary file is quite large in development (900MB+) it means we
have to copy, then zip (pnpm pack), then unzip (pnpm install) that
binary, which takes about 3+ seconds in each step.
The change in this PR is to skip the copy/zip/unzip completely by
providing the folder path for the binary directly to Next.js, as it's a
binary we don't need the special isolation for this, it's already
standalone so running it directly allows us to skip 14,6 seconds of work
that is required for each isolated test in development.
This will likely have little effect on CI times as we already do some
tricks like only running the packing at the start of the CI process.
Only thing that could be better and is probably worth doing is adopting
this change for the time it saves for unzipping, that's almost 4 seconds
per test still.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3200
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Add a validation for parallel routes with the same path.
This PR enables
`test/e2e/app-dir/conflicting-page-segments/conflicting-page-segments.test.ts`
### Why?
To match the behavior in the default mode.
### How?
Closes PACK-2912
We currently have logic spread in multiple places that normalize `nxtP`
parameters into their regular names, ie `nxtPfoo` -> `foo`. However we
don't apply this same logic to `nxtI`, which conceptually is another
parameter but for route interception. As a result, the interception
route would 404 when deployed because it'd be missing the interception
parameter.
This moves the normalization check into a util and updates the spots I
could find where we handle `nxtP` to also handle `nxtI`.
### Test Plan
Added a new test, and validated via these deploys:
**Working**:
[Link](https://vtest314-e2e-tests-m889gxi4p-vtest314-ijjk-testing.vercel.app/)
**Non-Working**:
[Link](https://vtest314-e2e-tests-8sa5t9uau-vtest314-ijjk-testing.vercel.app/)
Fixes#62207
Closes NEXT-3204
### What
Apply the react aliases for app dir also to the files with
`pagesExtension`
### Why
In the page bundle of mdx page:
In RSC layer react is referencing to the insatlled react 18.2.0 's
`jsx-runtime` to create each JSX element. The react 18.2 JSX runtime
access `propTypes` of the component type and then it crashes 💥
In RSC layer it should use the built-in react canary's `jsx-runtime`.
The reason that it didn't use the built-in one is we're using customized
`pageExtension` `["mdx"]` for mdx, where we didn't apply all these rules
for the files with `pageExtension`, but only the js and ts files by
default.
For mdx specifically, we cannot only applied to
`(page|layout|route).[page extension]` cause every mdx file needs to
have proper resolution. Since this doesn't break transform, it's safe to
apply for all files with page extension.
Fixes#58888
Closes NEXT-3187
### What
* Remove the change added in #64467, but still kept tests.
* Add more tests for mixed imports (component and function) from shared
component with `optimizePackageImports`
### Why
The fix in #64467 was not correct, as mixing `export *` with `"use
client"` should error if Next.js detect it properly.
When there's mixed exports, that a shared function will become a client
reference if the target file inherits the client boundary.
The original issue #64467 fixed was actually related to tree-shaking,
which is fixed in #64681.
Closes NEXT-3197
### What
- closes#63896
PR implements parsing JSValue for the matcher config if given item is an
object. We had those types already declared in place but somehow parsing
ignores it.
### What
Closes PACK-2978, requires https://github.com/vercel/turbo/pull/8005.
PR extends existing mdxRs config from accepting object as well in
addition to current boolean flag, mainly to allow to specify what kind
of markdown types will be used between gfm and commonmark.
### What
Reported by @MaxLeiter, when you mixing named import and wildcard import
to a client component, and if you clone the module it will missed others
exports except the named ones. This lead to an issue that rendered React
element type is `undefined`.
### Why
We're using a tree-shaking strategy that collects the imported
identifiers from client components on server components side. But in our
code `connection.dependency.ids` can be undefined when you're using
`import *`. So for that case we include all the exports.
In the flight client entry plugin, if we found there's named imports
that collected later, and the module is already being marked as
namespace import `*`, we merge the ids into "*", so the whole module and
all exports are respected.
Now there're few possible cases for a client component import:
During webpack build, in the outout going connections, there're
connection with empty imported ids (`[]`), cannot unable to detect the
imported ids (`['*']`) and detected named imported ids (`['a', 'b',
..]`). First two represnt to include the whole module and all exports,
but we might collect the named imports could come later than the whole
module. So if we found the existing collection already has `['*']` then
we keep using that regardless the collected named imports. This can
avoid the collected named imports cover "exports all" case, where we
will expose less exports for that collection module lead to the
undefined component error.
Closes NEXT-3177
The function we use to generate a string with named parameters to pass
into `path-to-regexp` currently doesn't properly handle non-word
characters (namely, for the purposes of this bugfix, hyphens). As a
result, `pathToRegexp` will convert something like `/foo/:bar-baz` into
`/^\/foo(?:\/([^\/#\?]+?))-baz[\/#\?]?$/i`, effectively only treating
the `:foo` as part of the regex capture group and leaving a dangling
-baz.
This means using an interception route within a dynamic segment (such as
`/foo/[bar-baz]`) would not properly trigger the route interception
Fixes#64766
### What?
I submitted PR #64499 , it got merged, but it contains a mistake.
I'm terribly sorry about this!
By removing the traceparent from the cachekey, we mistakenly removed the
header from the original object.
Causing the actual request to be executed without the traceparent
header.
### Why?
Creating a cachekey should not alter the original object.
### How?
Flip the arguments for Object.assign
---------
Co-authored-by: Jeffrey <jeffrey@jeffreyzutt.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Why?
This typo was resulting in this error in deploy.
```
Failed to get from fetch-cache TypeError: s.tags.include is not a function
```
Closes NEXT-3168
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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?
This ensures that the body limit option is enforced on all request
bodies sent to the Node.js runtime, not just the multipart field size
limits.
### Why?
The documentation states that this should limit the body size,
previously it only limited the field size.
### How?
This uses a `Transform` stream from Node.js. [Based on my
benchmarks](https://gist.github.com/wyattjoh/c470d98095da2f95f5920396aba2a206)
using the transform stream added next to no overhead, yet it did
simplify the implementation quite a bit. Assuming this is due to the
already performant stream support within Node.js.
Closes NEXT-3151
This ensures we only track fetch metrics in development mode as that's
the only time we report them currently, this also adds an upper limit on
how many metrics we store per-request as previously this was unbounded,
on top of that this ensures we don't keep tracking fetch metrics after
the request has ended as we only report on request end, and finally this
adds a clean-up to the reference we attach to the request object
containing the fetch metrics once we have used them.
Closes: https://github.com/vercel/next.js/issues/64212
Closes NEXT-3159
When a server action triggers a redirect, we're incorrectly applying a
refresh marker to the segment they were on, rather than the segment they
were being redirected to. As a result, when revalidation occurs (via
`revalidateX` or `router.refresh()`), the top-level segment would be
replaced with data for an incorrect segment.
For example, if triggering a redirect action from `/redirect` to `/`,
the router state tree would save a reference to `/redirect`. The next
time a refresh or revalidate happens, it'd refresh the segment data for
`/redirect` instead of `/`.
Fixes#64728
Closes NEXT-3156
The `@appsignal/nodejs` instrumentation package fails to load in Next.js
14 due to Webpack failing to bundle its Node.js native extension. Adding
it to the server components external packages list fixes this issue.
Part of https://github.com/appsignal/appsignal-nodejs/issues/1014.
When the router cache can't find a cache node for the requested segment,
it performs a request to the server to get the missing data. This
request to the server currently will always include the `next-url`
header, and on soft-navigations, the router will route the request to
the intercepted handler. This lazy fetch is treated as a soft navigation
by the server, and will incorrectly return data for the intercepted
route.
Similar to the handling in `router.refresh`, and the server action
reducer, we should not include the `next-url` header if there's no
interception route currently in the tree, as otherwise we'll be
erroneously triggering the intercepted route.
Fixes#64676
Closes NEXT-3146
Reverts vercel/next.js#64271
This appears to be causing problems rendering error boundaries on SPA
navigations and needs further investigation
Closes NEXT-3150
### Why
If you have a client entry that mixing `default` re-export and `*`
re-export, atm we cannot statically analyze all the exports from this
the boundary, unless we can apply barrel file optimization for every
import which could slow down speed.
```js
// index.js
'use client'
export * from './client'
export { default } from './client'
```
Before that happen we high recommend you don't mixing that and try to
add the client directive to the leaf level client module. We're not able
to determine what the identifiers are imported from the wildcard import
path. This would work if we resolved the actual file but currently we
can't.
### What
When we found the mixing client entry module like that, we treat it as a
CJS client module and include all the bundle in client like before what
we have the client components import optimization.
Ideally we could warn users don't apply the client directive to these
kinda of barrel file, and only apply them to where we needed.
Fixes#64518
Closes NEXT-3119
* https://github.com/vercel/turbo/pull/7995 <!-- Benjamin Woodruff - fix(turbopack-node) postcss.config.js path resolution on Windows -->
(plus unrelated turborepo + CI changes)
This PR should not be cherrypicked into the 14-2-1 branch. Instead https://github.com/vercel/next.js/pull/64677 should be merged into that branch, as that PR contains only the one above Windows commit.
## Info
I did not create a GitHub issue, but this PR for fixing the issue. Hope
that's okay.
## The bug
We run a 'normal' custom server described here:
https://nextjs.org/docs/pages/building-your-application/configuring/custom-server
```ts
const next = require('next');
const dev = process.env.NODE_ENV !== 'production';
const port = 3000;
const app = next({ dev, port, quiet: !dev })
const handle = app.getRequestHandler()
// ...
```
The `quiet` settings is missed in some deeper Next.js internal api
calls. For that reason, the setting did not work at all. This works only
in production mode.
## Testing
I tried to implement a test in `/test/production/custom-server` but I
failed to get the `stderr` messages. When someone give me some guidance,
I will add a new test.
Here are some criteria:
- need: custom server with `quiet: true` setting
- need: a next.js page with thrown error. e.g. `export const
getServerSideProps = () => { throw new Error('failed') }`
- need: collect all `stderr` messages
I tested the fix in our project by editing the files in `node_modules`
-- it worked.
## Background
We upgrade our project from next `13.3.4` to `14.2.0` and saw this
regression. I can not tell in which version this bug was added. We run a
Next.js + 'custom server' + Docker setup. Because we have a lot of
traffic, we need to suppress the standard Next.js logging and using our
own logging.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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?
- Changes webpack output target to `es6` (required for `async function`
output)
- Adds tests for top level await in server components and client
components (App Router)
- Converted the async-modules tests to `test/e2e`
- Has one skipped test that @gnoff is going to look into. This shouldn't
block merging this PR 👍
Adds additional tests for top level `await`.
Since [Next.js
13.4.5](https://github.com/vercel/next.js/releases/tag/v13.4.5) webpack
has top level await support enabled by default.
Similarly Turbopack supports top level await by default as well.
TLDR: You can remove `topLevelAwait: true` from the webpack
configuration.
In writing these tests I found that client components are missing some
kind of handling for top level await (async modules) so I've raised that
to @gnoff who is going to have a look.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3126
Fixes https://github.com/vercel/next.js/issues/43382
### Why
For app page rendering on edge, the `AsyncLocalStorage` (ALS) should be
bundled as same instance across layers. We're accessing the ALS in
`next/dynamic` modules during SSR for preloading CSS chunks. There's a
bug that we can't get the ALS store during SSR in edge, I digged into it
and found the root cause is:
We have both import paths:
`module (rsc layer) -> request ALS (shared layer)`
`module (ssr layer) -> request ALS (shared layer)`
We expect the ALS to be the same module since we're using the same layer
but found that they're treated as different modules due to applying
another loader transform on ssr layer. They're resulted in the same
`shared` layer, but with different resource queries. This PR excluded
that transform so now they're identical across layers.
### What
For webpack, we aligned the loaders applying to the async local storage,
so that they're resolved as the same module now.
For turbopack, we leverage module transition, sort of creating a new
`app-shared` layer for these modules, and apply the transition to all
async local storage instances therefore the instances of them are only
bundled once.
To make the turbopack chanegs work, we change how the async local
storage modules defined, separate the instance into a single file and
mark it as "next-shared" layer with import:
```
any module -> async local storage --- use transition, specify "next-shared" layer ---> async local storage instance
```
Closes NEXT-3085
### What
When rendering a parallel slot multiple times in a single layout, in
conjunction with using an error boundary, the following TypeError is
thrown:
> Cannot destructure property 'parallelRouterKey' of 'param' as it is
null
### Why
I'm not 100% sure of the reason, but I believe this is because of how
React attempts to dededupe (more specifically, "detriplficate") objects
that it sees getting passed across the RSC -> client component boundary
(and an error boundary is necessarily a client component). When React
sees the same object twice, it'll create a reference to that object and
then use that reference in future places where it sees the object. My
assumption is that there's a bug somewhere here, as the `LayoutRouter`
component for the subsequent duplicated parallel slots (after the first
one) have no props, hence the TypeError.
### How
Rather than passing the error component as a prop to `LayoutRouter`,
this puts it as part of the `CacheNodeSeedData` data structure. This is
more aligned with other properties anyway (such as `loading` and `rsc`
for each segment), and seems to work around this bug as the
`initialSeedData` prop is only passed from RSC->client once.
EDIT: Confirmed this is also fixed after syncing the latest React, due
to https://github.com/facebook/react/pull/28669Fixes#58485
Closes NEXT-2095
`initialCanonicalUrl` differs from the `canonicalUrl` that gets set on
the client, such as when there's a basePath set.
This hoists the `canonicalUrl` construction up so we can re-use it when
adding refetch markers to the tree.
This also renames `pathname` -> `path` since it also includes search
params. I added a test to confirm no extra erroneous fetches happened in
both cases.
Fixes#64584
Closes NEXT-3130
Since `AppRouterState` is promise-based (so we can `use` the values and
suspend in render), the state itself isn't stable between renders. Each
action corresponds with a new Promise object. When a link is hovered, a
prefetch action is dispatched, even if the prefetch never happens (for
example, if there's already a prefetch entry in the cache, and it
doesn't need to prefetch again). In other words, the prefetch action
will be dispatched but won't necessarily change the state.
This means that these no-op actions that don't actually change the state
values will trigger a re-render. Most of the context providers in
`AppRouter` are memoized with the exception of `LayoutRouter` context.
This PR memoizes those values so that consumers are only notified of
meaningful updates.
Fixes#63159
Closes NEXT-3127
### What
Fixes a regression to enable wasm fallback for the know target triples
(that does not have native bindings). The condition was skewed when
introducing `useWasmBinary` flag.
Closes PACK-2969
### What?
Toolchain is updated as well.
Should improve compile times marginally, also added the new parallel
frontend.
Depends on https://github.com/vercel/turbo/pull/7409
Closes PACK-2526
### What
When middleware.js is present, the logging is duplicated. We should
filter out the 1st middleware request and only log the actual one going
through request handler / renderer
Closes NEXT-3125
When an action is marked as "discarded", we enqueue a refresh, since the
navigation event will be invoked immediately without waiting for the
action to finish. We refresh because it's possible that the discarded
action triggered some sort of mutation/revalidation, and we want the
router to still be able to respond to that new data.
However there's a bug in this logic -- it'll only enqueue the refresh
action if there were no other actions in the queue, ignoring the case
where something is still in the queue. This makes sure that the refresh
is handled after `runRemainingActions` finishes.
When adding a test for the server component case (which doesn't hit this
refresh branch), I noticed `LayoutRouter` caused React to suspend
indefinitely, because it got stuck in the `use(unresolvedThenable)`
case. We should only suspend indefinitely if we kicked off a the
`SERVER_PATCH` action, as otherwise it's possible nothing will ever
break out of that branch.
Fixes#64517
Closes NEXT-3124
## What
Determine if the client module is a CJS file and `default` export is
imported, then we include the whole module instead of using webpack
magic comments to only extract `default` export.
## Why
Unlike ESM, The `default` export of CJS module is not just `.default`
property, we need to include `__esModule` mark along with `default`
export to make it function properly with React client module proxy
Fixes#64518
Closes NEXT-3119
### What
This PR's goal is to improve the throughput performance of the Next.js
server when handling Pages Router routes.
Note that the results from this are very synthetic and do not represent
the real-life performance of an application. If we only wanted to handle
hello worlds, we could probably make this even faster but on production,
a slow fetch call to your DB is probably what's slowing you down.
I'll look into App Router next.
### Why?
I guess I got nerd-sniped into it 😃
### How?
A few optimizations:
- I looked deeply at the pipeline for rendering a Pages Router page. I
noticed a lot of intermediary streams being created here and there to
eventually be concatenated to a simple string. I think this is probably
left over code from when we wanted to support streaming there and so
there's some code that was shared with the App Router, which we
absolutely don't need I think. I refactored it to be slightly simpler
with just a few string concats here and there.
- misc: I removed some redundant Promises being created here and there
and added a small inline optimisation to eliminate `if (renderOpts.dev)`
code in production.
### Nummies
Test setup: hello world pages router app, next start + autocannon
- requests handled in 10s: 18k -> 33K, **~80% improvement**
- avg latency: 4.89ms -> 2.8ms, **~42% improvement**
- avg req/res: 1846.5 -> 2983.5, **~61% improvement**
Before
<img width="742" alt="image"
src="https://github.com/vercel/next.js/assets/11064311/658e7ade-eba7-4604-a7c9-619bd51a5ec8">
vs
after
<img width="880" alt="image"
src="https://github.com/vercel/next.js/assets/11064311/2f46cf69-b788-4db2-bf90-6f65dc7abd82">
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3103
### What?
Add validation to ensure that the user is not using postcss when `experimental.useLightningcss` is enabled.
### Why?
It's confusing.
### How?
Closes PACK-2928
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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?
This enhances the typings in the `BaseServer`, `NextNodeServer`, and
`NextWebServer` to simplify types for request and responses across the
entire server. Rather than relying on manual environment checks only as
the source with error-prone type casts, this adds basic guards (albeit
naive) that assert the typings depending on the runtime environment
variables. This greatly enhances the typings used across the servers as
the servers no longer use the `as` keyword when working with these
request and response types.
This is a precursor to future planned work to further split the
different rendering runtimes to assist with code elimination and
framework organization.
### Why?
As a step to utilizing these more unified types, the `app-render.tsx`
(App Pages rendering pipeline) has been modified to instead accept the
abstract `BaseNextRequest` and `BaseNextResponse` types. This is a
precursor to future work to split the streaming behaviour based on the
runtime environment (ie, in Node.js, we can utilize the native streams
instead of web streams, which offer significant performance gains).
### How?
The server types were modified to be generic, allowing the three server
implementations to have their types flow safely between the different
methods. This enables us to only reference the `NodeNextRequest` within
the `NextNodeServer`, and the `WebNextRequest` within the
`NextWebServer` for example.
🎥 [Loom
Video](https://www.loom.com/share/76af2225cf0246d0b4f609ab3e35fff9?sid=c948a919-ac9e-4571-8a75-bd9d0a0776e2)
Closes NEXT-3102
Add information that revalidate interval is in seconds to unstable_cache
It's not obvious as "usually" time is in milliseconds
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### Summary
Fixes#52935
`next/script` has a `Script` component that supports an `async` prop.
However, when scripts are loaded with the `async` prop set to false, the
script is loaded as if async was set to true. This may cause scripts to
execute out of order. Repro:
https://github.com/domdomegg/next-async-script-reproduction
I think this is occurring because Next uses setAttribute to set the
async and defer attributes. However, this is not a valid way to set
these properties on a script. This is because . Demo:
https://jsfiddle.net/6ktpfae1/
This PR fixes this behaviour by using removeAttribute after calling
setAttribute (rather than using setAttribute "false"). This appears to
result in correct behaviour.
Given it appears this workaround was already applied in `next/head`,
I've harmonised the code between these two.
### Next steps
I think this PR is ready for review. I acknowledge there are no test
changes, but there are no existing tests for `next/script` at all and
creating them I think would be disproportionally difficult given issues
in #52943.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Sam Ko <sam@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Turbopack: don’t show long internal stack traces on build errors
Fixes PACK-2909
Looks like this may have been introduced in #61929, when code was moved
out of `setup-dev-bundler.ts`, `ModuleBuildError` was duplicated and no
longer satisfied the `instanceof` check.
Closes PACK-2951
Resolves#64412
This adds a client transition to the app route `ModuleAssetContext` and
the corresponding transforms so that client components can be safely
imported and referenced (as their proxies) in app routes.
Test Plan: Added an integration test
Closes PACK-2964
### What?
The string value of `Metadata.openGraph.emails` throws error:
```tsx
export const metadata = {
openGraph: {
type: 'article',
emails: 'author@vercel.com',
},
};
```
Error:
```sh
r.map is not a function
```
The type is:
```tsx
type OpenGraphMetadata = {
// ...
emails?: string | Array<string>
}
```
### Why?
Basic values such as `emails` and `phoneNumbers` were not included when
`ogType` was set while resolving the values.
### How?
Include basic values when resolving the metadata.
Fixes#63415
This fixes and improves the `lib/helpers/install.ts` file (`install()`)
method to better support pnpm and properly respect the `root` argument.
I encountered an issue where by running `next <command> <project-dir>`,
and the `<command>` involved installing missing dependencies (like
`lint` or my upcoming `experimental-test`), it was not executing pnpm in
my `<project-dir>` because pnpm doesn't have a `--cwd` flag.
Closes NEXT-3092
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
This ensures we properly skip calling a fetch during build-time that has
`cache: 'no-store'` as it should only be called during runtime instead.
Fixes: https://github.com/vercel/next.js/issues/64462
Closes NEXT-3114
I'm assuming leaving keywords blank is intended, but with 🖤 for Next.js,
I added 10 keywords to increase the traction of users.
- react
- web
- server
- node
- nextjs
- vercel
Also, included relative keywords that can be easily accessed from the
landing of [npm](https://www.npmjs.com).
- framework
- front-end
- back-end
- cli
Co-authored-by: Shu Ding <g@shud.in>
## Why?
For multi-root layouts (route groups on the root with their root
layouts, no layout file on the root), it is not possible to use global
`not-found` since the `layout` is missing on the root.
```sh
.
└── app/
├── (main)/
│ └── layout.js
├── (sub)/
│ └── layout.js
└── not-found.js --> ERR: missing layout
```
Current Behavior:
```sh
not-found.js doesn't have a root layout. To fix this error, make sure every page has a root layout.
```
## What?
Let multi-root layouts also benefit from the global `not-found`.
## How?
Wrap root `not-found` with default layout if root layout does not exist.
Although this solution is not `multi-root` specific, it won't produce
critical issues since a root `layout` is required for other cases.
Fixes#55191#54980#59180
### What?
We strip the `traceparent` header from the cache-key.
### Why?
The traceparent header forms part of the W3C Trace Context standard,
installed to track individual HTTP requests from start to end across
multiple services. That means each individual HTTP request will have a
unique traceparent value, reflecting its unique journey across servers
and services.
If we include the traceparent header in the cache key, the uniqueness of
the traceparent means the cache key would always be different even for
requests that should yield the same response. This would cause the cache
to always miss and re-process the request.
Effectively rendering fetch-cache useless.
Co-authored-by: Jeffrey <jeffrey@jeffreyzutt.nl>
### 🤔 What's in there?
We've deprecated config's `analyticsId` in 14.1.1 [almost 3 months
ago](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.2).
Users can opt in fot `@vercel/speed-insights`, or use
`useReportWebVitals` to report to any provider they'd like.
This PR:
- removes `analyticsId` key from configuration
- stops setting `__NEXT_PUBLIC_ANALYTICS_ID` env variable when the key
was present
- stops injecting `performance-relayer` file, when the variable is set
- cleans up related test code.
### What?
There is a race condition in the `pull-build-cache` script. When the
remote cache entry was removed between the dry run and the real run, it
will run the command and caches whatever is in the native folder.
Seems like there are some very old leftover files there which lead to an
broken publish.
This changes the command to fail when there are no files and empties the
folder before running the script. This should lead to pull-build-cache
to failing instead.
Closes PACK-2957
Fixes#64468
### What
Inherit the client boudaries from the found matched target in load
barrel
### Why
The root cause with the barrel transform, we missed the client boundary
directive during the transform.
Since the new version of mui's case looks like this:
Import path
page.js (server module) -> `<module>/index.js` (shared module) ->
`<module/subpath>/index.js` (client module) ->
`<module/subpath/sub-module.js> (client module)
After our transform, we lost the `"use client"` which causes the
mismatch of the transform:
In `rsc` layer: the file pointing to the sub module entry
(`<module/subpath>/index.js`), but without the client boundary.
Fixes#64369
Closes NEXT-3101
Since the router processes events sequentially, we special case
`ACTION_NAVIGATE` events to "discard" a pending server action so that it
can process the navigation with higher priority. We should apply this
same logic to `ACTION_RESTORE` events (e.g. `router.back()`) for the
same reason.
Fixes#64432
Closes NEXT-3098
`fetchCache` is a more fine-grained segment level cache-control
configuration that most people shouldn't have to use. Current semantics
of `dynamic = "force-dynamic"` will still treat the fetch as cacheable
unless explicitly overriding it in the fetch, or setting a segment level
`fetchCache`.
The `dynamic` cache configuration should be seen as a "top-level"
configuration, while more fine-grained controls should inherit logical
defaults from the top-level. Otherwise this forces people to opt-into
the `fetchCache` configuration, or manually override each `fetch` call,
which isn't what you'd expect when forcing a segment to be dynamic.
This will default to not attempting to cache the fetch when
`force-dynamic` is used. As a result, I had to update one of the
`app-static` tests to use `revalidate: 0` rather than `force-dynamic`,
as the revalidate behavior is slightly different in that it won't modify
the revalidation time on a fetch if it's non-zero.
Closes NEXT-2067
The fix is not correct, we already have request ALS wrapping the request
in app-render, shouldn't get another one for edge adapter. This is
actually a bundler bug
Reverts vercel/next.js#64382
Closes NEXT-3097
This PR improves the server rendering performance a bit, especially for
the App Router. It has mainly 2 changes.
A rough benchmark test with a 300kB Lorem Ipsum page, SSR is about 18%
faster.
### Improve `getServerInsertedHTML`
- Avoid an extra `renderToReadableStream` if we already know the content
will be empty
- Avoid `await stream.allReady` for better parallelism with
`streamToString()`
- Increase the `progressiveChunkSize`
### Improve `createHeadInsertionTransformStream`
- Only do chunk splitting and enqueuing if the inserted string is not
empty
## What?
- Removes the node-file-trace options from being unsupported as they are
passed to node-file-trace in build/index.ts
- Ensures `import next from 'next'` is handled in the same way as
webpack: creating an empty module. Currently it tried to bundle all
Next.js internals which is wrong.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
Closes NEXT-3086
### What
Wrap async local storage for all edge runtime routes in adapter
Basically fixed the case reported in [this
tweet](https://x.com/keegandonley/status/1778538456458854880)
### Why
We're relying on the ALS for dynamic css preloading but we didn't wrap
the ALS for request handlers for edge. So if you have CSS imports in
`next/dynamic` in edge runtime it would break.
Closes NEXT-3085
Manifests in the runtime should be treated as immutable objects to
ensure that side effects aren't created that depend on the mutability of
these shared objects. Instead, mutable references should be used in
places where this is desirable.
This also introduces the new `DeepReadonly` utility type, which when
paired with existing manifest types, will modify every field to be read
only, ensuring that the type system will help catch accidental
modifications to these loaded manifest values as well.
Future work could eliminate these types by modifying the manifest types
themselves to be read only, only allowing code that generated them to be
writable.
Closes NEXT-3069
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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?
This creates a new `SharedRevalidateTimings` type that is safe to share
amongst different points within the framework for sharing revalidation
timings. This is a precursor to #64313 which freezes loaded manifests.
### Why?
Using the `SharedRevalidateTimings` type, we no-longer have to modify
the in-memory instance of the prerender manifest to share the
revalidation timings for different routes.
Closes NEXT-3083
## Why
Currently, Server Action handlers are just normal routes and they
accepting POST requests. The only way to differentiate a normal request
(page access, API route, etc.) from a Server Action request is to check
that if it's a POST and has a Server Action ID set via headers or body
(e.g. `multipart/form-data`).
Usually, for existing page and API routes the correct handlers (page
renderer, API route handler) will take precedence over Server Action's.
But if the route doesn't exist (e.g. 404) it will still go through
Server Action's handler and result in an error. And we're eagerly
logging out that error because it might be an application failure, like
passing a wrong Action ID.
## How
In this PR we are making sure that the error is only logged if the
Action ID isn't `null`. This means that it's an intentional Server
Action request with a wrong ID. If the ID is `null`, we just handle it
like 404 and log nothing.
Fixes#64214.
Closes NEXT-3071
* Early return if the `this._module` doesn't exist, aligning with the
type
* If the source is changed, we should return the changed source
otherwise the indexes in source map will be wrong unless the modified
code is appended to the source code, but in this loader it's a different
case
Closes NEXT-3075
