### What?
We have to walk the directory tree recursively for every page (instead
of once) to get the correct loaderTree.
With this PR we walk the directory tree and for every
`page.(js,jsx,ts,tsx)` (entrypoint) we find we walk it again to get the
loader tree for that page
Closes WEB-1868
Closes WEB-1609
We also don't warn for awaiting a Promise late. That's a fine pattern in
Next.js because it allows for fetching early and awaiting late.
If a Promise does reject before that we still log an error which is fine
because an error actually did happen even if we didn't await it.
We ignore postpones though because they are not unexpected.
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Reduce the times that we re-create loaders, down to 3 loaders:
* swc loader for server layer
* swc loader for client layer
* babel loader
This change let us only create some loaders for once, and make the code
easier to read.
`babelLoader` will only available when babel config is enabled, so we
use filters to skip it when it's empty.
### What
Fixes how to determine if given route is dynamic to match next-dev does:
462b8585b6/packages/next/src/lib/metadata/get-metadata-route.ts (L79)
We were passing calculated route instead to check if it's dynamic, so
`/sitemap` always considered as static since calculated route is
`/sitemap.xml`.
Closes WEB-1864
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Apply `react-server` resolving and server components invalid APIs
checking to middleware. We want to limit the react usage in in
middleware as so far it's not aimed for rendering purpose.
Another invalid case could be: if you're doing react SSR with
`renderToString` in middleware it should be disallowed. Imaging it could
send the rendered html code to client and you display it in browser. But
it might require hydration so it can be broken.
This PR will only let you import `react-server` export condition
packages.
### What?
Fixes Client -> RSC (client importing a `"user server"` file) Server
Actions that are using TS.
### Why?
### How?
I check if the source module is using TS before "processing" the module
into the RSC layer.
Closes WEB-1871
This PR adds the codemods transforming certain fields from `metadata`
export to `viewport` export, will still preserve rest metadata export
properties. We don't cover `generateMetadata` to `generateViewport` as
there might be more complex logic inside the function which is hard to
apply the codemods rules.
TLDR: Codemods for #57302
* Should show `ImageResponse` is deprecated if you still import from `"next/server"`
<img width="708" alt="image" src="https://github.com/vercel/next.js/assets/4800338/38f9b9db-2cfb-48ec-99cc-08e7d1477155">
* If you build it will fail to compile, this might not be super ideal but at least it's not working. For pure js it will throw errors.
```ts
./app/icon.tsx:7:10
Type error: Only a void function can be called with the 'new' keyword.
5 |
6 | export default function icon() {
> 7 | return new ImageResponse(
| ^
8 | (
9 | <div
10 | style={{
ELIFECYCLE Command failed with exit code 1.
```
This PR updates the build output in order to reflect the changes brought
by PPR and also to make it more consistent.
before
```
○ (Static) automatically pre-rendered as static HTML
◐ (Partially Pre-Rendered) static parts of the page were pre-rendered and the dynamic parts will be streamed
ℇ (Streaming) server-side renders with streaming (uses React 18 SSR streaming or Server Components)
λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps)
```
after
```
○ (Static) prerendered as static HTML
◐ (Partial Prerender) prerendered as static HTML with dynamic server-streamed content
λ (Dynamic) server-rendered on demand using Node.js
ℇ (Edge Runtime) server-rendered on demand using the Edge Runtime
```
<!-- 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 #
-->
Introducting syntax errors in files throws an error in the server
actions parsing, which hides the actual syntax error reported
Closes WEB-1858
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Do not log the removed experiments in the start server logs, for instance `experimental.appDir` should get warned as unexpected option but it's not the valid experiment anymore
Noticed that if you use `unstable_cache` it did not opt-in to ISR even though fetch() does opt-in. This ensures the prerender-manifest holds the revalidate value.
* Rename swc option `is_server` to `is_server_compiler`
* Rename swc plugin `config.is_server` to `config.is_react_server_layer`
* Remove unused `bundle_target`, which could be covered by composing `is_server_compiler` and `is_react_server_layer`
### What?
This completes Turbopack's Server Actions implementation!
It also cleans up several things:
- Removes `server_actions` configuration, it's enabled by default now.
- Fixes the transform that runs in the SSR layer (it actually needs to
use the client transform)
- Generates a new encryption key
### Why?
### How?
It crawls the client layer modules for additional Server Actions
imports, and adds them to our generated `actions.js` entry point.
Closes NEXT-
Fixes #
Closes WEB-1854
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
## Story Time
Metadata API introduced two exports `metadata` and `generateMetadata` to the pages and layouts under app router, as partial prerendering work is going on and people are desiring to render the metadata asynchronizly, this change will be the preparation for moving to the dynamic & asynchronized land. In short, if we can render the metadata asynchronizedly, it will benefit the performance of the initial page loading and client page transiation a lot. Any slow data fetching can be handled while the essential page "shell" is rendered.
For meta tags, there're few ones will visually affect your web page, such as `<meta name="viewport">`, `<meta name="theme color">` and `<meta name="color-scheme">`, rendering them lately after the page frame is ready might bring flickering to the page such as revreting whole page's theme color or shaking due to viewport updates. Those meta are not majorly the "metadata" for SEO, but more for user experience when opening the page. If we're rendering everything as async meta tags, it won't be ideal due to the flickering on your web pages.
## Solution Preparation
We'll want to render the meta tags separately to make sure the visual ones are rendered as blocking along with web page, and then the ones for SEO or bots can be flushed later by later, like a suspense boundary keeps emitting them into the head of html.
We optionally picked up 3 meta tag "viewport", "theme-color" and "color-scheme" to be render first into the web page with html "shell", to guarantee the layout viewport and basic styling are rendered first.
This PR introduced two module export in the page and layout files: `viewport` and `generateViewport`, in order to separate the visual meta tags from the SEO metadata.
### API
```ts
// page.js | layout.js
export const viewport = {
// viewport meta tag
width: 'device-width',
initialScale: 1,
maximumScale: 1,
interactiveWidget: 'resizes-visual',
// visual meta tags
colorScheme: 'dark',
themeColor: { color: 'cyan', media: '(prefers-color-scheme: dark)' },
}
```
There's also a dynamic API like what we did for metadata API
```ts
// page.js | layout.js
export function generateViewport() {
return { ... }
}
```
## Notice
This PR won't get SEO metadata rendered asyncronizedly, instead it's a preparation for the later work in partial prerendering and async metadata. We'll encourage the Next.js community moving to the new metadata viewport API if you're customzing those 3 meta tags. Usually you don't have to change viewport itself, so mostly like only theme-color and color-scheme could relate to it.
### What?
incjects the script tag for CSS reloading
### Why?
### How?
Closes WEB-1851
---------
Co-authored-by: Will Binns-Smith <wbinnssmith@gmail.com>
Instead of `Readable.toWeb` we're gonna manually convert the Node.js stream to a Web stream. `toWeb` is either having a bug, or not compatible with middleware-cloned `PassThrough` streams.
Closes#56286. The case should be already covered with existing tests.
### What
Running `test/e2e/app-dir/emotion-js/index.test.ts` fails with turbopack as emotion skips necessary runtime transforms for the styles. Digging further, it was due to not applying correct importSource for the transform (`@emotion/react`) against ssr component when running with turbopack. Peeking next-dev, we apply `client` side context if issuer layer origin is either ssr or pages for the browser while turbopack doesn't.
PR uses `type` for the module context as equivalent to the issuer layer, and then apply client context for the transform for those modules.
`test/e2e/app-dir/emotion-js/index.test.ts` is passing with this PR.
Closes WEB-1834
This PR removes the usage of `raw-body` for App Router pages by parsing
the body for an action ourselves whilst assuming that it is encoded with
UTF-8. This is already what we do for the Edge Runtime version of Server
Actions and will only break if your page overrides the page encoding,
which should not happen and that we don't need to support.
This should remove a third of a serverless function zip size
<!-- 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
minor fix to match behavior to ae10b5c82b/packages/next/src/shared/lib/router/utils/remove-trailing-slash.ts (L2C4-L9)
as we're seeing a panic when route is /
```
Panic: PanicInfo { payload: Any { .. }, message: Some(byte index 1 is out of bounds of ``), location: Location { file: "packages/next-swc/crates/next-core/src/next_edge/route_regex.rs", line: 202, col: 59 }, can_unwind: true, force_no_backtrace: false }
Backtrace: 0: backtrace::backtrace::libunwind::trace
```
Closes WEB-1841
This is a 6.6kB (gzipped) win for the Node.js worker size baseline. `jsonwebtoken` uses semver to ensure that the Node.js version is larger than `16.9.0` (which is always true with Next.js) so we can just alias it to be a noop function that returns `true`.
This ensures when an error occurs during a revalidate in app router that
properly throw the error fully and don't store the error page in the
cache which matches the expected behavior for full route ISR as errors
are not meant to update the cache so that the last successful cache
entry can continue being served.
Fix was tested against the provided reproduction here
https://app-dir-example-ghl01cxtn-basement.vercel.app/
Fixes: https://github.com/vercel/next.js/issues/53195
This ensures we don't unexpectedly error when a fetch attempts to cache
inside of `unstable_cache`, this also ensures `only-on-store` doesn't
unexpectedly error when `revalidate: 0` is set.
This PR introduces a build optimization to create a "partial prerender" of the page.
1. During compilation, we create a static shell for the page using your existing Suspense boundaries. Components that can be static will be included in this static shell, leaving holes for the dynamic components.
1. Using `<Suspense />`, we can define fallbacks to be included in the partial prerender, as well as the holes for the dynamic components to stream into.
This means Next.js can initially serve a static loading skeleton, kicking off the dynamic parts in parallel. Then, the dynamic components stream in on demand. Dynamic components can use `cookies()`, `headers()`, `'cache': 'no-store'`, or `unstable_noStore()` to opt-into dynamic rendering.
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### Description
- We previously didn't write to the shared `middleware-manifest.json` for edge app pages
- We also need to manually write to the `_ENTRIES` object in turbopack entries because it currently doesn't have a way to change the output type like webpack: https://webpack.js.org/configuration/output/#type-assign-properties
- Also need to write a bunch of manifests as JS files to be able to load them from the edge runtime.
- Some import map fixes were needed as well.
This only fixes dev, build will need more work.
Closes WEB-1698
This doesn't need to error, we can instead warn that the functionality will not work as expected out of the box. Support can be added for outside of Next for this to behave as expected.
These are supported when deployed via the Nextjs builder ([x-ref](https://github.com/vercel/vercel/blob/main/packages/next/src/index.ts#L851-L855)).
### What?
Safely drop `__nextjs_pure` from next internals in transform
```js
import {__nextjs_pure} from 'next/dist/build/swc/helpers'
__nextjs_pure(console.log("test!"))
```
becomes
```js
/*#__PURE__*/ console.log("test!");
```
so it will be dropped by the minifier - terser and swc minifier will
both work.
### Why?
Adding pure comments from JS world with swc transform is complex. This
would be a helper for the case if we want to create "pure" expressions.
### How?
Closes WEB-1829
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Removes the constant prefix and action ID from the IV value and makes it a fully random string. Then, we prefix the actual payload with the action ID to avoid submitting the payload from a different action, as well as using it as the checksum of the encryption data to ensure it's not damaged.
Update the revalidate handling to perform the revalidate option coalescing in the render function closer to the render result output. This helps reduce the amount of scope leak from the render.
We introduced a data fetching logging before, and the control option was under experimental. After a bit experiments turns out users really loves it. We decide to move it to a stable option.
### Changes
We're going to move the `logging` option outside of `experimental`, and scope the `fetches` related config under `logging.fetches`.
```js
// next.config.js
logging?: {
fetches?: {
fullUrl?: boolean
}
}
```
This collects some of the request pathname normalization code into some helpers.
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
BREAKING CHANGE
Since `next export` has been printing a deprecation warning since https://github.com/vercel/next.js/pull/47376, its safe to remove in semver-major.
The upgrade path is to simply add `output: 'export'` in `next.config.js` - everything will continue to work the same.
This config greatly improves the `next dev` experience today. And in the future, it will improve performance of `next build` because we no longer need to do two passes (build then export).
This PR fixes a memory leak when using `next dev` where on HMR, we would always retain the memory associated with the old VM instance, leading to pretty egregious usage of RAM after only a few edits.
The leak itself comes from methods like `setTimeout` and `setInterval` capturing the context in which they were called and somehow never releasing, even if the timeout happened, when running in a Node.js `vm`. This is probably a Node.js bug.
The fix consists of taking ownership of all timeouts and clearing them ourselves manually at the end of each VM lifecycle.
Tested manually:
- hello world Next.js app with edge runtime
- triggered hmr 10 times
- memory usage
- base: 400MB
- before: 800MB
- after: 400MB
This change makes sure that the iv of AES-GCM encryption is cryptographically random on each request. Also added a constant prefix as some kind of checksum to ensure the data is not damaged (e.g. wrong key is being used).
### What?
* no need to clear require cache when assets where not used previously
* make build status reporting more consistent
* report build status to client side for build indicator
### Why?
### How?
Closes WEB-1826
### What?
Update SWC crates. This PR fixes a regression of `swc_core`.
The important PR: https://github.com/swc-project/swc/pull/8153
### Why?
There was a regression in `swc_core`.
### How?
- Fixes#56408
Closes WEB-1811
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Refactoring the webpack-config.ts file to no longer have all aliases defined, instead they are in a separate file which should make refactoring these to use them in Turbopack simpler.
### What?
If there's a static asset with edge runtime config, turbopack will bail with
```
⨯ ModuleBuildError: Code generation for chunk item errored
An error occurred while generating the chunk item [project]/test/e2e/app-dir/metadata/app/icon.svg (static, edge rsc)
Caused by:
- expected output_root to contain asset path
Debug info:
- An error occurred while generating the chunk item [project]/test/e2e/app-dir/metadata/app/icon.svg (static, edge rsc)
- Execution of <DevChunkingContext as ChunkingContext>::asset_url failed
- expected output_root to contain asset path
```
Since we creates chunking context for the edge with different output_root and asset_root, by using asset_root to be client_root. The other places creating context with `DevChunkingContext` don't do this, PR simply adjusting root to be output_root.
For the server's chunking context it actually accepts client_root and set the asseturl with client root instead. However not sure if that's what we want with devchunkingcontext.
This is part of metadata fixes for the test; however edge rendering still doesn't work so test doesn't pass yet.
Closes WEB-1798
### 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
### Reason for making this change
https://yarnpkg.com/getting-started/qa#:~:text=yarn%2Finstall%2Dstate.,your%20workspaces%20all%20over%20again.
In the official documentation of `yarn`, it is stated that `.yarn/install-state.gz` is an optimization file that developer shouldn't ever have to commit. However, currently, when running `create-next-app`, `.yarn/install-state.gz` is being commited.
### Remaining work
I apologize for only modifying one template initially to initiate the discussion first.
If this change is agreed upon, it should be synchronized with other `.gitignore` templates. Would it be possible to follow a similar approach as in https://github.com/vercel/next.js/pull/47241? I would appreciate any assistance in syncing this change.
We currently log when a worker is restarted but not when we send the kill signal, which can create a delta in logs of cryptic errors while the worker is exiting. This explicitly logs when we're terminating the static worker prior to a restart, and also adds an optional logger fn so that we pretty-print the messages.
[slack x-ref](https://vercel.slack.com/archives/C061DJBG8PN/p1697491350970269)
## History
We used to pass `onLoad` through directly to the underlying img so `onLoadingComplete` was introduced in order to handle the case when `placeholder="blur"` was used and `onLoad` would trigger before the placeholder was removed.
We have since changed the behavior of `onLoad` so that it acts the same as `onLoadingComplete` and therefore `onLoadingComplete` is no longer needed.
## What is this PR doing?
This PR marks `onLoadingComplete` as deprecated in favor of `onLoad`. In the future, we may remove `onLoadingComplete`.
In an attempt to avoid introducing experimental features into the Next.js userland space, we're reverting the `Promise.withResolvers` polyfill and preferring an internal `DetachedPromise` interface.
This PR introduces a new API, `unstable_noStore`, which will allow users to declaratively opt out of caching anywhere during static generation in the same way that you can specify `cache: 'no-store'` on a fetch call in Next.js.
An important caveat and difference from just calling `cookies()` to opt-out of static generation is that this won't opt you out when called from within `unstable_cache` and instead defers to the cache configuration to it.
```
import {unstable_noStore as noStore} from 'next/cache';
export default async function Component() {
noStore();
const result = await db.query(...);
}
```
<!-- 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 PR therefore introduces to always set response status code to 500
unless it is a `NotFoundError` or `RedirectError`. This PR would fix
issue #56235. See also:
https://codesandbox.io/p/sandbox/nice-panini-2z3mcp .
**Current Behavior**
At the moment, when an unexpected error occurs during app server
rendering, a 200 ok is returned as status code. This seems to be
undesirable because of the success status CDNs will cache the error
pages and crawlers will index the page considering the error content as
the actual content.
**Desired Behavior**
This issue is related to discussion
https://github.com/vercel/next.js/discussions/53225. Even though I
understand that the response status code cannot be set if streaming has
started, in my view it would be best to set the response status to 500
whenever it can (so before the streaming has started) for SEO and (CDN)
http caching. This would also be consistent with how 404s currently
work; that is, response status code is set to 404 if `NotFoundError`
occurred before streaming (related
[issue](https://github.com/vercel/next.js/issues/43831) &
[PR](https://github.com/vercel/next.js/pull/55542)).
Ideally, when a runtime error happens after streaming, a `<meta
name="robots" content="noindex" />` would also be added. But I didn't
want to make the PR too complex before receiving feedback.
---------
Co-authored-by: Vũ Văn Dũng <me@joulev.dev>
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
follow up to #56898 where I noticed that we don't apply any filtering to the trace files for the user routes, resulting in files that would need to be filtered like `caniuse` not being filtered out correctly. This fixes that.
A lambda in my test project goes from `2.7MB` to `1.4MB`
followup: add some snapshot tests
before
```
Serverless function size info
Serverless Function's pages: _not-found.js, index.js
Large Dependencies Uncompressed size Compressed size
node_modules/.pnpm/next@13.5.6-canary.1_react-dom@18.2.0_react@18.2.0 4.61 MB 1.35 MB
node_modules/.pnpm/caniuse-lite@1.0.30001517 909.73 KB 327.14 KB
node_modules/.pnpm/react-dom@18.2.0_react@18.2.0 546.21 KB 138.87 KB
All dependencies 3.66 MB 2.01 MB
Serverless Function's page: favicon.ico.js
Large Dependencies Uncompressed size Compressed size
node_modules/.pnpm/next@13.5.6-canary.1_react-dom@18.2.0_react@18.2.0 6.71 MB 2.05 MB
node_modules/.pnpm/caniuse-lite@1.0.30001517 909.73 KB 327.14 KB
node_modules/.pnpm/react-dom@18.2.0_react@18.2.0 546.21 KB 138.87 KB
All dependencies 5.78 MB 2.71 MB
Serverless Function's page: api/hello-world.js
Large Dependencies Uncompressed size Compressed size
node_modules/.pnpm/next@13.5.6-canary.1_react-dom@18.2.0_react@18.2.0 4.61 MB 1.35 MB
node_modules/.pnpm/caniuse-lite@1.0.30001517 909.73 KB 327.14 KB
node_modules/.pnpm/react-dom@18.2.0_react@18.2.0 546.21 KB 138.87 KB
All dependencies 3.65 MB 2.01 MB
```
after
```
Large Dependencies Uncompressed size Compressed size
node_modules/.pnpm/file+next-canary+next-13.5.6-canary.1.tgz_react-dom@18.2.0_react@18.2.0 2.87 MB 844.1 KB
All dependencies 341.31 KB 992.45 KB
Serverless Function's page: favicon.ico.js
Large Dependencies Uncompressed size Compressed size
node_modules/.pnpm/file+next-canary+next-13.5.6-canary.1.tgz_react-dom@18.2.0_react@18.2.0 4.97 MB 1.52 MB
All dependencies 2.45 MB 1.67 MB
Serverless Function's page: api/hello-world.js
Large Dependencies Uncompressed size Compressed size
node_modules/.pnpm/file+next-canary+next-13.5.6-canary.1.tgz_react-dom@18.2.0_react@18.2.0 2.87 MB 844.1 KB
All dependencies 328.64 KB 989.23 KB
````
### What?
Update Babel packages across the board
### Why?
Since you ship vendored presets and plugins it's impossible for people to update this stuff at their own pace - independently from Next. So users of `next/babel` are currently stuck with old versions and, for example, they might not be able to use the TS `satisfies` operator.
### How?
I just updated ranges (to pinned ones) where I could find them, run `corepack pnpm i` and re-run build scripts in the `packages/next`.
Fixes#43799
Upgraded dotenv to v16. Breaking changes are:
- Multiline parsing support
- Support inline comments
- Backtick support
[See their changelog](https://github.com/motdotla/dotenv/blob/master/CHANGELOG.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
### What?
BREAKING CHANGE: Bump the minimum required Node.js version.
### Why?
Node.js 16 has reached end-of-life in September.
Bumped to `18.18.2` since it contained some security-related patches: https://nodejs.org/en/blog/vulnerability/october-2023-security-releases
### How?
Bumped `engines` where needed, upgraded the workflows.
This will allow us to remove quite a few polyfills, I'll open separate PRs for those.
Closes WEB-1702
This PR implements initial support for the `next/dynamic` in Turbopack,
more specifically resolving some hydration errors and other components
boot up cases.
Previously, turbopack had partial next/dynamic support via its own mode
(https://github.com/vercel/next.js/pull/56389/files#diff-e1af4f79cb88a73f819a25443d15ed4b1ffabcbb879256caa59b751fad46d7c4L68),
which does a transform against `next/dynamic` wrapped import to embed
dynamically resolvable chunk ids like
(ad42b610c2/packages/next-swc/crates/next-transform-dynamic/tests/fixture/wrapped-import/output-turbo-dev-server.js).
However, since next.js relies on static path to the chunks to the
dynamic import and passing those ids in between client-server to ensure
component load (and avoid hydration errors), it doesn't work out of the
box. This PR changes turbopack's behavior to closely mimic what current
next.js's webpack plugin does, by
1. Traverse the module graph, find out `dynamic(import())`
2. Generate chunks for those imports, creates a partial LoadableManifest
per each imports
3. Merge partial manifest into a single `react-loadable-manifest.json`
4. For the id, use static (Webpack mode) instead of dynamic so we can
embed it in `react-loadable-manifest` as well as next.js can use it to
pass it between server-client context.
I left a small comment to the implementation
(https://github.com/vercel/next.js/pull/56389/files#diff-bf12ed2c69d0bc89a06884779da4ae44967eb8becada031dea12bedef28e2622R155)
for the lifecycle of this feature in case to fix further.
This makes to pass most of the basic next-dynamic related integration
tests, except if the import have webpack specific features like
ad42b610c2/test/development/basic/next-dynamic/pages/dynamic/multiple-modules.js (L5).
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
This ensures `import url from 'url'` works in the edge runtime when using Turbopack. It also ensures the stubs for fetch / object.assignare applied to the client and edge compilation.
### Description
- Adds the page path to the middleware template (and also uses the template from the next.js loader)
- ESM aliases for the edge context
- Fix for the process polyfill to make it possible to import from `dist/esm`
- Fix for the `server-only`/`client-only` aliases
Closes WEB-1779
### What?
Adding back `x-forwarded-*` headers.
### Why?
Starting with #52492, these headers were lost.
### How?
We can populate these headers before executing a request.
Closes NEXT-1663
Fixes#55942
### What?
app code is different from pages code and need to be in a separate layer
### Why?
Otherwise it tries to share chunks and will cause conflicting writes
### How?
Closes WEB-1778
`useParams` is not referentially equal between renders which can lead to unexpected behavior when used as a dep.
This memoizes the response from `useParams` similar to `useSearchParams`.
[slack x-ref](https://vercel.slack.com/archives/C04DUD7EB1B/p1697145987740229)
This adds a new `Revalidate` type which is used internally by Next.js to associate the user inputted value of `revalidate` from `getStaticProps` or the exported `revalidate` variable in app directory.
This change is to pick the esm assets for RSC server layer and server rendering side, this is for production and development perf purpose, also to let them apply with the ESM related optimization such as tree-shaking, barrel files optimizations, etc.
We found a few packages that can't be optimized easily in bundling because we're using "main" field so the packages are not able to be tree-shaked, ending up with large bundle in the dist. This will change a lot for the bundling improvements as some packages are only having "main" and "module" field. So switching from CJS to ESM means better bundling, more optimization, and faster code.
#56501 was a precondition for this, as previously the bundling strategy was applied to some library but triggered the invalid hooks erroring.
### Other Monior Change
Previously we'll prefer to resolve CJS as there're 2 versions of react, using CJS assets will help let them pass by require-hook to use canary react for app router bundling assets. But now we changed the approach to bundling nextjs runtime and react packages. Now we dropped the condition that prefered to resolve CJS exports for externals, since if you're putting them in `serverComponentsExternalPackages`, they're not using the built-in react, so could potentially having trouble if any dependency is using react but excluded in bundles. So far we didn't see any report to this.
Closes NEXT-1286
While investigating the failing test case of `test/integration/scroll-forward-restoration/test/index.test.js` I found that navigating from `/another` to `/` using `next/link` with a `href="/"` errored on `ensurePage` as "this page was not built". Turns normalization wasn't applied on these so the input `page` was `/index` instead of `/`, where it expects `/` as the input.
Ensures the webpack-hmr socket is not reconnected infinitely while (and
very quickly) when the dev server is offline. I've implemented a gradual
backoff, after 5 tries at 1 second it'll try 20 times at 5 seconds.
After those 25 retries it reloads the page as something must be wrong
(i.e. the server is offline).
<!-- 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 an internal API and will be removed soon. Please do not use.
Refactors #56404 to have a better internal API used by both Edge SSR and Edge Route Handlers.
This new API can buffer non-synchronously created "waitUntil"s even after the response has been returned, just need to make sure that there's at least one "waitUntil" queued. E.g.:
```js
async function handler() {
internal_runWithWaitUntil(async () => { // ← no await
await taskA()
internal_runWithWaitUntil(async () => { // ← no await
await longRunningTaskB()
})
await taskC()
})
return Response(...)
}
```
Internally, the "waitUntil" promise will resolve after all tasks are finished.
cc @ijjk @cramforce @feedthejim as we've synced about some of the details here. Not using ALS because of some promise-related issues.
In [55841](https://github.com/vercel/next.js/pull/55841), this file was reworked to improve type safety and readability, but it changed the behavior of how we were invoking methods on the worker. Specifically, when a restart occurred, this timeout wrapping function was referencing an already ended worker, resulting in a "Farm is ended, no more calls can be done to it" build error.
This PR ensures that we're fetching the method from the current `this._worker` at the time of invocation, not at the time of method creation.
[Slack x-ref](https://vercel.slack.com/archives/C04KC8A53T7/p1697064752635179?thread_ts=1696952142.759769&cid=C04KC8A53T7)
The build manifest when using webpack includes the rewrites config so
that the Pages Router can correctly match the path. The manifest for
Turbopack was missing these properties which caused a bunch of the
middleware tests to fail. This PR reuses the function to generate
rewrites from build-manifest-plugin.
<!-- 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 #
-->
An issue discovered from #56502 in azure pipeline
```
> Build error occurred
ReferenceError: structuredClone is not defined
```
`structuredClone` is not supported until nodejs 17, here we actually don't need to use `structuredClone` as the values are almost primitives, the deepMerge case we're using mainly objects and array, which are already handled above
This PR splits apart the function used to render App Router pages into smaller chunks for better readability + testing. A lot of the complexity is tied by the fact that a lot of the code of the function relied on closures so I had to coalesce a lot of the captured variables used into one big context that is then passed around during render.
There are a lot of things to slim down further but I don't have the energy to dig more.
When there's a version skew, it might be possible that the Action's ID has changed and we're no longer able to locate it. By definition, that means we **should** return a 404 because it might have a different implementation now. Currently this throws a "cannot access workers of undefined" error which doesn't make sense.
Please review with whitespace ignored.
### Observed Issue
```
⚠ Restarted collecting page data for [object Object] because it took more than 60 seconds
```
### Fix
The original issue is caused because the path is assigned to the `argument` array itself. Passing the argument type to the he worker, so in restart callback we're type safe, can the value will be correct.
<!-- 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 a follow-up to #48018 (don't add `isolatedModules: true` to
`tsconfig.json` when `verbatimModuleSyntax: true` is set), which also
handles the case where `verbatimModuleSyntax: true` is set in a base
tsconfig which is being referenced via `tsconfig#extends`.
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
This is just moving the `wrappedRender` function out of the `renderToHTMLOrFlight` function so that it's defined in the module scope.
You'll want to turn on hide whitespace during review 😉
Discovered while investigating https://github.com/vercel/next.js/pull/56526, turns out errors occuring during webpack builds do not fail the `pnpm build` which kicks off `taskr`. This is because `taskr` runs their plugins within coroutines, which based on the result, was not handling the promise rejections as expected.
### What?
While debugging #56456, I noticed that we cut useful information, namely the `Error` instances' [`cause` property](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause).
### Why?
In #56456, it was hiding the following:
```sh
Error: getaddrinfo EAI_AGAIN undefined
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26)
at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -3001,
code: 'EAI_AGAIN',
syscall: 'getaddrinfo',
hostname: 'undefined'
}
```
which might be an indicator to the user what was going wrong with the `fetch` call.
### How?
If there is a `err.cause` property, log it together with `err.digest`
Note, this does not fix#56456 but might be useful to debug similar issues as well.
This applies the predefined list of packages in server-external-packages.json as always external when used by app router in Turbopack
Test Plan: Added integration tests
Closes WEB-1709
This PR flattens the recursive optimization logic of our barrel optimization loader. So now if there're any recursive `export * from ...`, they won't be created as multiple individual Webpack modules, but optimized in one module.
With this change, we are running SWC transform to get the export map directly inside the barrel loader (instead of a separate loader rule). And that map is recursively calculated and cached in memory.
I also published https://unpkg.com/browse/recursive-barrel@1.0.0/ to give this a test. It contains 4 levels of 10 `export *` expressions, which is 10,000 modules in total. Without this change, it takes ~30s to compile and with this change, it goes down to ~7s.
### What?
Step 3 in our chunking refactors extracts ChunkItem::as_chunk into a new ChunkType trait. This new trait isn't useful yet, but will eventually allow us to collect ChunkItems of a similar type into a lists, and perform chunking over all similar items at once.
### Why?
In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
https://github.com/vercel/turbo/pull/6123
Re: https://github.com/vercel/next.js/pull/56504
Closes WEB-1724
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
This PR fixes `next start` and `next dev` so that they show the correct server boot-up time. The previous way of computing the start time was incorrect and misleading as it did not start exactly when next started.
Before:
> ✓ Ready in 120ms
After:
> ✓ Ready in 286ms
### What?
The second step in our chunking refactoring, this removes our use of Module::as_chunk and Module::as_root_chunk. Instead, the only way to generate a chunk is directly from a root ChunkItem.
### Why?
In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
https://github.com/vercel/turbo/pull/6120
Re: https://github.com/vercel/next.js/pull/56467
Closes WEB-1721
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
When we landed #51179 it broke library like `apollo-client` as it's bundling client hooks into RSC bundle, so our RSC linter caught them and reported fatal errors. But those client hook APIs won't get executed in RSC. The original purpose of erroring on invalid hooks for server & client components was to catch bugs easier, but it might be too strict for the 3rd party libraries like `apollo-client` due to few reasons.
We changed the rules only applying on user land source code. For 3rd party packages if they're not being imported correctly into proper server or client components, we're still showing runtime errors instead of fatal build errors.
x-ref: https://github.com/apollographql/apollo-client/issues/10974
Closes NEXT-1673
This is the first in a series of PRs replacing our use of fs-extra with node's own `node:fs`.
Test Plan:
With clean and existing artifacts in each case, ran:
- `pnpm build`
- `pnpm dev`
- `./node_modules/.bin/taskr ncc`
Closes WEB-1717
### What?
This change moves a few methods around.
Module::as_chunk is moved to ChunkItem::as_chunk as temporary intermediate state.
EcmascriptPlaceable::as_chunk_item is moved to ChunkableModule::as_chunk_item. This generalizes the concept of converting a Module into a ChunkItem
### Why?
This is the first step of refactoring the chunking. In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
see https://github.com/vercel/turbo/pull/6104
Closes WEB-1715
Co-authored-by: Justin Ridgewell <112982+jridgewell@users.noreply.github.com>
This replaces the `(global as any)._nextDevHandlers` invocation with references to a specific service instance while also removing the module scoped `devInstances`. This ensures that correct types are used.
This was done while changing the `match` parameter in `ensurePage` to `definition` which didn't cause a typescript error (it should have).
