### 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.
### 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.
This PR changes the `getWaitUntil` logic to always check if the platform
provided a request context with a `waitUntil` implementation (via [the
`@next/request-context`
symbol](05e6b82576/packages/next/src/server/after/wait-until-builtin.ts (L12)))
, regardless of minimalMode or runtime.
Previously, we wouldn't check the context at all unless `minimalMode`
was set, and defaulted `waitUntil` to a noop otherwise. This would make
integration more difficult for providers who don't use `minimalMode`,
because they'd have no way to inject their `waitUntil` implementation.
Ensures that app routes (like the `favicon.ico` added in the test case
in this PR which is represented as an app route) do not have a prefetch
RSC also attached.
## Background
Previously we introduced automatic caching for `fetch` based on certain
heuristics that were a bit tricky to grasp all scenarios. The scenarios
we would automatically cache were no dynamic data access before the
fetch call e.g. `headers()` or `cookies()`, the fetch call is inside of
a dynamic page e.g. `POST` method or `export const revalidate = 0` page
and the fetch is a non-`GET` request or has `Authorization` or `Cookie`
headers, or the fetch had `cache: 'no-store' | 'no-cache'` or
`revalidate: 0`.
## New Behavior
By default fetches will no longer automatically be cached. Instead they
need to be opted-in to caching via `export const fetchCache =
'default-cache' | 'force-cache',` `next: { revalidate: false or value >
0 }` or `cache: 'force-cache' | 'default-cache'`.
When the fetch call is automatically skipping the cache it won't impact
the page level ISR cacheability although if a fetch call manually
specifies `cache: 'no-store'` or `revalidate: 0` it will still bail from
the page being statically generated as it was before.
To achieve the previous behavior of automatic fetch caching all that
needs to be added is `export const fetchCache = 'default-cache'` in the
root layout(s) of your project.
When hot-reloading an edge runtime page, sometimes we randomly get this:
```
[InvariantError: Invariant: Cannot call onClose on a response that is already sent. This is a bug in Next.js.] {
name: 'InvariantError'
}
```
and since `unstable_after` relies on `onClose`, no callbacks are called.
I believe this is because `web-server` [calls `res.send()` pretty early
for streaming
responses](b9817f8351/packages/next/src/server/web-server.ts (L311)),
so `res.sent` becomes `true` even though we're still streaming, and
prevents us from calling `onClose` in the streaming render. It makes
more sense to check the CloseController's `isClosed` instead -- when
that becomes `true`, we _really_ shouldn't call onClose anymore (points
to a bug), but before that it's fine.
Follow-up to https://github.com/vercel/next.js/pull/65825 this ensures
we don't skip the static optimization specifically for metadata routes
as this most often should be static as they aren't dynamic content and
are requested very frequently.
This PR adds a flag to Next.js to enable Webpack options to improve
memory usage. See https://github.com/webpack/webpack-sources/pull/155
for a full description of the changes and impact on memory.
This PR adds a patch to `webpack-sources` temporarily that contains the
fixes as the real changes are iterated on to merge upstream in the
`webpack/webpack-sources` repository. After that is done, the patch will
be reverted and the latest `webpack-sources` version will be updated in
Next.js.
To avoid extra network hops we can compare existing cache entries we've
already fetched and see if the revalidated value matches and if it does
we can avoid sending the set request with the identical data.
As noted in (https://github.com/vercel/nextpack/pull/103), by not having
this as a default feature, when running the `build-native` script it's
not able to re-use any cargo caches that might already exist from a
default build.
Because this feature impacts the swc crate, everything dependent on it
can be forced to rebuild.
By making this a default feature, the hope/theory is that the number of
different ways we potentially build our dependency graph reduces, and
cargo cache hits will improve.
## Changes
- Add `plugin` to the default set of features for `next-swc-napi`.
- Consolidate `build-native-no-plugin-woa` with
`build-native-no-plugin`. Given the lack of any other default features,
these are equivalent.
- `i686-pc-windows-msvc`: Switch to `build-native-no-plugin-release` in
CI instead of just supplying the `--release` flag. This has the benefit
of also enabling `tracing/release_max_level_info`, which might reduce
the size of or speed up these builds.
- `x86_64-apple-darwin`: Remove a redundant `--release` flag in the CI
config (no expected changes).
## Testing
I've tested this locally on Linux (`pnpm run build-native`) and
Windows-on-ARM (`pnpm run build-native-no-plugin`) by making sure things
still build. I'll also make sure CI passes.
This parameter was previously used for a warning message, but we no
longer print that warning since
https://github.com/vercel/next.js/pull/63321 so now we can remove the
unused parameter.
Previously with Turbopack, we would attempt to establish a websocket
connection to the HMR server, even when running production builds. This
adds `next-turbopack.ts`, which includes the necessary runtime code for
Turbopack, but does not include HMR code.
Test Plan: `TURBOPACK=1 TURBOPACK_BUILD=1 pnpm next build
test/e2e/app-dir/app-middleware`
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
This configures the default client router cache `staleTime.dynamic`
value to be `0`.
This means that:
- Navigating between pages will always fire off a network request to get
RSC data for the page segment, rather than restoring from router cache
- Loading states will remain cached for 5 minutes (or whatever
`config.experimental.staleTimes.static` is set to)
- Shared layout data will continue to remain cached due to [partial
rendering](https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)
- Back/forward behavior will still restore from cache to ensure the
browser can restore scroll position.
It's possible to opt-out of this, and into the previous behavior, by
setting the
[`staleTimes`](https://nextjs.org/docs/app/api-reference/next-config-js/staleTimes)
config in `next.config.js`:
```js
/** @type {import('next').NextConfig} */
const nextConfig = {
experimental: {
staleTimes: {
dynamic: 30
},
},
}
module.exports = nextConfig
```
<!-- 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 reverts the below changes to avoid a breaking change in pages with
importing `react-dom/server` as this is disallowed in `app` but
shouldn't be in `pages`.
Revert "Bundle the installed react for middleware (#65811)"
Revert "Error in build for middleware when import client-only (#65792)"
This reverts commit fdd8f0c65f.
This reverts commit 082072ca95.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1716305493514869)
Updates the `create-next-app` template CSS to:
- Prevent browsers (e.g. Safari) from using synthetic bold font weights
- Move CSS variables out of global CSS / Tailwind config, to simplify
the process of wiping the default template.
<!-- 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 #
-->
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Background
Currently route handlers will be attempted to statically generate the
same as normal pages in app router. If a route handler accessed dynamic
data such as `cookies()`, `headers()`, `req.url`, or similar we would
bail from this static generation but this didn't handle the case where
you would do data fetching via a non-fetch based library e.g. `redis` or
even using `Date.now()` or `Math.random()` so users would expect these
to be run every request like normal API endpoints but they would be
static so wouldn't be executed again after a build.
## New Behavior
As discussed this disable the default static generation handling for
route handlers as we've seen this confuse our users since in most cases
when creating a route handler you are handling dynamic workloads. This
doesn't remove the ability to static generate route handlers though as
you can still manually specify:
If you specify `export const revalidate = 1` we will still bail if
dynamic data is accessed to prevent accidental `revalidate` configuring
but this can be avoided via `force-static` being used as well.
```js
export const dynamic = 'force-static'
// or
export const dynamic = 'error'
// or
export const revalidate = false
// or
export const revalidate = 1 // value great than 0
// or
export const generateStaticParams() {}
```
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Depends on vercel/turbo#8165
This:
- Creates and uses a `BeforeResolvePlugin` to handle requests to
`next/font/local/target.css` instead of `ImportMapping` replacers
- Returns a `ResolveResultItem::Error` which includes a custom
`StyledString` describing the missing font file
Test Plan: `TURBOPACK=1 pnpm test-dev
test/e2e/app-dir/next-font/next-font.test.ts`
This PR addresses an issue where the `dev` script in `package.json` was
not correctly updated to use the `--turbo` option when specified. The
changes ensure that the `dev` script is set to `next dev --turbo` if the
`turbo` option is enabled.
### Changes:
1. **Function Modification**:
- Updated the `modifyPackageJson` function to include a check for the
`turbo` parameter.
- If `turbo` is true, the `dev` script in `package.json` is set to `next
dev --turbo`.
- If `turbo` is false, the `dev` script remains `next dev`.
2. **Integration in App Creation**:
- Integrated the `modifyPackageJson` function into the app creation
process to ensure the `dev` script is correctly set based on the `turbo`
parameter.
### Testing:
- Verified that the `dev` script in `package.json` is correctly updated
to `next dev --turbo` when the `turbo` option is enabled.
- Ensured that the `dev` script remains `next dev` when the `turbo`
option is not enabled.
### Related Issues:
- Fixes#65924
### Notes:
- This change ensures that developers opting to use Turbopack for
development will have the correct script set up automatically.
---------
Signed-off-by: Arindam Majumder <arindammajumder2020@gmail.com>
Co-authored-by: Lee Robinson <me@leerob.io>
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Sam Ko <sam@vercel.com>
