### What?
- fixes test 17553c5e25/test/e2e/app-dir/metadata/metadata.test.ts (L487)
The way next.js collects static metadata is read static metadata, and then read layout metadata to merge multiple metadatas into a single layout path (17553c5e25/packages/next/src/lib/metadata/resolve-metadata.ts (L347-L352))
When turbopack creates LoaderTree for the corresponding directory tree, it extracts `page` but skips metadata in result there are orphan components that have a metadata doesn't have layout metadata, as well as a component have a layout doesn't have metadata. Latter is being rendered as a page (since it have correct layout), which eventually falls back to the default metadata instead.
PR trickles down the metadata when extracting page (creating a new component with `page`) to consolidates those.
Also PR expands Metadata to have base_page property to capture where it has been originally exists, as we clone down metadata then do `fillMetadataSegment` against the current page where LoaderTree is being created it creates a wrong relative path. For example, currently
```
/icon.svg
- opengragph/
- static -> path being `/opengraph/.../icon.svg` instead of `/icon.svg`
```
When recursively traverse directory tree, capture each components with corresponding base_page to calculate instead.
Unfortunately this doesn't make pass all of the metadata tests; there are lot to dig more. Would like to scope PR in a reasonable size.
Closes WEB-1795
When using server actions on an unsupported version of Node, you might see the following errors:
> NotSupportedError: multipart/form-data not supported
Support in Undici was landed in 5.11.0 which made it into Node v18.11.0
> TypeError: e._formData.forEach is not a function
Earlier versions of v18 (such as 18.0.0) did not have a `.forEach` implementation on FormData
This throws a better error before the user can get to the point of seeing these more confusing errors.
Closes NEXT-1658
Fixes#55932
This PR implements encryption and decryption for Server Action bound values that are from the closure level. Explicit `.bind` values, function arguments and module-level values are NOT handled.
### Compiler
The compiler now groups all closure bound values to an array which gets wrapped with `encrypt`. And then inside the action body, it prepends an expression to recreate the values via `await decrypt`.
Since closure-closed variables will only exist on the server layer, the encryption utility has `"server-only"` annotated.
### Encryption
During build time, a private AES-GCM encryption key is randomly generated and stored in the built server manifest. Before encrypting/decrypting, an extra round of Flight server and client will be used to serialize/deserialize the value.
When encrypting, a salt that contains the action ID is provided to prevent replay attack towards different API endpoints. The encryption key can be overridden via the `NEXT_SERVER_ACTIONS_ENCRYPTION_KEY` env variable so it can be built on multiple machines on scale.
A global singleton for storing the client reference manifest was made for Flight's serialization/deserialization as that might happen outside of rendering.
After encryption, we then serialize the ArrayBuffer as Base64 to send it to the client.
This PR fixes the passing of the `--inspect` option when calling Next.js with it. It's still not great because you need to target the next file in node_modules directly but I'll add a `next --inspect` option in the future.
This:
- Uses `isServer` to use the appropriate Turbopack `FileSystem` when
creating `FileSystemPath`s
- Properly uri decodes path segments originating from `file://` uris
- Correctly reads chunks starting at the project path instead of the
root path
Closes WEB-1815
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
The asset context is a better place to store the layer, because it's
affected by transitions unlike the chunking context
This PR also removes a bunch of unused code
### Why?
See https://github.com/vercel/turbo/pull/6237 for the rationale
Also needs to wait for that PR to be merged
Closes NEXT-1814
#### Turbopack Changes
* https://github.com/vercel/turbo/pull/6237 <!-- Leah - chore: move
layer from chunking context to asset context -->
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Remove the experimental `serverActions` flag
Co-authored-by: Shu Ding <3676859+shuding@users.noreply.github.com>
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
### Description
- Splits the generated code of the `next-edge-ssr-loader` out into 2 templates
- This PR also adds support for optional imports in templates
Closes WEB-1761
### What?
`globalThis.ReadableStream` and `globalThis.WriteableStream` has been exposed since Node.js 18, which is our new default requirement. (#56943)
### Why?
This simplifies the code and might result in slightly better performance.
### How?
Drop any checks of `globalThis` properties that are always defined now.
### What?
Add the same re-retrieval process for subseted font files of Google Font as for CSS files.
+ make use of [async-retry](https://github.com/vercel/async-retry)
### Why?
It was reported in #45080 that Japanese fonts such as Noto Sans JP were frequently `Failed to fetch`.
A retry process was added in #51890, but it did not resolve the issue completely ( https://github.com/vercel/next.js/pull/51890#issuecomment-1614558064 ).
Here is my reproduction code with 13.5.5-canary.4 (please run locally).
https://stackblitz.com/edit/stackblitz-starters-n8zxlq?file=app%2Fpage.tsx
<details>
<summary>And my local error log is here(folded)</summary>
```
$ npm run -- dev
> nextjs@0.1.0 dev
> next dev
⚠ Port 3000 is in use, trying 3001 instead.
▲ Next.js 13.5.5-canary.4
- Local: http://localhost:3001
✓ Ready in 23.9s
○ Compiling /page ...
FetchError: request to https://fonts.gstatic.com/s/notosansjp/v52/-F6jfjtqLzI2JPCgQBnw7HFyzSD-AsregP8VFBEj757Y0rw_qMHVdbR2L8Y9QTJ1LwkRmR5GprQAe69m.4.woff2 failed, reason:
at ClientRequest.<anonymous> (/mnt/c/Users/berlysia/Downloads/stackblitz-starters-n8zxlq/node_modules/next/dist/compiled/node-fetch/index.js:1:65756)
at ClientRequest.emit (node:events:514:28)
at TLSSocket.socketErrorListener (node:_http_client:495:9)
at TLSSocket.emit (node:events:514:28)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
type: 'system',
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT'
}
⨯ Failed to download `Noto Sans JP` from Google Fonts. Using fallback font instead.
Failed to fetch `Noto Sans JP` from Google Fonts.}
FetchError: request to https://fonts.gstatic.com/s/notosansjp/v52/-F6jfjtqLzI2JPCgQBnw7HFyzSD-AsregP8VFBEj757Y0rw_qMHVdbR2L8Y9QTJ1LwkRmR5GprQAe69m.28.woff2 failed, reason:
at ClientRequest.<anonymous> (/mnt/c/Users/berlysia/Downloads/stackblitz-starters-n8zxlq/node_modules/next/dist/compiled/node-fetch/index.js:1:65756)
at ClientRequest.emit (node:events:514:28)
at TLSSocket.socketErrorListener (node:_http_client:495:9)
at TLSSocket.emit (node:events:514:28)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at processTicksAndRejections (node:internal/process/task_queues:82:21)
at runNextTicks (node:internal/process/task_queues:64:3)
at listOnTimeout (node:internal/timers:540:9)
at process.processTimers (node:internal/timers:514:7) {
type: 'system',
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT'
}
...(15 errors emitted)
```
</details>
I've found that the issue is not limited to fetching CSS, fetching subset font files is also failing.
By adding retry handling to the fetch of individual subseted font files as well, I (almost) never see `Failed to fetch` anymore.
The issue tends to become more apparent when downloading a larger number of subsetted fonts.
This suggests that the problem is more likely to occur with larger fonts, such as those designed for CJK languages.
### How?
Add the same re-retrieval process for subseted font files of Google Font as for CSS files.
Related to #51890#53239#45080#53279
Exposes the new experimental Taint APIs using the `taint` flag which
enables experimental React.
As an example for how we can use it, I use it to taint `process.env`
with a better error message. I'm not sure where this should live since
it's a global init but it needs access to the global config. It's
unnecessary to retaint it for every render but not sure if there's a
better place for it.
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR adds a resolver plugin to verify during bundling that when a module is unresolved, that it is not an optional peer dependency specified in the package.json of the caller. An error would happen if you try to bundle packages like `typeorm` since there are `require` calls in the code to those dependencies.
Also, swallow dynamic dependencies warnings in `require` calls error if they come from `node_modules`. They are not actionable at all generally.
This implements support for properly tracing sourcemaps when presenting
error stacks to the user. It also adds code frames when possible.
Closes WEB-1764
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
We already had `domains` as "not recommended" but this PR marks it as "deprecated" and prints a warning if its detected.
I also updated all examples to switch from `domains` to `remotePatterns`.
### What?
Note: This is not a breaking change, just removing some unused code.
### Why?
Since #56896 we don't need this, as Node.js 18+ has `fetch` exposed by default.
### How?
Depends on #56896, #56909
We already didn't load `fetch` if `globalThis` had it (ie. Node.js 18+ environments), and since we are dropping support for Node.js 16, these code paths should have no effect on runtime behavior.
### Story
Since we introduced `ImageResponse` into `next/server` export, there're a few libraries relying on `next/server` that accidentally ended up with bundling og image into the bundle. As og package is quite large that could easily raise the size concern for middleware, edge runtime routes.
### Struggles
We've done optimizations. The tree-shaking strategies are tricky, we tried modularize imports and also optimize cjs require/exports to make sure you're not including og package into bundle if it's not being used. However, it's still not 100% can handle all the bundle optimization cases, such as `import {..} from "next/server.js"` could also ended up with the cjs bundle that failed the tree-shaking.
### Move on
So we decide to move og `ImageResponse` into a separate export `next/og`
Closes NEXT-1660
This avoids testing against latest exact canary version as this causes these tests to fail while the publish is still in progress. As a follow-up we can investigate moving this post publish or packing/deploying tarballs to use.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
This PR adds the optional `limit` parameter on String.prototype.split uses.
> If provided, splits the string at each occurrence of the specified separator, but stops when limit entries have been placed in the array. Any leftover text is not included in the array at all.
[MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split#syntax)
While the performance gain may not be significant for small texts, it can be huge for large ones.
I made a benchmark on the following repository : https://github.com/Yovach/benchmark-nodejs
On my machine, I get the following results:
`node index.js`
> normal 1: 570.092ms
> normal 50: 2.284s
> normal 100: 3.543s
`node index-optimized.js`
> optmized 1: 644.301ms
> optmized 50: 929.39ms
> optmized 100: 1.020s
The "benchmarks" numbers are :
- "lorem-1" file contains 1 paragraph of "lorem ipsum"
- "lorem-50" file contains 50 paragraphes of "lorem ipsum"
- "lorem-100" file contains 100 paragraphes of "lorem ipsum"
This updates some code related to web streams and encoding.
- Removes some unused code related to base64 encoding/decoding (Edge runtime currently supports it natively via `Buffer`)
- Prefer readable stream `pull` versus `.on("data", (chunk) => { ... })` event handlers (simplifies execution)
- Utilize `pipeTo` and `pipeThrough` on web streams to remove custom code related to stream pumping
- Updates pipe readable function to utilize web streams first class rather than relying on manual pumping + stream management
- This also takes advantage of the `AbortController` when piping so that the response can use it to cancel the stream
