### What?
Turbopack uses `parse_as_prorgram`, and in case of empty file it returns
script instead of module so none of visitor runs for the rsc module.
This PR attempts to workaround, however need double clarification if
upstream swc behavior is desired.
Closes PACK-2460
### What?
This PR improves turbopack documentation, mostly collects existing
documents into a single place.
Also, adds a support to render mermaid diagram.
Closes PACK-2488
Moved app-dir path params parsing logic from `useParams` to `AppRouter`.
This allows for the use of `PathParamsContext` in the `useParams` hook
for both pages and app routers. In addition, this allows for memoization
of the layout tree which fixes undesired re-renders of the `useParams`
hook.
Fixes [#58788](https://github.com/vercel/next.js/issues/58788)
Closes NEXT-2434
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
Fix the externals resolving for server rendering layer for app router.
For SSR requests, if it's next externals, we resolved and return early,
if we didn't resolve, keep going through the following externals
resolving
### Why
Previously on app router's SSR bundling layer, we didn't go through the
following requests when seeing an server external package, it will keep
bundling even it's in server components external packages.
A bug found in #61983
Closes NEXT-2473
Fixes#61941 example blog-with-comment.
The root issue is that the SWR fetcher does not check the `ok` status of the response, and that way we end up putting the error message object into the SWR data. And then `.map` is invoked in the object.
Since this is a learning kind of example, I think perhaps the presented change is just about enough to understand what's going on. Whether or not the people using the example want to gain access to the message from the server is up to them.
`createActionProxy` isn't the accurate name here - the function doesn't
return anything new but only mark the value as registered. And also, it
might not be a proxy (which is implementation detail) and might not be
used for Server Actions only. `registerServerReference` is a better name
here.
There's no functionality change in this PR, only a few renames.
Closes NEXT-2490
### What
Merges the package into the internal overlay.
### Detailed Changes
* Move `@next/react-dev-overlay` into next package and rename the import
paths.
* Fix the `getErrorSource` symbol issue, use `Symbol.for()` instead of
`Symbol`
* Extra `getErrorSource` into single lib as it's being used in a lot of
places, this will keep the same bundle size
Closes PACK-2261
Closes NEXT-1977
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
In `v14.0.2-canary.1` users started noticing more memory errors
especially with many edge runtime configured pages. After investigation
it seems this can be related to the additional transpiling we configured
in https://github.com/vercel/next.js/pull/59569 and
https://github.com/vercel/next.js/pull/57784
To help alleviate this we are updating the default swc loader to have an
additional check to see if no special features such as `next/font`,
`next/dynamic`, or `use server/client` directives are present and then
no-oping in the loader to avoid additional overhead for a majority of
modules.
For monitoring regressions our `stats-app` has been updated with
repeated edge-ssr routes to hopefully help us keep an eye on memory or
cache size issues.
x-ref: NEXT-2430
x-ref: NEXT-2395
x-ref: NEXT-2299
x-ref: NEXT-2324
x-ref: NEXT-2373
Closes NEXT-2479
### What
This PR changes setup for the turbopack documentation.
Long story in short, we want to 2 types of documentation: one for high
level description (archtecture, etcs) and another for the api doc.
rustdoc / cargo doc unfortunately doesn't support to integrate both
easily.
PR adds mdbook setup to workaround those - instead of using rustdoc's
index as entrypoint, mdbook becomes an entrypoint to rustdoc. This
allows to host plain text document, and also able to access full rustdoc
pages.
preview: https://turbopack-rust-docs-b6qta4xdq.vercel.sh/
rustdoc:
https://turbopack-rust-docs-b6qta4xdq.vercel.sh/rustdoc/index.html
Closes PACK-2475
Closes PACK-2468
### What
When navigating back to a page that you had already loaded, it currently
results in a prefetch cache miss and will re-trigger any data
fetching/loading despite it being available.
### Why
When creating the initial router state, the prefetch cache is
initialized to an empty map.
### How
This uses the `initialTree` passed from the server to seed the cache for
that route with flight data.
Closes NEXT-2001
### What
Prefetches to pages within a shared layout would frequently cache miss
despite having the data available. This causes the "instant navigation"
behavior (with the 30s/5min TTL) to not be effective on these pages.
### Why
In #59861, `nextUrl` was added as a prefetch cache key prefix to ensure
multiple interception routes that correspond to the same URL wouldn't
clash in the prefetch cache. However this causes a problem in the case
where you're navigating between sub-pages. To illustrate the issue,
consider the case where you load `/foo`. This will populate the prefetch
cache with an entry of `{foo: <PrefetchCacheNode}`. Navigating to
`/foo/bar`, with a link that prefetches back to `/foo`, will now result
in a new cache node: `{foo: <PrefetchCacheNode>, /foo/bar%/foo:
<PrefetchCacheNode>}` (where `Next-URL` is `/foo/bar`). Now we have a
cache entry for the full data, as well as a cache entry for a partial
prefetch up to the nearest loading boundary. Now when we navigate back
to `/foo`, the router will see that it's missing data, and need to
lazy-fetch the data triggering the loading boundary.
This was especially noticeable in the case where you have a route group
with it's own loading.js file because it creates a level of hierarchy in
the React tree, and suspending on the data fetch would result in the
group's loading boundary to be triggered. In the non-route group
scenario, there's still a bug here but it would stall on the data fetch
rather than triggering a boundary.
### How
In #61794 we conditionally send `Next-URL` as part of the `Vary` header
if we detect it could be intercepted. We use this information when
creating the prefetch entry to prefix it, in case it corresponds with an
intercepted route.
Closes NEXT-2193
On the Examples section the name was already updated but not updated on
the Selecting Session Management in Next.js
---------
Co-authored-by: Balázs Orbán <info@balazsorban.com>
### What
When navigating to a page that uses a loading boundary + parallel route,
an empty white screen would be displayed rather than the loading state /
final state
### Why
With parallel routes, the RSC data is an array of data paths, each
corresponding with one of the parallel segments rendered on the page.
During the navigation event, when we iterate over this data, we call
`applyFlightData` with this data path & an empty cache node.
`applyFlightData` checks to see if the flight data contains cache nodes
("seed data"). If it doesn't, then that means it has no work to do, and
it bails out. Pre-PPR and in the case of having a `loading.js` file,
`walkTreeWithFlightRouterState` doesn't return any seed data, just
router state. This means that `applyFlightData` will not have any work
to do on the new cache node, and leaves it untouched.
Once `applyFlightData` is finished, but while still in the flight data
path loop, we reassign `currentCache` to the empty cache object we
created prior to `applyFlightData`. But since that cache node has
remained empty, the next iteration of the loop is going to be inspecting
a now empty cache, rather than the actual "current" cache. Now there's
no existing cache to copy into the new cache. The app now doesn't know
about any cache nodes.
### How
It doesn't seem like we should be re-assigning `currentCache` to the new
cache. In the context of a navigation, it seems more accurate to always
assume `currentCache` is the cache _now_, since it won't actually be
applied to the state until the action has finished (`mutable.cache` is
currently taking care of this).
Closes NEXT-2223
Fixes#61080
followup to: https://github.com/vercel/next.js/pull/60645
### Background
When prerendering the determination of whether a prerender is fully
static or partially static should not be directly related to whether
there is a postponed state or not. When rendering RSC it is possible to
postpone because a dynamic API was used but then on the client (SSR) the
postpone is never encountered. This can happen when a server component
is passed to a client component and the client component conditionally
renders the server component.
Today if this happens the entire output would be considered static when
in fact the flight data encoded into the page and used for bootstrapping
the client router contains dynamic holes. Today this is blocked by an
error that incorrectly assumes that this case means the user caught the
postpone in the client layer but as shown above this may not be the
case.
### Implementation
A more capable model is to think of the outcome of a prerender as having
3 possible states
1. Dynamic HTML: The HTML produces by the prerender has dynamic holes.
we save the static prelude but expect to resume the render later to
complete the HTML. This means we will resume the RSC part of the render
as well
2. Dynamic Data: The HTML is completely static but the RSC data encoded
into the page is dynamic. We don't want to resume the render but we do
need to produce new inlined RSC data during a Request.
3. Static: The HTML is completely static and so is the RSC data encoded
into the page. We save the entire HTML output and there will be no
dynamic continuation when this route is visited.
Really 1 & 3 are the same as today (Partially static & Fully Static
respectively) but case 2 which today errors in a confusing way is now
supported.
In addition implementing the Dynamic Data case the old warning about
catching postpones is removed. The reason we don't want this is that
catching postpones is potentially a valid way to do optimistic UI. We
probably want a first-party API for it at some point (and maybe we'll
add the warning back in once we do) but imagine you do something dynamic
like look up a user but during prerender you want to render as if the
user is logged out. you could call `getUser()` in a try catch and render
fallback UI if it throws. In this case we'd detect a dynamic API was
used but we wouldn't have a corresponding postpone state which would put
us in the Dynamic Data case (2).
Another item to note is that we can produce a fully static result even
if there is a postponed state because users may call postpone themselves
even if they are not calling dynamic APIs like headers or cookies. When
this happens we don't want to statically capture a page with postponed
boundaries in it. Instead we immediately resume the render and abort it
with a postponed abort signal. This will cause the boundaries to
immediately enter client render mode which should speed up recovery on
the client.
#### Technical Note
Another note about the implementation is that you'll see that regardless
of which case we are in, if there is a postponed state but we consider
the page to be Dynamic Data meaning we want to serialize all the HTML
and NOT do a resume in the dynamic continuation then we immediately
resume the render with and already aborted AbortSignal. The purpose here
is to mark any boundaries which have dynamic holes as being
client-rendered.
As a general rule if the render produces a postponed state we must do
one of the following
1. save the postponed state and ensure there is a dynamic continuation
that calls resume
2. immediately resume the render and save the concatenated output and
ensure the dynamic continuation does NOT call resume.
or said another way, every postponed state must be resumed (even if it
didn't come from Next's dynamic APIs)
#### Perf considerations
This PR modifies a few key areas to improve perf.
Reduces quantity of *Stream instances where possible as these add
significant overhead
Reduces extra closures to lower allocations and keep functions in
monomorphic form where possible
Closes NEXT-2164
### What
We'd like to deploy generated rustdocs from turbopack & related packages
(next-swc), setting up a CI workflow to automate those.
Since we need next.js side packages to build docs, this CI sets up
things in this repo.
Closes PACK-2375.
## Changes
It's dynamic now, no longer a fixed 15.
### Before
```
name: Notify about the top 15 PRs (most reacted) in the last 90 days
```
### After
```
name: Notify about the top PRs (most reacted) in the last 90 days
```
### What?
Bump up turbopack to latest. This is to cut off turbopack **before**
including filewatcher changes, so we can easily bisect & revert if
watcher have regressions.
Previously, this error was confusing because it made it sound like the
`sizes` prop was missing. This was because the default value of `sizes`
is `100vw` so the previous code couldn't tell the different between
implicit vs explicit `100vw`.
This PR changes the code to read the input value from the `sizes` prop
and prints a better warning.
Fixes NEXT-2441
