### 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:
![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
## 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?