Long-hanging promises are retaining the closure context where it's being
`await`'ed even it's resolved already. You can tell it from this
screenshot:
<img width="1822" alt="CleanShot 2023-07-13 at 18 09 11@2x"
src="https://github.com/vercel/next.js/assets/3676859/1d6210b0-16ba-440e-a8b6-c8c4343f4850">
In some cases, the entire `req` object is retained because of that. This
increases the memory usage a bit.
So this PR changes these promises to be cleaned up after they got
resolved.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Creates a NAPI api for Next.rs to be used in Next.js
### Why?
### How?
Co-authored-by: Alex Kirszenberg <1621758+alexkirsz@users.noreply.github.com>
We have some special bundle path handling logic for `/index` routes in
`normalizePagePath`, which is missing in the new
`AppBundlePathNormalizer`. This already broke `/index/page.js` in dev in
the past, and now become noticeable in prod as well because of the
manifest change.
b98469c86b/packages/next/src/shared/lib/page-path/normalize-page-path.ts (L5-L14)
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Introduce a new way to search for `not-found` component that based on
the request pathname and current loader tree of that route. And we
search the proper not-found in the finall catch closure of app
rendering, so that we don't have to pass down the root layout to
app-router to create the extra error boundary.
This ensures the root layout doesn't have duplicated rendering for
normal requests
Fixes NEXT-1220
Fixes#49115
Transitions the App Pages renderer into the entrypoint bundle.
- Adjusts the static path detection to handle route module's with App Pages
- Fixes bug in font manifest loading on Edge
Related: https://github.com/vercel/next-telemetry/pull/106
We collect wasm fallback reason (`enabled`, `fallback`, ..) but it is bit unclear why we came to reach `fallback` state for the wasm. This PR expands current reporting to include native bindings error code if node.js returns it to understand categories better. Mostly this would be in between ERR_DLOPEN or ERR_MODULE_NOT_FOUND, but worth to confirm if the guess is correct. For the targets have multiple triples (gnu / musl), we collect only the last attempt's error code.
There are 2 custom variants of the string value other than err code itself: if thrown error doesn't have code (unlikely, but) it'll be `unknown`. for the targets we falls back to wasm immediately (freebsd, for example) it'll be marked as unsupported_target.
One thing to note is this does not collect if wasm binding fails to load: this is strictly for native bindings load error.
### What? Why? How?
Similar to https://github.com/vercel/next.js/pull/47571, add `.js` extensions to generated imports to avoid problems with TypeScript `Node16` / `NodeNext` module resolution
Without this change, there are confusing errors with `{ experimental: { typedRoutes: true } }` in `next.config.js`, such as:
```
Property 'refresh' does not exist on type 'AppRouterInstance'.ts(2339)
```
<img width="490" alt="Screenshot 2023-07-11 at 19 12 21" src="https://github.com/vercel/next.js/assets/1935696/399265e6-223d-4386-bc85-6136d98e436a">
cc @shuding
This PR ensures that both Webpack and the config won't be initiated in render workers. This is great for performance but also avoids potential issues (e.g. Next.js plugin with side effects). Instead, we pass a serialized config from the router worker to the render workers.
Closes#52366.
This PR adds proof-of-concept support for the App Router to `next build
--experimental-turbo`.
It introduces a new way to generate Next.js manifests in Turbopack.
Currently, in dev, we pass proxy objects in lieu of manifests, and rely
on the entries to know which chunks they need loaded on the client.
However, this can't work for builds because it requires control over
Next.js rendering, which is not compatible with a Next->Turbo approach.
We would need to modify Next.js to support these "lazy" entries. So for
now, we add well-known assets (`NextDynamicAsset`,
`NextServerComponentAsset`, `NextClientReferenceAsset`, etc.) to the
graph, which will get picked up when walking it during asset processing.
This lets us collect all possible entries before chunking.
This two-step process (collecting all entries, then chunking them) is
also a good first step towards production chunking.
## Turbopack updates
* https://github.com/vercel/turbo/pull/5494 <!-- Tobias Koppers - add
reporting of console messages -->
* https://github.com/vercel/turbo/pull/5448 <!-- Alex Kirszenberg -
Misc. changes to support App Router build -->
### 🧐 What's in there?
At the moment, it is not possible to test code with `import 'server-only'` in app directory.
When trying to load such file in jest (even with `testEnvironment: node`), the error will be:
```
● Test suite failed to run··
x NEXT_RSC_ERR_CLIENT_IMPORT: server-only
,-[lib/util.js:1:1]
1 | /** @jest-environment node */·
2 | import 'server-only'
: ^^^^^^^^^^^^^^^^^^^^
3 | export const PI = 3.14;
`----·
at Object.transformSync (node_modules/next/src/build/swc/index.ts:443:25)
at transformSync (node_modules/next/src/build/swc/index.ts:629:19)
at Object.process (node_modules/next/src/build/swc/jest-transformer.ts:117:25)
at ScriptTransformer.transformSource (node_modules/@jest/transform/build/ScriptTransformer.js:619:31)
at ScriptTransformer._transformAndBuildScript (node_modules/@jest/transform/build/ScriptTransformer.js:765:40)
at ScriptTransformer.transform (node_modules/@jest/transform/build/ScriptTransformer.js:822:19)·
```
In a nutshell:
- next/swc is looking for ‘server-only’ [text in the source](https://github.com/vercel/next.js/blob/canary/packages/next-swc/crates/core/src/react_server_components.rs#L576), and throw if not configured for server
- next's jest-transformer will only configure next/swc for server [if the environment is node](https://github.com/vercel/next.js/blob/canary/packages/next/src/build/swc/jest-transformer.ts#L88)
- when testing Next.js apps, your jest testEnvironment is most likely jsdom. But you can configure it [per file with docBlock](https://jestjs.io/docs/configuration#testenvironment-string), which jest-transformer ignores because it only reads the top-level configuration.
This PR fixes this, by
1. reading the docblock to configure next/swc accordingly and bypass its hardcoded guard
2. mocking `server-only` so [it does not throw](https://github.com/vercel/next.js/blob/canary/packages/next/src/compiled/server-only/index.js) when loaded (jest does not read `react-server` export from package.json)
Users would still have to annotate their `server-only` files with `/** @jest-environment node */` in order to test them.
### 🧪 How to test?
There's a full test available: `pnpm testheadless --testPathPattern jest/server-only`
Here is also a minimal reproduction:
<details>
<summary>app/layout.tsx</summary>
```typescript
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (<html lang="en"><body>{children}</body></html>)
}
```
</details>
<details>
<summary>app/page.tsx</summary>
```typescript
import { PI } from '@/lib/utils'
export default function Home() {
return <h1>{PI}</h1>
}
```
</details>
<details>
<summary>lib/utils.ts</summary>
```typescript
import 'server-only'
export const PI = 3.14
```
</details>
<details>
<summary>lib/utils.test.ts</summary>
```typescript
import { PI } from './utils'
it('works', () => expect(PI).toEqual(3.14))
```
</details>
<details>
<summary>jest.config.js</summary>
```typescript
const nextJest = require('next/jest')
module.exports = nextJest({ dir: './' })({ testEnvironment: 'jsdom' })
```
</details>
### ❗ Notes to reviewers
[jest-docblock](https://packagephobia.com/result?p=jest-docblock) with dependencies is only 12.5 kB.
Fixes#47448
Previously `global-error` only caught the error on client side, this PR adds the support for catching the errors thrown during client components SSR or server components RSC rendering.
Closes#46572Closes#50119Closes#50723
### What?
Attempt to close WEB-1074.
PR tries to validate custom babel config: if it only contains options supported by latest next.js compiler features, trying to suggest to migrate / enable native compiler instead of babel.
### What?
The type definition of `ImgProps` is the following:
```typescript
export type ImgProps = Omit<ImageProps, 'src' | 'alt' | 'loader'> & {
loading: LoadingValue
width: number | undefined
height: number | undefined
style: NonNullable<JSX.IntrinsicElements['img']['style']>
sizes: string | undefined
srcSet: string | undefined
src: string
}
```
`ImgProps` is then used as part of the definition of the `ImageElementProps` type. For the latter, `Omit<ImageProps, 'src' | 'alt' | 'loader'>` is intersected with `ImgProps` even though the intersection with that type is already part `ImgProps`'s definition. This PR removes the redundancy.
### Why?
I was looking at how Next.js implemented it's optimized image component to create something similar for a WASM framework when I noticed this typing and got confused. I figured making a PR would be the polite thing to do.
### How?
Removed redundant part of type definition.
This PR:
- adds a minified bundled server for Next with some optimisations applied
- a test server in minimal-server.js
- misc changes:
- makes some polyfills lazy
- adds a cached version of node-html-parser
-
The problem was introduced in #52450, that the client reference manifest isn't being tracked and included in the function.
Verified that this fixes the issue.
This pull request:
- removes unnecessary object copying in `hasEslintConfiguration`
- returns always `null` on `runLintCheck`, and make sure it does not return undefined.
- removes unnecessary async scope creation on `isDirectory`
### What?
This PR fixes build crashing when `output: 'standalone'` and `experimental.appDir` is enabled but there is no app pages.
### How?
It does that by checking whether `.next/server/app` exists before copying the folder to `.next/standalone/...`
Closes#51828Fixes#44442Fixes#44120
This PR changes client manifest generation process. Instead of one big
manifest file that contains client references for the entire app, we're
now generating one manifest file per entry which only covers client
components that can be reached in the module graph.
Metadata API should provide a way to override the filebased metadata
images. As usually for child routes, if there's new social images or
icons are provided, the ones from parent routes should be overridden /
skipped.
The `metadata` object export or `generateMetadata` should be able to do
that. Sometimes users still add other og info (besides images) to
metadata export (both object and `generateMetadata`).
I think we should check if they really have returned images property,
then decide to override.
- For the same level of routes:
- If there's no `openGraph.images` in the returned value, merge with
file based images
- If there's any `openGraph.images` in the returned value, ignore file
based ones
- For child level of routes:
Always override the parent level, ignoring parent level file based
images unless they use `generateMetadata` to merge from
`resolvingParentMetadata` value, then the parent level's file based ones
will present there
Closes NEXT-1418
After we separating the metadata routes to a separate layer, we didn't apply the webpack alias rules properly to it as it's should still be treated as pure "server" side
This PR fixes the aliasing for that new metadata layer and make it working properly with "server-only"
Fixes#52390
This should resolve part of the `MaxListenersExceededWarning` problem mentioned in #50909. When there are too many concurrent requests sent to the dev server, we only need to handle the first.
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
This reverts the change to the pages render until a more substantial refactor can ensure that using the custom `app.render` method will attach a match to the request metadata.
- Fixes#52384
The performance of the current implementation can be improved by using
`URL.canParse` which is pending for backport to Node 18 right now. This
pull request also reduces the usage of try/catch in the happy path.
Follow up for #52196
The og title should be always resolved as `AbsoluteTemplate`. Move all the title resolving inside the og metadata resolving, so that it's aligned with type. And we don't have to check title everywhere, when og/twitter metadata is resolved, `title` is always presented as a property with `AbsoluteTemplate` type
Closes NEXT-1399
### What?
HMR causes infinite reloads for parallel routes when the corresponding page component is nested
### Why?
In 4900fa21b078fd1ec1adc5d570fcfb560be8aeb6, code was added to remove `/@children` from the page path (if present) but in 59b36349eb86427ac7b679ac62fa6628c9fc4886, `normalizeParallelKey` removes the @ prefix from children, so this doesn't seem to be catching the scenario it was intended to prevent
### How?
This updates the existing replace logic to consider `/children/page` rather than `/@children/page` -- it doesn't seem like `/@children` is a valid scenario given the `normalizeParallelKey` behavior
Fixes#52342 and addresses the concerns in https://github.com/vercel/next.js/pull/52061#issuecomment-1619145129
This pull request replaces `fs.readdir` with `fs.opendir` for better memory usage. `fs.readdir` consumes the path and only returns value when the iteration is finished, but `fs.opendir` both returns `fs.Dirent` which is better, since we are calling an additional `fs.stat` for each iteration, but also streams the output, so that we don't store the whole array of inputs in the memory.
There is no need to make a `fs.statSync` call for each file while reading a directory, since `fs.readdirSync` supports `withFileTypes` property that returns a `fs.Dirent` which includes the necessary information for detecting if the particular item is directory or not.
