Utils `stringToUint8Array` and `arrayBufferToString` assume that the values are just arbitrary fixed width data. However that doesn't work when we do unicode concatenation (`actionId + arg`) which requires Text encoder/decoder to be used.
Closes#58463, closes#58579. In general any complex unicode characters will cause the same issue, for example emojis.
## What?
Was investigating an issue with Turbopack and MDX, in the process found
a few bugs:
- When you have a `tsconfig.json` or `jsconfig.json` the `baseUrl: '.'`
is used by default which causes the top-level directories to be
available as e.g. `design-system` (without a prefix).
- This is not how TypeScript's default setting for `baseUrl` works.
While it should resolve `paths` relative to `.` when none is specified
it does not do additional resolving for the top level directories/files.
- When `"baseUrl": "."` is added to `tsconfig.js` explicitly it handles
the top level directories.
- `modularizeImports` and other SWC transforms weren't applied to `.mdx`
files when `experimental.mdxRs` is enabled, which caused compilation to
fail.
- `modularIzeImports` and other SWC transforms are not applied to `.mdx`
files when using Turbopack.
- @kwonoj is investigating this, will be handled in a follow-up PR.
## How?
- Added a test suite for `modularizeImports` with MDX tests
- Removed the condition that disables swcLoader in webpack when using
mdxRs
- Changed the check for `tsconfig.json` / `jsconfig.json` baseUrl to
include if it was implicitly or explicitly set, disabled the module
resolving when it is implicitly set
<!-- 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: Tobias Koppers <tobias.koppers@googlemail.com>
There're some reports related to using incorrect Node.js version, sometimes users ended up in weird errors. As pkg manager like pnpm only gives a warning ` WARN Unsupported engine: wanted: {"node":">=18.17.0"} (current: {"node":"v16.18.0","pnpm":"8.9.0"})` which is not easy to investigate the issue.
We're adding a version check at the beginning of the Next.js process so if Node.js version is mis-match the version specified in package.json, bail with error.
Examples
node 16.x
```
You are using Node.js 16.18.0. Node.js >= v18.17.0 is required.
```
node.18.16
```
You are using Node.js 18.16.1. Node.js >= v18.17.0 is required.
```
The app router reducer state used to be managed by `useReducer`, so it
was written to be resilient to rebasing — the same action may be
processed multiple times. Now that we've lifted the reducer outside of
React (#56497), each action runs only a single time. So we can simplify
some of the logic.
Previously, actions that update that cache were passed an empty cache
object as part of the action payload. Now, we can instead create these
objects on demand in the reducer.
(We should do the same for the `mutable` object, but there's a unit test
which relies on this implementation detail, so I've left that for a
separate PR.)
<!-- 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 #
-->
We previously used preloadComponent to render nested page/layouts in
parallel, but now that all layouts are passed to React at the top level
(#58669), we no longer need this special module.
A flaw of preloadComponent was that it only called the top-most
component per layout. In the new approach, React can preload non-layout
components, too.
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
In anticipation of #58885 (and to avoid adding another spot where we're checking the same headers), this unifies the logic that parses the request headers and determines if the request corresponds with a server action.
There was already some drift between the check in `base-server` and `action-handler` (unsure if this was intentional - let me know if so, in which case maybe separated handling is the better approach. I couldn't think of a good reason why it would be different, though).
Existing tests should be sufficient for testing this changeset.
No change in behavior, this just moves a util that performs the same
error digest parsing into the other file that performs similar behavior
& validation. Since splitting & parsing the digest string is a strange
operation, this keeps it close to where that happens & where it's
validated so it's easier to follow.
Since this file is imported in the same spots that we're importing the
other redirect utils, there doesn't seem to be a reason to keep them
separated.
### What?
Shows the actual request url that triggered a compilation in the console
message
### Why?
makes it easier to find accidental compilation
### How?
Closes PACK-2017
The sandboxed request processing do not share the same async context with the `BaseServer` and thus the context should be propagated independently.
Notably, the `headers` API is different in `BaseServer` (`Record<string, string | string[]>`) vs in the sandbox (`Headers`), so additionally, we have to use the right `getter`.
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
* Add docs link to the warning, add codemod link to viewport docs section
* Only log the warning once after the metadata resolving process, this will avoid multiple duplicated logs showing for one page.
Closes NEXT-1723
### What?
Rewrites to an edge route currently throw an invariant rather than properly serving up the page that is rewritten to.
### Why?
The `NextRequest` object that is provided to the edge route handler contains pathname information only for the "origin" request (e.g., when visiting `/one/example` which rewrites to `/two/example`, the pathname is still `/one/example`. This hits an invariant since the route matcher is unable to find `/one/example` since it does not exist.
### How?
This updates the module wrapper to grab the pathname from the route definition rather than the request object. For dynamic segments, we extract them from `request.nextUrl` since we know that even if `nextUrl` is referencing the origin path, the parameters it has are relevant for the rewrite.
This adds the `getUtils` utility that's also used in base-server to handle the URL normalization, which also provides an interface for normalizing dynamic params from a `ParsedUrlQuery`.
Closes NEXT-1724
Fixes#48295
This PR adds more information to `.next/trace` for local development:
- Break down server startup times into setting up the dev bundler and running the instrumentation hook
- Add top level span for handling a request such as a page request, app router request, or API request
- Add span for compilation time tracking the path of the route that triggered the compilation.
- Track memory usage after every request
- Track event when server is restarted due to reaching the memory limit
Platform stats and memory usage on startup:
Memory usage after each request:
<img width="340" alt="Screenshot 2023-11-20 at 9 16 44 AM" src="https://github.com/vercel/next.js/assets/7355009/d14279d6-35c5-45a6-b431-b485d5d14ac6">
Split server startup times into setting up the dev bundler and running the instrumentation hook:
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
This PR doesn't treat an instrumentation hook as a `PAGES` page which
avoids compiling `_app`, `_document`, and `_error` when compiling the
instrumentation hook.
It's too easy to change the root context and thus the `context.active()
=== ROOT_CONTEXT` it's not a reliable way to check whether the current
context is a root. A much more predictable option is to see if there's
actually an active tracing span already defined.
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR fixes an issue where users would try to access `req.cookies` from a route handler and be unable to read from it.
This issue was caused by `req.cookies` not opting you into dynamic behaviour, unlike `cookies()` from `next/headers`. This fixes it.
This uses styled issue titles and details introduced in
vercel/turbo#6535, which also moves "Module not found" messaging to the
title field for those issues.
Closes PACK-2013
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: Leah <github.leah@hrmny.sh>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
## What?
Changes the default resolve extensions to be consistent between
server/client compilation.
Currently browser prefers `.mjs` then `.js` and the server compiler
prefers `.js` then `.mjs`.
I added that behavior back in 2018 before mjs/cjs extensions were fully
baked and many npm libraries had incorrect usage of it (PR: #5898).
In the new setup with ESM resolving in Node.js writing out the full
extension is required for `.mjs` files, meaning this "magic resolving"
of a file to `.mjs` is no longer correct. In the future we'll likely
want to remove `.mjs` from the default list of resolve extensions to
align with the Node.js ESM resolver a bit more.
For now we have to keep it in order to not break existing applications
that rely on that behavior, an example of that seems to be contentlayer.
## How?
Removed the condition and aligned it on a single list instead of
separate lists.
<!-- Thanks for opening a PR! Your contribution is much appreciated.i
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: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Calls to `revalidateTag` when using the data cache would sometimes be ignored. This would result in stale data being displayed even after manually triggering a revalidation.
### Why?
Revalidation calls are pushed onto a `pendingRevalidates` array and, in the case of a route handler, are awaited [here](8b11264ea9/packages/next/src/server/send-response.ts (L53-L55)).
Previously this took place as part of the former `pipeReadable` implementation ([ref](57bb52d37d/packages/next/src/server/send-response.ts (L49))) which awaited the promise before calling res.end ([ref](57bb52d37d/packages/next/src/server/pipe-readable.ts (L99-L105))). There was a subtle change in behavior here in a recent refactor that seems to cause a race between awaiting the promise and ending the response, which results in this unpredictable behavior.
### How?
This applies similar logic that used to be in the `pipeReadable` function to the new `pipeToNodeResponse` function. Namely, we plumb `waitUntil` into the writeable stream close handler and await it before calling `res.end()`.
This is a very difficult edge case to test, and as such resorted to rigorous manual testing when deployed to an environment that uses the data cache.
Fixes#52962Fixes#57632
### What?
In #57062, a deprecation warning was added for usage of `nextConfig.images.domains`. This warning was erroneously showing up for users that had an `assetPrefix` configured.
### Why?
When an `assetPrefix` specified, during assignment for `nextConfig` default values, we push to `nextConfig.images.domains` so that the user doesn't receive errors about hostnames not being configured ([Original PR](https://github.com/vercel/next.js/pull/29307)). This means people are indirectly being opted into a deprecated config, and receiving a warning because of it.
### How?
We no longer push any defaults to the deprecated config option. Additionally, this applies the same defaults handling to `remotePatterns,` as otherwise people using this new config will run into the same issue as this block was originally intended to fix.
Fixes#58074
After the changes in #58669, it's now possible for these `DynamicUsageErrors` to be caught in the streaming renderer. We didn't have any logic to handle this happening inside the existing catch block, so this adds a check for that specific error and re-throws it so that it properly bubbles to `exportPage`. `exportPage` checks the error to see if it's a `DynamicUsageError` and if so, marks the page as dynamic.
(This resolves an issue with particular scenarios hanging the build, caught by a few of our tests: [example](https://github.com/vercel/next.js/actions/runs/6949079695/job/18907597751?pr=58744), [example](https://github.com/vercel/next.js/actions/runs/6948412805/job/18904387924))
### What?
When a layout segment forces dynamic rendering (such as with
`force-dynamic` or `revalidate: 0`), navigating to sub-pages of that
layout will attempt to re-render the layout, also resulting in side
effects re-running. This means if your layout relies on a data fetch and
you render the result of that data in the layout, it will unexpectedly
change when navigating between sub-paths, as described in #57326.
As a separate issue (but caused by the same underlying mechanism), when
using `searchParams` on a dynamic page, changes to those search params
will be erroneously ignored when navigating, as described in #57075
### Why?
As a performance optimization we generate static prefetch files for
dynamic segments ([original
PR](https://github.com/vercel/next.js/pull/54403)). This makes it so
that when prefetching is turned on, the prefetch can be served quickly
from the edge without needing to invoke unnecessarily. We're able to
eagerly serve things that can be safely prefetched. This is nice for
cases where a path has a `loading.js` that we can eagerly render while
waiting for the dynamic data to be loaded.
This causes a problem with layouts that opt into dynamic rendering: when
the page loads and a prefetch is kicked off for the sub-page, it'll load
the static prefetch, which won't be generated with the same router state
as the dynamically rendered page. This causes a mismatch between the two
trees, and when navigating within the same segment, a refetch will be
added to the router because it thinks that it's navigating to a new
layout.
This also causes issues for dynamic pages that use `searchParams`. The
static prefetch will be generated without any knowledge of search
params, and when the prefetch occurs, we still match to the prefetch
generated without search params. This will make the router think that no
change occurs, and the UI will not update to reflect the change.
### How?
There's ongoing work by @acdlite to refactor the client router.
Hopefully it will be easier to re-land this once that work is finished.
For now, I've reverted the behavior as it doesn't seem to be worth the
bugs it currently causes. I've also added tests so that when we do
re-land this behavior, we can catch these subtleties.
Fixes#57326Fixes#57075
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Various fixes in handling of externals in node.js
* add extensions to builtin externals to allow node.js ESM to work
* improve the auto-externals logic to detect more edge cases
* prepare for `esmExternals` support, but that's blocked by client
manifest missing the async flag
* currently only `esmExternals: false` is supported
### Why?
### Turbopack Changes
* https://github.com/vercel/turbo/pull/6531 <!-- Leah - fix(turbopack):
postcss should be applied to `@import`ed CSS files -->
* https://github.com/vercel/turbo/pull/6530 <!-- Tobias Koppers - fix
node.js externals -->
---------
Co-authored-by: Leah <github.leah@hrmny.sh>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
* include path and title in errors
* don't block the page for errors in node_modules
### Why?
### How?
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
## Based on #58666
*I submitted this stack as separate PRs so I could run CI but I want to
land them as a single unit. So I've left all but this last one in draft
mode. You can review them commit-by-commit.*
We render nested layouts in parallel on the server. This means we should
be able to create a CacheNode entry for every layout in the tree as soon
as the Flight response is received by the client, even before the nested
layouts have streamed in. Currently, we wait until the nested layouts
start rendering before we write them into the cache, which prevents us
from performing certain optimizations. That's because the CacheNodes are
sent as a prop to LayoutRouter; the only way to unwrap the CacheNode is
to wait for LayoutRouter to render.
In previous PRs, I updated the server to create a top-level data
structure that contains all the CacheNodes for the entire tree. This PR
updates the client side to receive the nodes and write them into the
cache.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Currently to make inline-defined Server Actions work, the compiler hoists the actual `"use server"` function to the module level and convert the inlined function to a parentheses expression that creates a noop wrapper function and wraps it with the proxy. This works fine however expressions are still different from declarations (#57392). So there're some details that can't be aligned well.
With this change, we're going to make the compilation for the two types of inline-defined Server Actions more robust and more lightweight:
#### 1. Expressions
```jsx
const action = async () => { "use server" ... }
const action = async function () { "use server" ... }
const action = async function named () { "use server" ... }
foo={async function () { "use server" ... }}
...
```
These expressions can directly be replaced with a new expression `createActionProxy("id", hoisted_action)`. A `.bind(...)` member call can be followed if it needs to bind any variables from the closure level.
#### 2. Declarations
```js
async function named () { "use server" ... }
```
In this case, we replace all the same `named` idents to be the expression `createActionProxy("id", hoisted_action)`, and removed that function declaration.
With these changes, these will be fewer structural changes to the AST and the code is more performant.
The PR also changes it to use React's `registerServerReference` method directly instead of our in-house implementation inside `createActionProxy`.
Another small change is to stabilize the comment header to use `BTreeMap` inside the SWC transform. Otherwise the test snapshots will randomly mismatch.
Closes#57392.
## What?
Enables `experimental.windowHistorySupport` support for Turbopack.
## How?
Turbopack has a guard for unknown options (allow-list). Added the option
to the list of supported configurations.
No additional changes are needed as Turbopack already uses the
define-env config.
<!-- 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 #
-->
