### What
Only call error log in SSR renderer, instead of calling it in all RSC
and SSR renderers.
Fixes#67352
Close NEXT-3579
### Why
The RSC rendered generated result will be rendered by SSR renderer
again, at there we can get the actual error. So when there's a RSC error
happening, only logging once in SSR rendering layer is enough.
### What?
This disallows merging of global css with styles that appear on other
pages/chunk groups.
### Why?
Before we made the assumption that all CSS is written in a way that it
only affects the elements it should really affect.
In general writing CSS in that way is recommended. In App Router styles
are only added and never removed. This means when a user uses
client-side navigations to navigate the application, styles from all
previous pages are still active on the current page. To avoid visual
artefacts one need to write CSS in a way that it only affects certain
elements. Usually this can be archived by using class names. CSS Modules
even enforce this recommendation.
Assuming that all styles are written this way allows to optimize CSS
loading as request count can be reduced when (small) styles are merged
together.
But turns out that some applications are written differently. They use
global styles that are not scoped to a class name (e. g. to `body`
directly instead) and use them in different sections of the application.
They are structured in a way that doesn't allow client-side navigations
between these sections. This should be valid too, which makes our
assumption not always holding true.
This PR changes the algorithm so we only make that assumption for CSS
Modules, but not for global CSS. While this affects the ability to
optimize, applications usually do not use too much global CSS files, so
that can be accepted.
fixes#64773
Previously, if `artifact_directory` were set, artifacts would be
resolved at a fixed location relative to each file. This correctly
resolves them from the project root.
Test Plan: `TURBOPACK_BUILD=1 TURBOPACK=1 pnpm test-dev
test/integration/relay-graphql-swc-multi-project/test/index.test.js`
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What
Transpile `geist` package by default. Currently users need to add
`geist` into `transpilePackages` to make it work with pages router as
it's external packages but require transform. This PR will resolve that
issue. cc @JohnPhamous
### Why
geist package is using `next/font` which requires to work with SWC
transform. But so far only ESM syntax can be captured by SWC since CJS
is pretty difficult to cover as the package import is not statically
analyzable.
We introduced a new list that it could be transpiled and include geist
package into bundle. Add it in both `next/jest` side and
webpack/turbopack bundling side
---------
Co-authored-by: 강동윤 (Donny) <kdy1997.dev@gmail.com>
### What
When using `generateStaticParams` with interception routes, the
interception would never occur, and instead an MPA navigation would take
place to the targeted link.
### Why
For interception rewrites, we use a `__NEXT_EMPTY_PARAM__` marker (in
place of the actual param slot, eg `:locale`) for any params that are
discovered prior to the interception marker. This is because during
route resolution, the `params` for the interception route might not
contain the same `params` for the page that triggered the interception.
The dynamic params are then extracted from `FlightRouterState` at render
time. However, when `generateStaticParams` is present, the
`FlightRouterState` header is stripped from the request, so it isn't
able to extract the dynamic params and so the router thinks the new tree
is a new root layout, hence the MPA navigation.
### How
This removes the `__NEXT_EMPTY_PARAM__` hack and several spots where we
were forcing interception routes to be dynamic as a workaround to the
above bug. Now when resolving the route, if the request was to an
interception route, we extract the dynamic params from the request
before constructing the final rewritten URL. This will ensure that the
params from the "current" route are available in addition to the params
from the interception route without needing to defer until render.
Fixes#65192Fixes#52880
### What
When PPR is off, app router prefetches will render the component tree up
until it encounters a `loading` segment, at which point it'll just
return some metadata about the segment and won't do any further
rendering. This is an optimization to ensure prefetches are lightweight
and don't potentially invoke expensive dynamic subtrees. However,
there's a bug in this logic that is causing it to bail unexpectedly if a
segment deeper in the tree contained a `loading.js` file.
This would mean the loading state wouldn't be triggered until the second
request for the full RSC data is initiated, resulting in an unintended
delta between when a link is clicked and the loading state is shown.
### Why
The `shouldSkipComponentTree` flag was incorrectly being set to `true`
even if the `loading.js` segment appeared deeper in the tree. Prefetch
requests from the client will always contain `FlightRouterState`, so the
logic to check for loading deeper in the tree will always be missed.
### How
This removes the `flightRouterState` check as it doesn't make sense:
prefetches will currently _always_ include the `flightRouterState`,
causing this to always short-circuit. I believe that this check is
vestigial from when we were generating static `prefetch.rsc` outputs
which is no longer the case.
This mirrors a [similar
check](b87d8fc499/packages/next/src/server/app-render/create-component-tree.tsx (L393))
when determining if parallel route(s) should be rendered.
When running `pnpm test-start
test/production/standalone-mode/required-server-files/required-server-files.test.ts`
locally, Jest hangs and prevents the process from exiting. In the CI,
the issue is masked because `run-tests.js` uses `--forceExit`.
The reason for the hanging process is that there are two server
instances started, and only the last one is killed. By starting and
killing the server for each test we can not only fix this, but also
prevent the `should run middleware correctly (without minimalMode, with
wasm)` test from affecting the other tests when flipping the
`minimalMode` flag in `server.js`.
I also reverted the darwin-specific overwrites of `appPort` that were
added in #65722 and #66724. I don't think those are needed because after
#65722 was created we did land #66285 which sets the hostname to be
compatible with ipv4 and ipv6. If there's still a need to keep this then
let me know, and I will restore it.
This leverages [fetch
priority](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#priority)
to ensure automatic prefetching as a result of visiting a page is sent
with "low" priority, to signal to the browser it can prioritize more
important work necessary for rendering the page.
A "temporary" prefetch (ie one that is created when there wasn't an
existing prefetch cache entry on navigation) will use a "high" priority
because it's critical to the navigation event.
All other cases will be "auto" which is the current default.
## History
When we added `priority` prop to `next/image`, there was no
`fetchPriority` so we instead used this to preload the image in the
head.
Then when browsers added support `fetchPriority`, we automatically added
`fetchPriority=high` when `priority={true}` to signal to the browser
that this was a high priority image. This priority is added to the img
and the preload.
However, we saw cases where images are blocking critical css. Per
@gnoff:
> React currently prioritizes font preloads then high priority images,
then css in the initial page load
Due to these changes in React (aka Float), we should no longer set
`fetchPriority=high`, although the user can still manually add that prop
if needed.
### What
* Warn with next.js when users customized `experimental.esmExternals`
value
* Add telemetry tracking on the customization usage for that flag. 0 for
no customization, 1 for used non-default customized value
### Why
`esmExternals` ideally can just remain as default value `true` which
Next.js can handle the customization properly. Since next.js app router
also supports it on canary now we're adding a warning to users that
don't modify `esmExternals` option as it could affect module resolution
on ESM packages.
### Why?
It could be confusing between `...` and `…`, which the later is actually
a single character.
### How?
We throw if we detect `…` instead of `...`.
The Image Optimization API currently uses `parseInt()` for `w` and `q`
query string parameters.
This doesn't handle floats as you might expect and instead coerces, for
example `parseInt('99.9') === 99`.
This PR changes the runtime to match the build time validation and only
accept integers for `w` and `q`.
When a server action responds with something other than an RSC response,
we currently silently ignore the error and it doesn't get propagated to
any rejection handlers.
This adjusts the handling so that if the server action response is a
non-successful status code, we reject the server action promise. If the
error is `text/plain`, we'll automatically propagate the text content as
the error text. Otherwise, the promise is rejected with a fallback
message.
Fixes some possible race conditions by adding a few delays to the
navigation test to ensure that we wait for hydration to occur and
prefetches to finish.
Previously, when the provided postponed state was corrupted, the render
failed which resulted in a hydration error. Instead, when the postponed
state is corrupted, we send the resume stream just for the hydration
where it'll attempt to render client side with the data that's already
available.
### What
Reland #64716
Removing the Suspense boundary on top of `next/dynamic` by default, make
it as `React.lazy` component with preloading CSS feature.
* Remove `suspense` option in `next/dynamic` since it's already
deprecated for a while
* Remove the default loading in app router implmentation of
`next/dynamic`
### Why
Extra Suspense boundary is causing extra useless rendering. For SSR, it
shouldn't render `loading` by default
Related: #64060
Related: #64687
Closes
[NEXT-3074](https://linear.app/vercel/issue/NEXT-3074/app-router-content-flickering-with-reactcreatecontext-and-nextdynamic)
This is sort of a breaking change, since removing the Suspense boundary
on top of `next/dynamic` by default. If there's error happening in side
the dynamic component you need to wrap an extra Suspense boundary on top
of it
### What
Add isEdgeRendering check condition for rewrite logic in edge adpator
Fixes#66837
Closes NEXT-3545
### Why
From headers `x-middleware-rewrite`, it's still relative url `/rewrite`,
reconstructing the url will lead to crash as it doesn't contain host.
### What
Render noindex into a flight data and rsc payload when page path is
`/404`
### Why
When it's static generation, noindex is not rendered due to the
statusCode from mock request is 200, but we can relying on the pagePath
as `/404` page should always contain `nonidex`
We were missing the noindex before for flight generation, now we'll
render it when it's 404 page.
### What
Show the full `pagePath` information for missing default component app
router convention files.
Move runtime error tests from `rsc-build-errors.test.ts` to the new test
`test/development/acceptance-app/undefined-default-export.test.ts`
### Why
Previously we only log `segment` which could be `[slug]` that is not
enough useful for users to locate the bad defined component
This test was failing when deployed with _"Unsupported URL Type
"link:"._
This tweaks the linking behavior when deployed. I wasn't able to get
this test to pass when changing both `start` and deploy to use `link`.
When accessing search params, we only track dynamic access during static
generation. This has implications on fetch caching, because the fetch
cache relies on hints set during render that it's in a dynamic scope. In
15, this would signal that it should not attempt to cache the fetch at
all. In 14, this could impact the heuristic that bails from fetch cache
if dynamic access came before certain requests types, e.g. POSTs.
Currently webpack would be incorrectly used when some of the
experimental options for builds were enabled. For example
`parallelServerCompiles` and `parallelServerBuildTraces`. This ensures
Turbopack is always used when it's specified to be used.
Fixes around 100 Turbopack build tests
<!-- 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 #
-->
...with `assertHasRedbox` and `assertNoRedbox`.
`hasRedbox()` has a hardcoded timeout of 5s that is only required for
the negative assertion.
Instead, we now have dedicated assertions for the positive
(`assertHasRedbox`) and negative case (`assertNoRedbox`).
The negative assertion still has the hardcoded timeout.
But the positive assertion just retries until we find the Redbox.
This speeds up tests using the positive assertion.
Removing `hasRedbox` also uncovered some unused expressions e.g. `await
hasRedbox(browser)`.
These expressions probably wanted to use `expect(await
hasRedbox(browser)).toBe(true)
## What?
This PR adds an option to use `sass-embedded`.
## Why?
For large projects sass-embedded improves SCSS compilation time by over
50%.
See also https://github.com/vercel/next.js/discussions/36160
## How?
Added a sassOption `implementation` to configure the sass-loader which
Sass implementation to use.
See also https://www.npmjs.com/package/sass-loader#implementation
I think this a similar approach to what is done for `additionalData`.
## Additional notes
In order to support `sass-embedded`, `sass-loader` is upgraded to
12.6.0.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
Writes the async flag to the client reference manifest to support ESM
externals in app dir.
The `app-ssr` context can't have esm externals as that might cause a
module to be async in ssr but not on the client.
Closes PACK-2967
Fixes#64525
### What
app-dir `metadata.test.ts` is pretty big and includes a lot of erroring
tests and navigation tests. Breaking them into smaller suites to avoid
the erroring on effect on others.
- metadata
- metadata-navigation
- metadata-thrown
Moved the metadata testing utils into `next-test-utils` for sharing
purpose.
Moved the hmr test to the bottom to avoid flakyness.
