### What
* Error on case that readable stream controller tries to close but
stream is either errored or unfinished
* Delay the DOMContentLoaded event to avoid "Connection Closed" error
### Why
Regarding to the new error about readbale stream controller, the new
error we added here is for identifying the connection is closing before
the last bit has been received that's an error case not intentional
close. It's not a proper state for close more for erroring.
As for adding the queuing for the task of dom content loaded callback,
after investigation, I found that if the DOMLoaded execute earlier the
readable stream controller cuold close earlier on client, which lead to
the "Connection Closed." error. Hence we added a `queueMicroTask` here
to delay it after hydrate call.
x-ref: [slack
thread](https://vercel.slack.com/archives/C01A2M9R8RZ/p1715188343813489)
### What
It's not helpful to see the network issue of fetching error on reading
nextjs version in dev overlay
### Why
Error case:
<img width="400"
src="https://github.com/vercel/next.js/assets/4800338/a7852d9b-1f98-4098-8498-a3b832efdbb0">
This should just be ignored, it's fine that the fetching is failed.
There're so many fetch errors code, it's easy to try-catch on fetch
instead of enumerate all the codes
Using the hostname `::` enables dual-stack support. This prevents
`ECONNREFUSED` errors when running tests locally, and `localhost` being
resolved to `::1` (IPv6) instead of `127.0.0.1` (IPv4).
Updates `with-react-hook-form` example by bumping react-hook-form and
other dependencies to their latest versions, along with a minor cleanup
of the UI.
---------
Co-authored-by: Sam Ko <sam@vercel.com>
During integration testing, previously, calls to `next build` could rely
on the project (the Next.js project) level ESLint configuration. In
order to correct this, a new `lint` option was added to `nextBuild` that
can be passed to enabled linting. If this is `false` or `undefined`, a
`--no-lint` argument will be passed to `next build` to prevent it from
running.
Old logic from the pages router was previously being hit during
development. This was more apparent when PPR was enabled as it was
mixing dynamic + static rendering in development which propagated to
errors. This change ensures that requests that are made with `RSC: 1`
are not marked as `/_next/data` URL's, and don't use the same logic
paths.
Previously it was a bit confusing because we used the variable
`isDataReq` in a few places that made it hard to tell what it was
referring to. In this case, the `isDataReq` is actually only used by the
pages router. This renames the `isDataReq` to `isNextDataRequest` to
make it clearer, as well as refactors to ensure that it's not used in
the paths for app routes.
Also to better represent the rendering modes the `supportsDynamicHTML`
variable was renamed to `supportsDynamicResponse`.
Fixes#66241
Revert the revert in #66049
It was erroring in pages api with importing `react-dom/server` as this
is disallowed in app but shouldn't be in pages. It's caused by we're
validating middleware layer as server components but edge pages api is
still bundled in the same layer, where we shouldn't apply the check.
* Separate the api in api layers, and while handling middleware
warnings, checking api layer as well
* No need to check layers while handling externals in edge compiler
* Found a bug that we shouldn't check if `config.transpilePackages` is
defined then we enable `externalDir`, removed that condition. It fails
the telemetry tests case build with code change from this PR.
Add more tests for pages dir and middleware
| | `react` condition | `react-dom/server` condition |
| ---- | ---- | ---- |
| middleware (edge) | react-server | not allowed, failed with dev/build
checks |
| pages/api edge | default condition | default condition |
| pages/api node | default condition | default condition |
Updates `create-next-app` template CSS:
- Declares variable font weights in `localFont` options and removes
instances of `font-synthesis: none`
- Removes Geist font variables from Tailwind config files
- Adds fallback sans typefaces to the `body` CSS
Co-authored-by: Sam Ko <sam@vercel.com>
#64186 removed the pages router implementation from the `with-apollo`
example and replaced it with an app router implementation.
Unfortunately, it did so in an unsupported way.
At this point, we can not support any streaming SSR scenario without
additional helper packages - in the case of the app router, it is vital
to use the `@apollo/experimental-nextjs-app-support` package.
This PR switches the example to our officially supported patterns.
<!-- 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?
Updates create-next-app's templates' `.gitignore` files for parity with
[Yarn's official
recommendations](https://v3.yarnpkg.com/getting-started/qa#which-files-should-be-gitignored),
accounting for Yarn's modern Plug-n-Play functionality.
Fixes#65586
### Why?
New projects initialized with create-next-app presently add various
extraneous files from the Yarn cache to the initial commit. This is most
notable in the case of the Next SWC binary, which may exceed 100M in
some environments and prevent users from pushing their new projects to
free GitHub repositories without rewriting the commit history or setting
up Git LFS.
### How?
I've opted to follow the recommendations for
non-[Zero-Install](https://yarnpkg.com/features/caching#zero-installs)
configurations as Zero-Install may necessitate additional configuration
and present additional complications for unsuspecting users, so I think
it's best left up to the user to opt-in.
Contrary to the example `.gitignore`s provided by Yarn, I've excluded
the `.yarn/sdks` directory as it contains IDE-specific tooling which I
think is also best left up to the user to opt-in to including.
I have retained the current `.gitignore`'s exclusion of the `/.pnp`
directory for backwards compatibility with older versions of Yarn.
### What?
This fixes the "Migrating from Create React App" guide and add some
minor improvements
### Why?
The existing guide was broken due to `next start` not working anymore
when using `output: 'export'` and because the TypeScript configuration
was outdated.
### How?
I've validated the guide by going through each steps on [this
PR](https://github.com/IGassmann/cra-to-nextjs/pull/1).
---------
Co-authored-by: Lee Robinson <me@leerob.io>
### Why?
The current wording leaves room for questions/misinterpretations like:
- What does "use `src/`" mean? Does this affect my build, like compile
`src/*.ts` to `lib/*.js`?
- Oh, I can customize import aliases to use @ for project root instead
of doing relative everywhere? I'll choose Yes!
I think the proposed wording clarifies ^
---------
Co-authored-by: Sam Ko <sam@vercel.com>
This adds a new target in the next-swc package designed as an entrypoint
for collecting memory benches. Later PRs in the stack add a script to
run the benches and finally a manual-triggered CI step
We'd like to warn users if they have particularly slow file IO, so that they can correct the problem themselves, and don't send us reports of poor performance.
- Feature request: https://vercel.slack.com/archives/C03KAR5DCKC/p1716051650641529
- Tweet about how Bun does this: https://x.com/jarredsumner/status/1637549427677364224
- Bun implementation: 06a9aa80c3/src/install/install.zig (L3038)
**Why 100ms?** Bun used to use 10ms, found it too noisy, and switched to 100ms.
This benchmark should run non-blocking in the background and should not meaningfully slow down server startup (even on slow disks).
## Simulated Testing
I looked around and found https://github.com/schoentoon/slowpokefs/. It hasn't been updated in 10 years, but still seems to build fine.
In a nextjs project directory, turn `.next` into an artifically slow mount point:
```
fusermount -uz .next; rm -rf .next .next.real && mkdir .next .next.real && ~/slowpokefs/slowpokefs -m 50 -M 50 --no-slow-read -F .next.real .next
```
<img width="695" alt="Screenshot 2024-05-21 at 4 14 58 PM" src="https://github.com/vercel/next.js/assets/180404/217d7692-33cf-42b7-bbf7-5a530b9e0df1">
Run `pnpm dev --turbo` and see that the warning is generated.
## "Real World" Testing
The following tests are from a linux VM using virtiofs to connect to a 5400 RPM USB 2.0 HDD with APFS:
Only the .next is on an HDD (bind mount):
Otherwise idle disk: `4.86ms 4.44ms 5.31ms`
Otherwise busy disk (copying files): `69.34ms 53.75ms 25.12ms`
The whole project directory is on the HDD (more realistic):
Otherwise idle disk: `20.29ms 35.61ms 48.12ms`
Otherwise busy disk (copying files): `131.40ms 21.71ms 87.33ms`
Most of the time the threshold was not reached, but the 131.40ms test did trigger the warning!
Fixes PACK-3087
This reverts commit
637033c410.
What wasn't clear originally is that we require that required packages
have their `package.json` resolvable. So either they don't have an
`exports` field, or their `package.json` is listed in the `exports`
field. The React beta types didn't have `package.json` entry in
`exports` so we accidentally thought they weren't installed.
I published [`19.0.0-beta.2` that has `package.json` in
`exports`](13879ee571 (diff-81cc573aa0c2bd0e13f9463499747741704aabccd7474f544db710befd7bcfc4R44))
so we can restore the old behavior. It's still questionable IMO to do
all that I/O work just for a nicer error message that may contain
false-positive but that's for another time.
Alternative to https://github.com/vercel/next.js/pull/65867 this
stabilizes our `swrDelta` config that allows customizing the
`stale-while-revalidate` period that is included in the `Cache-Control`
header for ISR enabled routes.
This is not a breaking change itself as no default value is provided as
is the case already.
