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
`yarn pack` does not pack the same way that `npm pack` does. There is at least one bug with how files are treated where node_modules are ignored even inside folders defined by the files config. While this is not currently used in next.js an upcoming change will rely on it. The reason this change makes sense otherwise is we use npm to publish next and during a publish the pack from npm is used. For consistency we should use the same pack for our actions and other code that does repo setup such as `create-next-install` which is used for tests
The implementation is slightly more complicated than just replacing the pack command however. `npm pack` respects gitignore files whereas `yarn pack` does not (or at least not nested ones). For some packages the `"files"` property in package.json is set which overrides any gitignore rules however the `@next/swc` package uses a gitignore to prevent the committing of native binaries but does not use files and thus npm pack does not includes native binaries when yarn pack does. To address this the PR adds a temporary rename of the `next-swc/native/.gitignore` file which allows npm pack to mimic the yarn pack behavior. The reason I did not just add `"files"` is that this package actually publishes to many different package names on npm for each architecture and I was unsure about making changes to the package.json that would potentially affect this codepath.
In addition to those changes there are 2 `.gitignore` files that appear to be outdated and unnecessary. I removed them.
### 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.
At my work, we use Cloudflare as our CDN, and it has various optimization options for the served code including the "Auto Minify" feature that can minify JS, HTML and CSS to reduce download speed. After months of trying to update React to version 18, I have finally found out that the "Auto Minify" was the root cause of the problem, not anything in our code such as invalid tag nesting or printing dates. Because of that, I thought it would be helpful to add CDN as a possible place for investigating hydration errors.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
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.
### What?
Fixed a bug that the title of the topmost Docs was unclickable when less than 1024px.
### Why?
This appears to be due to the fact that these clickable elements are overlapped by the logo image wrapper in Next.js, preventing the propagation of click events for these elements.
### How?
To mitigate this problem, this PR assigns a z-index of -1 to the Next.js logo image wrapper. This change ensures the wrapper is placed beneath the clickable elements, thereby preventing it from blocking click events on smaller screens.
#### Before
https://github.com/vercel/next.js/assets/76232929/7b84737d-8a43-4c92-870e-86d08e4eaf74
#### After
https://github.com/vercel/next.js/assets/76232929/648b2e9b-33b5-4905-b10f-03904c1f7529
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`
- Remove specific TypeScript sections and add JS/TS code block toggles
- Consolidate "Good to know" information into sections
- Add links back to incrementally adopting the App Router when trying to
use escape hatches
- Add better TS example for `getInitialProps` (even tho it's not
recommended, still helpful)
Adds missing `Metadata` type to a few declarations.
---------
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### 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.
#52486
Here I fixed the typo error of fetchUsers to fetchUser in
docs/api-reference/04-functions/not-found.mdx
async function fetchUser(id) { // Here instead of fetchUsers i changed
it to fetchUser
const res = await fetch('https://...')
if (!res.ok) return undefined
return res.json()
}
export default async function Profile({ params }) {
const user = await fetchUser(params.id)
if (!user) {
notFound()
}
// ...
}
https://nextjs.org/docs/app/api-reference/functions/not-found
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
The `incrementalCacheHandlerPath` have to be under `experimental`.
And the path should use `path` library so that the custom cache handler can be used.
Hey Next.js Team, 👋🏻
I noticed Next.js apps scaffolded with create-next-app weren't prompting me for the TypeScript workspace version in VS Code. After digging through the repo, I stumbled on this https://github.com/vercel/next.js/pull/49133 PR from Tim. While this PR explains why it was removed, I'm not sure the docs were ever updated to reflect this change.
This PR aims to address that with a simple note in the TypeScript Plugin section of the TypeScript docs page.
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
