### 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`
### What?
Replace `twitter.com` links in the docs with `x.com`
### Why?
Now that Twitter (twitter.com) has officially moved to the x.com domain
### How?
- Replace the link, then click on the link to make sure there are no
problems
Closes NEXT-
Fixes#65916
---------
Co-authored-by: Sam Ko <sam@vercel.com>
### 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.
### What?
Adding packages from the Effect ecosystem to the list of
optimized-by-default imports
### Why?
Effect usage includes very liberal use of `import * as Module from
"effect/Module"` and `import { Module } from "effect"`. This is usually
trees-shaken but in nextjs we must declare it to be optimized to be have
this way. To provide a better experience to users I added all the
packages in the ecosystem to the list that are possibly relevant. I
don't expect all of them to get in, but the proposal should start from
the full set of possible candidates. Not included are `/cli`,
`/printer`, `/printer-ansi`, and `/vitest`.
At the very least `effect` and `/schema` should be added for their
prevalence, but even if there is hesitance I recommend adding
`/platform` and `/platform-node` since it's natural for effect usage to
grow into benefitting from these quickly enough.
Related issue in the effect repo
https://github.com/Effect-TS/effect/issues/2701
cited source for taken action:
[the vercel
blog](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js)
### How?
Adding strings to a set
Co-authored-by: JJ Kasper <jj@jjsweb.site>
- 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)
### 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>
Further enhancing the typings across the codebase, this resolves some
errors discovered while running tests. During development, previously,
if the websocket request was forwarded down to the route resolver, it
would fail. This is because a `Duplex` stream is not a `ServerResponse`.
I opted to use the `MockedResponse` here to ensure the remaining code
didn't change, as we're only using the resolve routes code to identify a
match rather than actually sending the response on. The response data is
sent later with the `proxyRequest` which here does have support for
`Duplex` streams.
### 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>
### What
`__INTERNAL_CUSTOM_TURBOPACK_BINDINGS` behaves inconsistent across
exposed bindings interface. PR adjusts to apply it to all of the
interface, to allow to use this env to override any swc binaries. This
is not a public interface, no concern of breaking changes.
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`).
This resolves an issue where a prefetch react server components (RSC)
request incorrectly causes cache poisoning issues during revalidation
for applications configured with partial prerendering (PPR).
It removes the test which used the header directly, and instead defers
to the `handleRSCRequest` method which includes specific environment
implementations.
This also fixes a bug where the prefetch RSC request for the root page
was not normalized.
Bumped acorn to latest version to let it parse class properties.
Class properties and private properties support was landed in 8.6.0,
bumping acorn parser to latest version then we can parse all the
syntaxes.
## What?
A small update to FileSystemCache to replace sync calls with async.
## Why?
`loadTagsManifest` may be called multiple times per request. Since
`loadTagsManifest` is synchronous it blocks the main thread whilst
reading from the file system which could impact server performance.
Replacing these sync calls with async has no impact for consumers of the
FileSystemCache.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### 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.
When `alternates.canonical` is provided as a `URL` instance,
`searchParams` are discarded.
When canonical is provided as a string, the same search parameters work.
This behavior may be unintuitive.
#### Unexpected result (`foo=bar` is removed):
```ts
export const generateMetadata = () => {
const canonical = new URL(`https://example.com/test?foo=bar`);
return {
alternates: { canonical: canonical },
};
};
```
#### Works as expected:
```ts
export const generateMetadata = () => {
const canonical = new URL(`https://example.com/test?foo=bar`);
return {
alternates: { canonical: canonical.toString() },
};
};
```
Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Previously we only display the warning when it's a new key format
`<object>.<property>`, we should display all cases to help users
understand where the new key is moved to
x-ref: https://x.com/huozhi/status/1789335665252921381
### What?
Do not reuse `Compiler` instance.
### Why?
It exists only to support preserving comments from `print()` API for
modules created with `parse()` API, but it causes a problem for
`transform()` for very huge apps.
### How?
- Closes https://github.com/swc-project/swc/issues/8932
- Fixes#48960
- Fixes#65436
### What
Reland #57448 , add react-server condition resolving and apply
server-only rules to middleware
Closes NEXT-1653
Closes NEXT-3333
### Why
Middleware as the pre-routing layer that is indended to be light-weight.
Since it's on edge runtime and only run on server but not on client, it
doesn't need to include the client react bundles. Hence we apply
`react-server` export condition, that if users import React we can only
bundle server required APIs and if users use React client hooks we can
error.
### BREAKING CHANGE
This changes the behavior of the default image `loader` so that
[`Content-Disposition`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#as_a_response_header_for_the_main_body)
header is now `attachment` for added protection since the API can serve
arbitrary remote images.
The new default value, `attachment`, forces the browser to download the
image when visiting directly. This is particularly important when
`dangerouslyAllowSVG` is true. Most users will not notice the change
since visiting pages won't behave any differently, only visiting images
directly.
Users can switch back to the old behavior by configuring `inline` in
next.config.js
```js
module.exports = {
images: {
contentDispositionType: 'inline',
},
}
## Why?
- Remove `favicon.ico` from empty templates
- Update Index pages in `default-empty` templates to be the same as the
`app-empty` templates
- x-ref: https://github.com/vercel/next.js/pull/65532
Updates the links to go to the respective dir version (app or pages) and
rely less on the current redirects.
Also, if app dir is default, should the folder for pages be called
"pages" instead?
# What
Remove the previous deprecated flags and warnings
Removed deprecated types:
In `next.config.js`
- `experimental.incrementalCacheHandlerPath` (has moved to new options
in next 14)
- `experimental.isrMemoryCacheSize` (has moved to new options in next
14)
- `outputFileTracing` (not support customization anymore)
- `swcMinify` (not support customization anymore)
In `next/types`
- `unstable_includeFiles` (already deprecated for a while)
- `unstable_excludeFiles` (already deprecated for a while)
Remove font loaders resolving for `@next/font`, users should directly
rely on `next/font`, they're intended to be removed.
Also removed the legacy tests
When a server action performs a redirect, we send an RSC request to the
redirect URL so that everything can be handled in a single roundtrip.
However, we forward the `next-action` header to that request. This means
that the intra-app RSC request will be incorrectly associated with an
action, and any rewrites we do for `next-action` requests (such as the
work in the Next.js builder to ensure actions are routed to streaming
outputs) won't be handled correctly.
<!-- 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
Ensures `nonce` is added to script and link tags Next.js renders.
Additional cases it now handles:
- We already passed `nonce` to the React rendering, though not
consistently on all cases where `renderToStream` is called, I'm
surprised there haven't been more reports of this, but now it will pass
it on all cases where React rendering is called that I could find
- In `get-layer-assets.tsx` we now pass `nonce` to both the `script` and
`link` tags
- When calling `ReactDOM.preload` the nonce was missing as well, ensured
that the nonce is included in that case as well.
Added a test that mimicks the reproduction by adding `next/font` in this
case.
Fixes#64037
Closes PACK-2973
<!-- 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 #
-->
We've seen too many instances of folks accidentally committing their
`.env` files that I feel it's time to make this change.
Up until now, Next.js has recommended that you use `.env.local` when
working locally to store your environment variables. Some developers do
intentionally want to commit their `.env` file without secret values to
source control. However, the ecosystem is fragmented on `.local`
support.
There are tools which require secrets values that do _not_ support
`.local` and require using `.env`. This means that it's possible to dump
your secret values into a `.env` file and commit to source control,
thinking that the defaults would have you covered.
This change updates the defaults for `create-next-app` to ignore all
`.env` files by default. If you want to commit then, you opt-in by
modifying your `.gitignore`, versus the opposite.
Related: https://x.com/complexlity/status/1755890800527892716
---------
Co-authored-by: Sam Ko <sam@vercel.com>
## Why?
Adding an `--empty` flag so we can easily create an empty Create Next
App template.
Closes NEXT-3367
---------
Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
### What
Remove the extra `__esModule` and `$$typeof` export for ESM client
module
For a client page reference, it changed on server side in renderer:
Previous: `{ __esModule, $$typeof, default }`
Now: `{ default }`
### Why
The Module object itself appears as a client reference but it can't be
rendered since it's not a real reference. I'm not sure why it was added
but I think the right thing for an ESM module is to not treat the module
itself as a client reference but only the objects inside of it. E.g. the
"default" export. That's what React does upstream for ESM modules.
Closes NEXT-3360
### What
Remove the auto appending `.xml` extension to the sitemap routes when
it's a dynamic route.
### Why
Previously we were adding `.xml` to `/[...paths/]sitemap` routes, but
the bad part is when you use it to generate multiple sitemaps with
`generateSitemaps` in format like `/[...paths/]sitemap.xml/[id]`, which
doesn't look good in url format and it can be inferred as xml with
content-type. Hence we don't need to add `.xml` in the url.
Before this change it could also result into the different url between
dev and prod:
dev: `/sitemap.xml/[id]`
prod: `/sitemap/[id].xml`
Now it's going to be aligned as `/sitemap/[id]`. Users can add extension
flexiblely.
Closes NEXT-3357
Reverts vercel/next.js#65321
Missed covering `api` layer, got reported with below error. Revert it
for now and will re-land it with more tests
```
../../node_modules/.pnpm/next@14.3.0-canary.51_@opentelemetry+api@1.7.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/client/components/navigation.js
02:23:13
Module not found: shared-runtime module app-router-context cannot be used in api layer
02:23:13
https://nextjs.org/docs/messages/module-not-found
```
### What
Follow up for #64294 where we could preload all the JS and CSS chunks
for `next/dynamic` component.
* Rename `preload-css` component to `preload-chunks` and remove the
filter for css chunks
* Preload JS chunks with `defer`
### Why
Preloading all the async chunks of `next/dynamic` can make rendering
more efficiently when combined with the initial chunks. Since those
chunks are splitted on client but still essential for the page
#### After vs Before
We can see the waterfall starts much earlier for the dynamic chunk
(881.8a0e88...js)
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/9bab2c32-37c3-4c7a-93e2-3aa43b2ec7c8">
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/0fba7499-bb69-41c4-ab72-e9952f3d7f68">
### What
* Remove the `private-next-app-dir` condition for
`WEBPACK_LAYERS.appRouteHandler` layer since it's not effective as the
`rule.test` will match the actual file path. App routes are actually
bundled in rsc layer atm as expected.
* Should only let shared-runtime modules working in either ssr layer or
non-layer (unbundling pages router).
* Remove the pages router context modules for app-page runtime. Still
need to keep amp-context as it's used in `head.js` and `head.js` used in
`next/image`. Not easy to remove unless we have separate implementation
of `next/image` for pages and app router
Closes NEXT-3312
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
Reverts vercel/next.js#65425
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
make sure children is first in loader tree to fix head css bug on client
navigation
### Why?
### How?
Fixes PACK-3028
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What
Support `esmExternals` working in app router
### Why
`esmExternals` was disabled for app router that most of the packages are
picking up the CJS bundles for externals. This PR enables to resolve the
ESM bundle for external packages.
We have two issues discovered while enabling the flag, any esm external
packages will fail in client page SSR and server action. We fixed them
by changing the below bundling logics:
* When a client page having a async dependency, we can await the page
during in rendering
* When a server action having a async dependency, we changed the server
action entry creation with webpack along with the server client entry
creation together, then webpack can handle the modules async propagation
properly.
Fixes#60756
Closes NEXT-2435
Closes NEXT-2472
Closes NEXT-3225
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
For debugging purposes, it can be useful to set `NODE_ENV=development`
during a `next build`. Currently this value is forced to be production
in Next.js. This PR adds an experimental flag to not force a mode of
`production` when the flag is set.
To use this flag, you'll still need to explicitly set
`NODE_ENV=development`, while also enabling
`nextConfig.experimental.allowDevelopmentBuild`
Closes NEXT-3277
This PR promotes and renames experimental configuration options related
to server bundling:
- `serverComponentsExternalPackages` -> `serverExternalPackages`
- `bundlePagesExternals` -> `bundlePagesRouterDependencies`
Existing docs for `serverComponentsExternalPackages` was changed.
New docs for `bundlePagesRouterDependencies` were added.
Closes NEXT-3332
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The tests added in https://github.com/vercel/next.js/pull/46219 were
never correctly testing the headers because `detectContentType()` is
called first and only when we can't detect the type from the response
body do we fallback to the `Content-Type` header.
I also refactored some of the tests because the `ctx: any` type was
causing some tests to not run when testing different configuration
options.
Closes NEXT-3321
When revalidating a page that corresponds with a dynamic path and when
using the “type” parameter, eg `revalidatePath(“/dynamic/1”, “page”)`
corresponding with `/dynamic/[id]`, the wrong cache tags would be
checked to determine if a revalidation occurred.
This is because the “derived” cache tags created for a
`/dynamic/[id]/page` are:
- /dynamic/[id]/layout
- /dynamic/[id]/page
Additionally, a tag is added for the current canonical URL, so the final
tag would be:
- /dynamic/1
Thus a fetch on `/dynamic/1` would be tagged with the following:
- /layout
- /dynamic/layout
- /dynamic/[id]/layout
- /dynamic/[id]/page
- /dynamic/1
Calling `revalidatePath(“/dynamic/1”, “page”)` would signal to
revalidate caches tagged `/dynamic/1/page` in the current logic.
However, this tag doesn’t exist given the above, so it would be a no-op
and wouldn't properly re-invoke the fetch.
This updates the docs to explicitly call out that if you are attempting
to revalidate a path that corresponds with a dynamic page, that you
should not provide a "type" argument.
Fixes#62071
Closes NEXT-3302
<!-- 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 #
-->
Hi everyone, this is my first PR to such a large project so please be
gentle. 😄 I'm also new to publishing packages so I'm not sure if I'm
missing any steps.
ESLint 9.0.0 came out a few days ago and unfortunately,
`eslint-plugin-next` is not compatible as it uses deprecated (and with
ESLint 9.0.0 removed) functions.
In this PR, I replaced the deprecated functions with the suggested
replacements ([check this
out](https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/)).
Regarding backwards compatibility, everything I used is available since
ESLint 8.40 (released May 2023). I'm not sure how far back Next.js
support goes but it feels fine to me.
I successfully tested some rules locally with ESLint 9.0.0 and this
`eslint.config.js` (flat config format):
```js
import js from '@eslint/js';
import nextPlugin from '@next/eslint-plugin-next';
import prettierRecommended from 'eslint-plugin-prettier/recommended';
import importSortPlugin from 'eslint-plugin-simple-import-sort';
import globals from 'globals';
import tseslint from 'typescript-eslint';
/**
* TypeScript config with strict type checking and no type checking for JS files.
*/
const typeScriptConfig = [
...tseslint.configs.strictTypeChecked,
{
plugins: {
'@typescript-eslint': tseslint.plugin,
},
languageOptions: {
parser: tseslint.parser,
parserOptions: {
project: true,
},
},
},
{
// disable type-aware linting on JS files
files: ['**/*.js', '**/*.mjs', '**/*.cjs'],
...tseslint.configs.disableTypeChecked,
},
];
/**
* Next.js config with recommended and core web vitals rules.
*/
const nextConfig = {
plugins: {
'@next/next': nextPlugin,
},
rules: {
...nextPlugin.configs.recommended.rules,
...nextPlugin.configs['core-web-vitals'].rules,
},
};
/**
* Import sort config with simple-import-sort plugin.
*/
const importSortConfig = {
plugins: {
'simple-import-sort': importSortPlugin,
},
rules: {
'simple-import-sort/imports': 'error',
'simple-import-sort/exports': 'error',
},
};
/**
* The final ESLint config wrapped with the tseslint.config helper for type hinting.
*/
export default tseslint.config(
{
ignores: ['.next', '.yarn', '**/*.d.ts', 'node_modules'],
},
{
languageOptions: {
globals: {
...globals.browser,
...globals.node,
},
},
},
js.configs.recommended,
...typeScriptConfig,
nextConfig,
prettierRecommended,
importSortConfig,
);
```
It has a few more configs but I'm sure you can remove most of them. The
important one is the `nextConfig`. Also important: Run `eslint` and not
`next lint`, it's currently not compatible with the new flat config
format.
Related discussion: https://github.com/vercel/next.js/discussions/54238
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Enabling Partial Prerendering (PPR) for an entire application is
ideally, the goal for teams wanting to test out the feature or adopt it
in their applications to get ready for when it becomes the default
rendering pattern. For large applications, with many routes the new
behaviours of old API's may prove a difficult pill to swallow all at
once.
This aims to enable incremental adoption of PPR for pages and routes
that want to support it in a similar way to how existing segment-level
configurations. Segments can now add:
```ts
export const experimental_ppr = true
```
To enable PPR for that segment and those descending segments. Any subset
of those routes that have it enabled can add:
```ts
export const experimental_ppr = false
```
<details>
<summary>An aside on the choice of <code>experimental_ppr</code>
name</summary>
<blockquote>
<p>It is against common JS semantics to use snake-case, and preference
is given to camel-case instead. The choice to make this snake-case was
to re-enforce that this is an experimental feature, an ugly incremental
path, and ideally, developers should aim to remove all references of it
from their codebase.</p>
<p>Additionally, this mirrors what we've done for unstable API's like
`unstable_cache`.</p>
</blockquote>
</details>
To disable PPR for that segment and those descending segments. To use
this new option, the `experimental.ppr` configuration in
`next.config.js` must be set to `"incremental"`:
```js
// next.config.js
module.exports = {
experimental: {
ppr: "incremental",
},
}
```
If a segment does not export a `experimental_ppr` boolean, it is
inferred from it's parent. If no parent has it defined, it's default
value is `false` and therefore disabled.
Once all your segments have PPR enabled via this config, it would be
considered safe for teams to set their `experimental.ppr` value in the
`next.config.js` to `true`, enabling it for the entire app and for all
future routes.
### Aside
I also took the liberty to rename `isPPR` and `supportsPPR` to be the
clearer `isAppPPREnabled` and `isRoutePPREnabled`.
---------
Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>
## What?
Implements support for running the Turbopack trace server, which is the
websocket server that powers https://turbo-trace-viewer.vercel.app/ when
using `NEXT_TURBOPACK_TRACING=1 NEXT_TURBOPACK_TRACE_SERVER=1`.
Currently you have to manually run the server through the Turbo
repository which in practice means that only people working on Turbopack
are able to run it.
With the bindings implemented anyone should be able to run the trace
server.
Note that the traces that come out of Turbopack are very low level,
they're meant for optimizing Turbopack like finding slowdowns / large
memory usage / optimizing performance.
However, it's useful for people that want to peek into why their
application is slow to compile. I.e. we've used
https://turbo-trace-viewer.vercel.app to investigate reports in #48748.
This PR adds support for `trace.log` by default, so if you add
`NEXT_TURBOPACK_TRACING=1 NEXT_TURBOPACK_TRACE_SERVER=1` it will
automatically select the `trace.log` for the current instance of
Next.js. You can only have one trace server running at the same time.
### `next internal`
In order to support running the trace server standalone, which is useful
for investigating trace files other people have shared, I've added a new
subcommand `internal` that is not covered by semver / use at your own
risk. It's meant for internal tools that are useful to be bound to the
version of Next.js, the turbo-trace-server is a great example of that as
it has an internal binary format for storing data that needs to match
the trace.log file.
If you want to take a look at `.next/trace` instead the new `next
internal` subcommand can be used for that:
```sh
# Replace [path] with a path to a file.
next internal turbo-trace-server [path]
```
For example:
```sh
next internal turbo-trace-server ~/Downloads/trace
```
Currently the trace server does not support loading multiple files, just
hasn't been implemented yet. Once we can load two or more files we can
load both `.next/trace` and `trace.log` when
`NEXT_TURBOPACK_TRACE_SERVER=1` and support multiple paths passed to
`next internal turbo-trace-server`.
### Turbopack upgrade
PR includes a Turbopack upgrade:
* https://github.com/vercel/turbo/pull/8073 <!-- OJ Kwon -
feat(webpack-loaders): support dummy span interface -->
* https://github.com/vercel/turbo/pull/8083 <!-- OJ Kwon - fix(webpack):
print resource, project path when relative calc fails -->
* https://github.com/vercel/turbo/pull/8094 <!-- Tim Neutkens -
Implement bindings for Turbopack trace server -->
<!-- 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-3328
When `notFound()` is thrown from metadata, it's caught by a
`<MetadataOutlet />` rendered as a sibling to the page component. But we
currently only pass the custom not-found component to the
`<NotFoundBoundary />` for the `children` slot. This means that if a
parallel route throws a `notFound()` in `generateMetadata`, it'd be
caught by the root not found, which would be unexpected.
This mirrors the logic for determining whether or not a `notFound`
boundary should be provided. A side effect of this is that if you throw
a `notFound()` in `generateMetadata` for a segment that _only_ has
parallel routes, and no `children` slot, it won't be caught by the
boundary. But fixing this will require a larger refactor.
<!-- 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-3320
The `transparent` option only does something when the struct is a field-less unit struct with a single item.
Right now, an invalid `transparent` option is silently ignored. I'm working on a PR to change this to a compilation error, so that it's obvious that the option won't work. These are the callsites in `next.js` that my tweak brought up as potential issues.
Functionally, this PR should be a no-op.
### Why?
`polyfill-nomodule.js` is a pre-built file containing polyfills for
older browsers (gated by the `<script>` tag `nomodule` attribute).
### How?
- The turbopack server needs to emit a raw OutputAsset for this file, so
that it is copied into the output chunks directory.
- That file needs to be passed into `polyfillFiles`, and preserved when
we're merging manifests inside of the development server.
### Test Plan
```
HEADLESS=true pnpm testonly-dev test/e2e/app-dir/app/index.test.ts -t 'should serve polyfills for browsers that do not support modules'
HEADLESS=true pnpm testonly-dev-turbo test/e2e/app-dir/app/index.test.ts -t 'should serve polyfills for browsers that do not support modules'
```
Build a project with `next dev --turbo` and inspect:
![Screenshot 2024-05-01 at
10.40.39 PM.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/HAZVitxRNnZz8QMiPn4a/fe0214b2-ca56-4c03-a133-921f1dc51775.png)
![Screenshot 2024-05-01 at
10.40.20 PM.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/HAZVitxRNnZz8QMiPn4a/d41dbf91-34d2-44c4-90ec-30e3212ce0f8.png)
Verify that the polyfill file exists and resolves in the browser.
Closes PACK-2993
This enables the preloading entries on start flag by default as it has a
great benefit to preload eagerly when starting the server instead of
lazily when requests come in which makes the user eat the module
initialization time.
Closes NEXT-3303
This should fix the following scenarios,
- Given a page defined like `app/foo/[...bar]/page.tsx`
- Given a page defined like `app/bar/[[...foo]]/page.tsx`
- Given a parallel route defined like `app/@slot/[...catchall]/page.tsx`
If you navigate to `/foo/bar` the `params` prop in the parallel route
would be
```js
params: {
catchall: [
'foo',
[ 'bar' ]
]
}
```
And if you navigate to `/bar/foo` the `params` prop in the parallel
route would be
```js
params: {
catchall: [
'bar',
'[ ...foo ]'
]
}
```
With the fix in place, the `params` prop in the parallel route will be,
```js
params: {
catchall: [
'foo',
'bar',
]
}
```
And
```js
params: {
catchall: [
'bar',
'foo',
]
}
```
Respectively
### What?
Remove "text-balance" custom class from create-next-app tailwindCSS
templates.
### Why?
TailwindCSS has exact same class since v3.4.0.
https://tailwindcss.com/docs/text-wrap
Co-authored-by: Sam Ko <sam@vercel.com>