### 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
### 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>
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>
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
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:
Verify that the polyfill file exists and resolves in the browser.
Closes PACK-2993
## What?
Ensures just importing `crypto` does not error, only when it is used it
shows an error in the edge runtime. This matches webpack behavior. The
`crypto` module was missing the list of unsupported packages in the
Next.js Turbopack integration.
Fixes#64464
Fixes PACK-2954
## TODO
While adding tests for this issue I found another bug that only happens
with webpack.
Specifically these 4 packages are accidentally being polyfilled even
when they're not set up to be polyfilled. i.e. there's no npm package
installed for polyfilling them through aliasing or such. Even in that
case `punycode`, `process`, `querystring`, and `string_decorder` get
polyfilled regardless, this causes the newly added test to fail.
Removing the polyfills would be potentially breaking so we'll want to
change it in Next.js 15 instead.
<!-- 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-3252
This extends #64520 to cover cases where client components originate
from node_modules (foreign code).
Test Plan: Extended the integration test to cover this
Closes#64412
Fixes PACK-3014
---------
Co-authored-by: OJ Kwon <1210596+kwonoj@users.noreply.github.com>
### What
- closes#65052
Emitting warning itself is correct, however
- we emit warning multiple times
- missing additional detail to provide link to the docs
PR fixes those 2.
### What?
Add a validation for parallel routes with the same path.
This PR enables
`test/e2e/app-dir/conflicting-page-segments/conflicting-page-segments.test.ts`
### Why?
To match the behavior in the default mode.
### How?
Closes PACK-2912
### What
- closes#63896
PR implements parsing JSValue for the matcher config if given item is an
object. We had those types already declared in place but somehow parsing
ignores it.
### What
Closes PACK-2978, requires https://github.com/vercel/turbo/pull/8005.
PR extends existing mdxRs config from accepting object as well in
addition to current boolean flag, mainly to allow to specify what kind
of markdown types will be used between gfm and commonmark.
### Why
For app page rendering on edge, the `AsyncLocalStorage` (ALS) should be
bundled as same instance across layers. We're accessing the ALS in
`next/dynamic` modules during SSR for preloading CSS chunks. There's a
bug that we can't get the ALS store during SSR in edge, I digged into it
and found the root cause is:
We have both import paths:
`module (rsc layer) -> request ALS (shared layer)`
`module (ssr layer) -> request ALS (shared layer)`
We expect the ALS to be the same module since we're using the same layer
but found that they're treated as different modules due to applying
another loader transform on ssr layer. They're resulted in the same
`shared` layer, but with different resource queries. This PR excluded
that transform so now they're identical across layers.
### What
For webpack, we aligned the loaders applying to the async local storage,
so that they're resolved as the same module now.
For turbopack, we leverage module transition, sort of creating a new
`app-shared` layer for these modules, and apply the transition to all
async local storage instances therefore the instances of them are only
bundled once.
To make the turbopack chanegs work, we change how the async local
storage modules defined, separate the instance into a single file and
mark it as "next-shared" layer with import:
```
any module -> async local storage --- use transition, specify "next-shared" layer ---> async local storage instance
```
Closes NEXT-3085
### What?
Toolchain is updated as well.
Should improve compile times marginally, also added the new parallel
frontend.
Depends on https://github.com/vercel/turbo/pull/7409
Closes PACK-2526
Resolves#64412
This adds a client transition to the app route `ModuleAssetContext` and
the corresponding transforms so that client components can be safely
imported and referenced (as their proxies) in app routes.
Test Plan: Added an integration test
Closes PACK-2964
### 🤔 What's in there?
We've deprecated config's `analyticsId` in 14.1.1 [almost 3 months
ago](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.2).
Users can opt in fot `@vercel/speed-insights`, or use
`useReportWebVitals` to report to any provider they'd like.
This PR:
- removes `analyticsId` key from configuration
- stops setting `__NEXT_PUBLIC_ANALYTICS_ID` env variable when the key
was present
- stops injecting `performance-relayer` file, when the variable is set
- cleans up related test code.
### What?
There is a race condition in the `pull-build-cache` script. When the
remote cache entry was removed between the dry run and the real run, it
will run the command and caches whatever is in the native folder.
Seems like there are some very old leftover files there which lead to an
broken publish.
This changes the command to fail when there are no files and empties the
folder before running the script. This should lead to pull-build-cache
to failing instead.
Closes PACK-2957
Fixes#64468
## What?
- Removes the node-file-trace options from being unsupported as they are
passed to node-file-trace in build/index.ts
- Ensures `import next from 'next'` is handled in the same way as
webpack: creating an empty module. Currently it tried to bundle all
Next.js internals which is wrong.
<!-- 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-3086
### What
CSS imports in components that loaded by `next/dynamic` in client
components will cause the css are missing initial in
SSR, and loaded later on client side which will lead to FOUC. This PR
fixes the issue and get CSS preloaded in the SSR for dynamic components.
### Why
The CSS from client components that created through `next/dynamic` are
not collected in the SSR, unlike RSC rendering we already collect the
CSS resources for each entry so we included them in the server rendering
so the styles are availble at that time. But for client components, we
didn't traverse all the client components and collect the CSS resources.
In pages router we kinda collect all the dynamic imports and preload
them during SSR, but this approach is not able to be applied to app
router due to different architecture. Since we already have all the
dynamic imports info and their related chunks in
react-loadable-manifest, so we can do the similar "preloading" thing in
app router. We use the current dynamic module key (`app/page.js ->
../components/foo.js`) which created by SWC transform and match it in
the react loadable manifest that accessed from `AsyncLocalStorage`, to
get the css files created by webpack then render them as preload
styleshee links. In this way we can SSR all the related CSS resources
for dynamic client components.
The reason we pass down the react loadable manifest through
`AsyncLocalStorage` is that it's sort of exclude the manifest from RSC
payload as it's not required for hydration, but only required for SSR.
Note: this issue only occurred in dynamic rendering case for client
components.
### Other Changes Overview
- Change the react loadable manifest key from pages dir based relative
path to a source dir based relative path, to support cases with both
directory or only one of them
Closes NEXT-2578
Fixes#61212Fixes#61111Fixes#62940
Replacement for #64021 but only with production test
I'm not sure why this issue is impacting me and seemingly not others,
but on Debian 12 with the default linker options (gcc with ld) I get the
following compilation error regarding unresolved symbols:
https://gist.github.com/bgw/92da94f46b0994514a144b8938aa2f6c
This flag downgrades that linker error to a warning (which cargo hides).
I've checked that this flag is supported by ld, gold, lld, and mold.
I've also tried building with mold in addition to ld. I'm restricting
the option to linux to avoid potentially breaking other platforms.
Tested by running:
```
cargo test -p next-swc-napi
```
Which now gives:
```
running 2 tests
test transform::test_deserialize_transform_regenerator ... ok
test transform::test_deser ... ok
```
### What?
Emit `<link data-next-font="size-adjust" rel="preconnect" href="/"
crossorigin="anonymous"/>` in more cases.
### Why?
To align with the default mode
### How?
### What?
Print an error message to stdout if stylesheet fetching fails.
### Why?
To align behavior with the default mode. This PR fixes one integration
test case.
### How?
Closes PACK-2896
### What?
Pass the names of side-effect-free packages specified in `experimental.optimizePackageImports`.
Turbopack counterpart: https://github.com/vercel/turbo/pull/7731
### Why?
Some packages like `@tremor/react` causes a problem without `optimizePackageImports`.
### How?
Closes PACK-2527
### What
Supports partial `get-page-static-info` in turbopack. Since turbopack
doesn't have equivalent place to webpack's ondemandhandler, it uses
turbopack's build time transform rule instead.
As noted, this is partial implementation to pagestatic info as it does
not have existing js side evaluations. Assertions will be added
gradually to ensure regressions, for now having 1 assertion for
getstaticparams.
Closes PACK-2849
### What?
The transform seem to be quite inefficient regarding memory usage. Just
leaving a trace here to allow inspecting performance and memory of it
separately from the normal `parse` function.
Closes PACK-2855
### What
Supports root segment config inherit from layout. Currently route
segment config only runs agasint own source, so individual route segment
config works but if the config is set in layout level it is being
ignored. PR introduces root segment and pass into each route if tree
level have a corresponding layout.
Closes PACK-2839
This PR renames the API to be not specifically related to Server
Actions, as in the future it might be used by other things. It also adds
the `__next_encryption_key_generation_promise` variable to avoid
double-generating of the key when it's called concurrently (e.g. by the
node server and edge server compilers).
Closes NEXT-2938
### What
This PR implements runtime warning for dynamic codes (`eval`,
`Function`...) in edge runtime. Webpack uses middleware plugin to
replace / wrap codes, in case of Turbopack we don't have equivalent, so
creating a new transform visitor and run it if the context is edge.
Since sandbox augments global fn (__next_*), transform simply wraps the
expr if it matches to the condition.
Closes PACK-2804
### What?
route/middleware/instrumentation use server assets
server assets use full url rewrite
### Why?
### How?
https://github.com/vercel/turbo/pull/7750
Fixes PACK-2522
fixes PACK-2645
### What
Implement webpack's middleware plugin equivalent for webpack, to raise
unsupported error in runtime.
PR utilizes import map alias for the edge context, to resolve into
modulereplacer internally provides a virtualsource to call runtime error
logic. Since we already have globally augmented, the virtualsource only
need to take export those into module.
Closes PACK-2789
### What
Fixes to honor metadata route's segment config - turbopack replaces it
into route handler, then parsed segment config so original segment
config was ignored always.
Closes PACK-2762
### What?
* Allow to apply webpack loaders depending on "conditions".
* add a few next specific conditions depending on context type
### Why?
Some loaders need different behavior depending on context
### How?
Closes PACK-2748
### What?
* rename test case
* improve error message and handle edge case for require resolving
* fix test case actually testing externals (webpack was silently
bundling, Turbopack showed error that helped to find the broken test
case)
### Why?
### How?
Closes PACK-2662
### What
Use SWC to check invalid client hooks of `next/navigation` imports in
server components.
Follow up of #62456
Remove the runtime error APIs for `next/navigation` rsc version.
Add `next/navigation` react-server version alias in turbopack.
This PR also refactored the invalid server layer APIs detection into a
map, where key is import path and value is an array of client APIs.
During the traversing we will get the import source easily, this makes
extending the logic much easier
### Why
Previously we're using the runtime error to check it, but it has to run
first then the error will be thrown. If we error first in build time
with this check it's much faster and we this align on both side between
webpack and turbopack.
### What?
add support for `new URL(..., import.meta.url)` assets in edge. e. g.
needed for og-image.
### Why?
### Turbopack Changes
* https://github.com/vercel/turbo/pull/7712 <!-- Tobias Koppers - allow
to use full urls in browser runtime -->
Closes PACK-2725
### What
This PR completes resolve plugin for the invalid import assertion, for
the server-only in client component + styld-jsx in server components.
Closes PACK-2707
### What?
make sure that we don't error for dynamic requests on server side.
It will throw at runtime when using a dynamic request.
### Why?
Not all packages are fully bundler compatible, but still work when only
using the parts that work. We don't want to block users from using them
by having an hard compile error.
### How?
Closes PACK-2675
In addition to the file path, also url-decode the module name
(represented by the `id` query parameter).
Test Plan: Together with vercel/turbo#7682, this fixes `pnpm
testonly-dev test/development/basic/hmr.test.ts "should recover from
errors in the render function"`
Closes PACK-2700
