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)
Noticed while testing turbopack version of tests that we weren't loading
the correct swc binary since this path wasn't absolute and was just the
relative path in `node_modules`.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Since, https://github.com/vercel/next.js/pull/65830, I've been seeing
weird flakes from
`test/e2e/app-dir/app-invalid-revalidate/app-invalid-revalidate.test.ts`.
```
TIMED OUT: /Invalid revalidate value "1" on "\/", must be a non-negative number or "false"/
```
The build output looks like this:
```
▲ Next.js 14.3.0-canary.73
Creating an optimized production build ...
[snip]
Error: Invalid revalidate value "1" on "/_not-found", must be a non-negative number or "false"
[snip]
Generating static pages (2/4)
> Build error occurred
Error: Export encountered an error on /_not-found, exiting due to prerenderEarlyExit: true being set
```
Note that there's no `Invalid revalidate value "1"` message for `/`, so
the test will fail.
This looks like a race condition: the invalid `revalidate` value is set
in a layout, so if `_not-found` happens to be prerendered before `/`,
it'll abort the whole prerender (because of `prerenderEarlyExit: true`).
so if the timing is right, the test -- which is looking for build errors
for `/` -- will never see them and time out.
There might be more of these, but unfortunately they're basically race
conditions, so I think we'll have to squash them as they come up.
CC @ijjk
## 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>
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>
Currently `OPTIONS` requests to page handlers (eg `pages/foo.tsx` or
`app/foo/page.tsx`) will respond as though it's handling a `GET`
request. There should be no reason for these routes to handle `OPTIONS`
requests as the only valid option is `GET`.
We do not need to special-case actions here because those will always be
invoked from the same origin as the canonical browser URL.
<!-- 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 #
-->
Closes NEXT-3305
## Background
Historically during prerendering we have waiting until all paths have
been attempted before we exit the process and fail the build. This is
nice if you want to collect all potential errors to address them at the
same time although this has the drawback of slowing down builds if
things are timing out or if the same error is occurring across numerous
paths.
## New Behavior
This changes our default behavior to immediately exit when the first
error occurs during prerendering so that builds don't stall out from
timeout errors or from the same error occurring across numerous paths.
This will help from holding up CI or similar un-necessarily.
If users want to opt-in to the previous behavior the flag is still
present under `experimental.prerenderEarlyExit`.
cc @icyJoseph @ztanner
NOTE: The canary release
[`v14.1.1-canary.51`](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.51)
and below work as expected.
### Why?
Introduced from #61535, the initial prefetch cache is set based on the
`location.pathname`.
When a page is loaded WITH the search param, the cache key does not
contain information of the search param.
The issue is when on a dynamic page reading the `searchParams` value,
the value doesn't change if navigated as:
```
/?q=foo --> /
```
The prefetch cache hits, not re-rendering, and the `searchParams` value
is not passed properly.
### How?
For the prefetch cache, add the `location.search` as well.
Since `createPrefetchCacheKey` uses
[`createHrefFromUrl`](https://github.com/vercel/next.js/blob/canary/packages/next/src/client/components/router-reducer/create-href-from-url.ts)
which includes `location.search`, I'm expecting the change won't affect
current cache key behavior.
Fixes#64170Fixes#65030
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Adds support for nested `unstable_after()`.
This pattern previously threw a "Not supported yet" error, but works
now:
```js
function MyComponent() {
after(() => asyncWork());
return <div>...</div>
}
async function asyncWork() {
after(() => { /* look ma, nesting!*/ })
// more stuff...
}
```
### Implementation notes
Switched `AfterContext` to use a proper promise queue
([`p-queue`](https://www.npmjs.com/package/p-queue)) instead of plain a
callback array to support adding more callbacks as we execute (i.e. from
nested `after`s). Used a package because I didn't want to reinvent the
wheel here.
As a nice bonus, `p-queue` lets us limit the concurrency of running
tasks if we're worried about resource consumption. **This PR doesn't do
that**, but it's very easy to add. That could be controlled via
`process.env.NEXT_AFTER_MAX_CONCURRENT_TASKS`, a next.config.js option
(`unstable_after: { maxConcurrentTasks: 5 }`), or something like that.
### What?
Upgrades sharp to the latest version and relies on more of its default
settings (if the default settings are unsuitable, we should consider
improving these for all users in sharp itself).
- The `sequentialRead` setting is now managed for you based on each
input image and the operations to be applied to it.
- The concurrency detection is more accurate than `os.cpus()` as it now
inspects things like CPU set/affinity as well as the memory allocator.
- The (mostly archaic) concept of chroma subsampling is not required for
AVIF output. Using full chroma should improve the quality of red/orange
edges, as well as slightly reducing file size as it allows greater use
of AV1 chroma-from-luma prediction.
In addition, this PR also enables the use of mozjpeg features such as
trellis quantisation to produce smaller file sizes. The use of `mozjpeg:
true` infers `progressive: true`. This aligns JPEG output behaviour with
the previously-used squoosh, which always used mozjpeg.
/cc @styfle
Implements `unstable_after`, which lets the user schedule work to be
executed after the response is finished.
### Implementation notes
- `unstable_after()` is a dynamic function (bypassable only with `export
dynamic = "force-static"`)
- Usable in: server components (including `generateMetadata`), actions,
route handlers, middleware
- It is meant to run its callbacks even if a response didn't complete
successfully (thrown error) or called `notFound()`/`redirect()`
- Currently gated behind a `experimental.after` feature flag, because it
touches many runtime bits (including a React monkeypatch...)
- The state for `unstable_after()` in a given request lives in
`requestAsyncStorage` (added via `RequestAsyncStorageWrapper`)
- the implementation is based around two functions that we inject via
`renderOpts`:
- `waitUntil(promise)` - keep a function invocation alive until a
promise settles. it is provided as a platform primitive in serverless
contexts, and a noop in `next start`
- for serverless (nodejs), Next.js will attempt to get `waitUntil` from
`globalThis[Symbol.for('@next/request-context')].get().waitUntil`. This
should be considered unstable for now. See
`packages/next/src/server/after/wait-until-builtin.ts` for details.
- `onClose(callback)` **[NEW]** - run something when a response is done.
basically `res.on('close', callback)`, but also implemented for Web APIs
- unfortunately, for Web, this requires some potentially expensive
tricks - see `packages/next/src/server/web/web-on-close.ts`
the 'should show an experimental warning' test in
`react-compiler-test.ts` has been randomly flaking for me:
```
Expected substring: "Experiments (use with caution)"
Received string: " ⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
▲ Next.js 14.3.0-canary.69
- Local: http://localhost:40095
"
```
when the actual CLI output is:
```
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
▲ Next.js 14.3.0-canary.69
- Local: http://localhost:40095
- Experiments (use with caution):
· reactCompiler
```
which indicates that we're reading the CLI output too early
### What
Error when users installing react@18 and requires higher version
### Why
The architecture now already requires to have `react@beta` or
`react@rc`. Especially where we need to load `react-server` condition of
react, which is erroring now in react 18.
- Ensure React Compiler runs on first-party code in Turbopack (Excludes
node_modules, but also fully skips running Babel on node_modules)
- Ensure React Compiler runs on first-party code in Webpack (Excludes
node_modules, but also fully skips running Babel on node_modules)
- Ensure React Compiler only runs on browser code -- Per React team
recommendation, it only optimizes browser-facing code currently.
- Ensure React Compiler runs on Pages Router in Webpack -- Was already
the case for Turbopack.
<!-- 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
Fix a bug introduced in #65694 , use app-page runtime for app router
layers
### Why
This is basically reverted the route context picking up logic we had
before.
During the test we found the error thrown
> Module not found: shared-runtime module router-context cannot be used
in rsc layer
Which is caused by a `next/router` imports in rsc page. Decided to
revert to what it was before as the most safe way to load share module
contexts.
It's caused by `next-contentlayer` usage that they're using
`next/router` in server component MDX, but we cannot lint error that
from node_modules. (We actually can, but disabled that due to various
mis-usage of server/client hooks we had before)
In `test/production/graceful-shutdown/index.test.ts`, 2 tests cases are
always failing, disabled them for now to investigate later.
In
`test/e2e/app-dir/actions-allowed-origins/app-action-allowed-origins.test.ts`,
the hard-coded `port` was used sometimes already been used, so we change
that to a "random" port which can help find an available port instead of
`'0'`.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
This PR exposes new experimental configuration for next.js,
`experimental.reactCompiler`. Under the hood, this option configures to
use new experimental react compiler
(https://react.dev/learn/react-compiler#). `reactCompiler` value can be
either boolean or an object contains partial set of compiler itself's
configuration option.
For the webpack and turbopack both it is enabled by adding a babel
plugin for the react compiler. If user have an existing .babelrc, plugin
will be appended to the config. Otherwise, swc will still kicks in (for
webpack) or turbopack for the general transform but only compiler babel
plugin will run via babel.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
This PR sets the upstream image timeout to 7 seconds so its not
unbounded (P99 is about 3 to 4 seconds).
We also set the sharp timeout to 7 seconds (P99 is about 2 seconds
although it depends on CPU).
This means an image could take at most 14 seconds to fetch and optimize.
When we provide the `set-cookie` string in `x-middleware-set-cookie`, we
need to ensure that multiple values are properly delimited.
We also make sure the cookies that get passed into `RequestCookies`
aren't in `ResponseCookie` form, to prevent something like `Path=/` from
being part of `cookies()`.
<!-- 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
Let `middleware` and `instrumentation` apply `react-server` exports
condition names first. When bundle the react and react-dom, bundle the
installed version instead of the built-in version.
Renamed "app" group for webpack layers to "bundled", which indicates it
will bundle all the dependencies.
### Why
Middleware and instrument are sort of isolated from app router and pages
router, if they're using react should pick up from the installed
version. Since they're in server layer so they only need to bundle the
`react-server` conditions.
x-ref: [slack
thread](https://vercel.slack.com/archives/C046HAU4H7F/p1715790385748169)
This PR ensures that any arbitrary binary data can be passed across the
RSC boundary, especially when inlined in HTML. While the Flight payloads
in RSC requests (`text/x-component`) already work, it's a different case
when we inline them directly in HTML as that's required to be a valid
string in UTF-8.
So instead of always inlining the UTF-8 decoded chunk (`new
TextDecoder('utf-8')`), we fallback non-decodable chunks to base64 and
send as a special item in `__next_f` so we can safely change it back to
a binary typed array.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR introduces a **breaking change** that returns a 400 error if the
Image Optimization API is given a protocol-relative URL.
The Image Optimization API currently checks whether the given image URL
is relative by checking `url.startsWith('/')`. This means that
protocol-relative URLs, such as `//example.com`, pass the check and are
treated as relative. They in turn skip any kind of validation provided
when matching against `remotePatterns` and are passed back to the
optimation logic as a relative URL.
My knowledge of the stack stops there, but in our case at GitBook it led
to a nasty attack where non-GitBook content could be served over this
URL: https://docs.gitbook.com/_next/image?url=//example.com&w=1200&q=100
- even though we have configured `remotePatterns` to protect against it.
I originally went into the problem wanting to handle the URL properly
(treating it as an absolute URL and potentially using the protocol of
the Optimization API itself as the relative protocol), but after seeing
the code in
https://github.com/vercel/next.js/blob/canary/packages/next/src/client/legacy/image.tsx#L135
and
https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/image-loader.ts#L26
it feels that protocol-relative URLs are just not really supported
anywhere. My understanding is that very few uses of `next/image` will be
allowed to use protocol-relative URLs, so the impact of this breaking
change should be quite low? If others disagree I am happy to modify and
to use the protocol of the request as a stand-in for the relative
protocol.
---------
Co-authored-by: Steven <steven@ceriously.com>
### What
Disable auto polyfill for process in edge runtime.
### Why
React uses process.emit behind a typeof guard now. This leads to process
being bundled and process.emit being called which triggers build
warnings since we stub process APIs since they're not supported in Edge
runtime.
There's condition like `"object" === typeof process && "function" ===
typeof process.emit` in the react build now where the 2nd condition is
falsy. Stop polyfilling to skip that condition since it's mainly for
Node.js runtime
Related to #65692
### What?
This PR adds an experimental option `clientTraceMetadata` that will use
the existing OpenTelemetry functionality to propagate conventional
OpenTelemetry trace information to the client.
The propagation metadata is propagated to the client via meta tags,
having a `name` and a `content` attribute containing the value of the
tracing value:
```html
<html>
<head>
<meta name="baggage" content="key1=val1,key2=val2">
<meta name="traceparent" content="00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01">
<meta name="custom" content="foobar">
</head>
</html>
```
The implementation adheres to OpenTelemetry as much as possible,
treating the meta tags as if they were tracing headers on outgoing
requests. The `clientTraceMetadata` will contain the keys of the
metadata that're going to injected for tracing purpose.
### Why?
Telemetry providers usually want to provide visibility across the entire
stack, meaning it is useful for users to be able to associate, for
example, web vitals on the client, with a span tree on the server. In
order to be able to correlate tracing events from the front- and
backend, it is necessary to share something like a trace ID or similar,
that the telemetry providers can pick up and stitch back together to
create a trace.
### How?
The tracer was extended with a method `getTracePropagationData()` that
returns the propagation data on the currently active OpenTelemetry
context.
We are using `makeGetServerInsertedHTML()` to inject the meta tags into
the HTML head for dynamic requests.
The meta tags are generated through using the newly added
`getTracePropagationData()` method on the tracer.
It is important to mention that **the trace information should only be
propagated for the initial loading of the page, including hard
navigations**. Any subsequent operations should not propagate trace data
from the server to the client, as the client generally is the root of
the trace. The exception is initial pageloads, since while the request
starts on the client, no JS has had the opportunity to run yet, meaning
there is no trace propagation on the client before the server hasn't
responded.
Situations that we do not want tracing information to be propagated from
the server to the client:
- _Prefetch requests._ Prefetches generally start on the client and are
already instrumented.
- _Any sort of static precomputation, including PPR._ If we include
trace information in static pages, it means that all clients that will
land on the static page will be part of the "precomputation" trace. This
would lead to gigantic traces with a ton of unrelated data that is not
useful. The special case is dev mode where it is likely fine to
propagate trace information, even for static content, since it is
usually not actually static in dev mode.
- _Clientside (soft) navigations._ Navigations start on the client and
are usually already instrumented.
### Alternatives considered
An implementation that purely lives in user-land could have been
implemented with `useServerInsertedHTML()`, however, that implementation
would be cumbersome for users to set up, since the implementation of
tracing would have to happen in a) the instrumentation hook, b) in a
client-component that is used in a top-level layout.
### Related issues/discussions
- https://github.com/vercel/next.js/issues/47660
- https://github.com/vercel/next.js/discussions/62353 (Could be used as
an alternative to the server-timing header)
- https://github.com/getsentry/sentry-javascript/issues/9571
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### Fixing a bug
fixes#65580
### What?
#65580
### Why?
Currently, afterInteractive is given as the default strategy prop, but
afterInteractive is not set for the child retrieved through
React.Children, and it is an empty prop and is not added to the script
loader, so the script is not executed.
### How?
Added item to script loader when `child.props.strategy` is undefined.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!-- 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?
Adding support for supporting a custom fontFamily name when using
next/font
### Why?
By default, next/font hashes the font name when generating css to
achieve proper scoping.
However, that makes it impossible to use next/font with 3rd party
libraries that provide CSS with pre-defined font names.
### How?
To solve this, I've added a new argument to the next/font function call
– `usedFontFamilyName`.
It allows developers to pick the fontFamily name that is going to be
used in the CSS output instead of the default one and make it work with
vendor CSS files.
```
import { Inter } from "next/font/google";
const inter = Inter({
subsets: ["latin"],
fixedFontFamily: "Inter",
});
```
Fixes [#43452](https://github.com/vercel/next.js/discussions/43452)
---
Edit:
I've changed the implementation to use `disabledFontFamilyHashing`
boolean flag which removes the hashing but keeps the original font
family name instead of allowing a custom name
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
BREAKING CHANGE:
Using the built-in image optimization API, the URL is parsed with `new
URL()` constructor which automatically trims spaces.
However, the developer may choose a 3rd party image optimization API via
`loader` or `loaderFile` (or perhaps a deployment platform that has its
own built in loader), so we shouldn't assume the API will parse the URL
in the same way as
[WHATWG](https://url.spec.whatwg.org/#:~:text=If%20input%20contains%20any%20leading%20or%20trailing%20C0%20control%20or%20space%2C%20invalid%2DURL%2Dunit%20validation%20error.).
While we could trim on the client, its probably best to fail fast and
let the developer make a conscience decision if a trailing space should
be removed or remain (by explicitly using `%20`).
### What
Remove `swcMinify` related branches as the option is deprecated and it's
always enabled
* Remove the related branches for checking `config.swcMinify`
* Remove the related telemetry about `swcMinify`
### What
Remove `missingSuspenseWithCSRBailout` and always treate the conditions
where it was used as `true`.
### Why
This was an intended behavior introduced in 14.1, which requires users
to always add suspense boundaries if it's using any hook that could bail
out to client rendering. `missingSuspenseWithCSRBailout` as `true` was
the default behavior and you could disable it with
`missingSuspenseWithCSRBailout: false` in next config. Now after the
removal you will not be able to opt-out it.
