### What?
Turbopack was missing the list of modules / requests that should never
be marked as external:
8d1c619ad6/packages/next/src/build/handle-externals.ts (L188)
This could lead to errors with i.e. `next/image` not receiving the
correct image config.
Closes PACK-2047
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This improves some of the typings around the `RenderResult` returned during renders. Previously it had a single large metadata object that was shared across both the pages and app render pipelines. To add more type safety, this splits the types used by each of the render pipelines into their own types while still allowing the default `RenderResult` to reference metadata from either render pipeline.
This also improved the flight data generation for app renders. Previously, the promise was inlined, and errors were swallowed. With the advent of improvements in #58779 the postpone errors are no longer returned by the flight generation and are instead handled correctly inside the render by React so it can emit properly postponed flight data.
Besides that there was some whitespace changes, so hiding whitespace differences during review should make it much clearer to review!
### What?
We currently dedupe fetch requests, but if those fetch requests contain a `revalidate` time, when that window is expired all of those fetches will be invoked without deduping.
### Why?
We track revalidations on the `staticGenerationStore` but we don't have a way to dedupe them, as it's currently just an array. When the (patched) fetch is invoked and catches a stale entry, it'll push each fetch onto the `pendingRevalidates` array which will later be invoked via `Promise.all`.
### How?
This updates the shape of `pendingRevalidates` to be a map, that way we can reliably dedupe if we see a key that is already pending revalidation.
Closes NEXT-1744
[slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1700836529460289)
### What
Pairing with https://github.com/vercel/turbo/pull/6602, enables
ecma-related transform support in mdx. notably fixes test cases in
https://github.com/vercel/next.js/pull/58968 .
With turbopack side fix, still modularize imports are not being applied
as we limite it to .js* extension only. PR expands it to include mdx if
mdx is enabled. PR is failling until turbopack side fix lands.
Closes PACK-2045
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Utils `stringToUint8Array` and `arrayBufferToString` assume that the values are just arbitrary fixed width data. However that doesn't work when we do unicode concatenation (`actionId + arg`) which requires Text encoder/decoder to be used.
Closes#58463, closes#58579. In general any complex unicode characters will cause the same issue, for example emojis.
## What?
Was investigating an issue with Turbopack and MDX, in the process found
a few bugs:
- When you have a `tsconfig.json` or `jsconfig.json` the `baseUrl: '.'`
is used by default which causes the top-level directories to be
available as e.g. `design-system` (without a prefix).
- This is not how TypeScript's default setting for `baseUrl` works.
While it should resolve `paths` relative to `.` when none is specified
it does not do additional resolving for the top level directories/files.
- When `"baseUrl": "."` is added to `tsconfig.js` explicitly it handles
the top level directories.
- `modularizeImports` and other SWC transforms weren't applied to `.mdx`
files when `experimental.mdxRs` is enabled, which caused compilation to
fail.
- `modularIzeImports` and other SWC transforms are not applied to `.mdx`
files when using Turbopack.
- @kwonoj is investigating this, will be handled in a follow-up PR.
## How?
- Added a test suite for `modularizeImports` with MDX tests
- Removed the condition that disables swcLoader in webpack when using
mdxRs
- Changed the check for `tsconfig.json` / `jsconfig.json` baseUrl to
include if it was implicitly or explicitly set, disabled the module
resolving when it is implicitly set
<!-- 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 #
-->
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
There're some reports related to using incorrect Node.js version, sometimes users ended up in weird errors. As pkg manager like pnpm only gives a warning ` WARN Unsupported engine: wanted: {"node":">=18.17.0"} (current: {"node":"v16.18.0","pnpm":"8.9.0"})` which is not easy to investigate the issue.
We're adding a version check at the beginning of the Next.js process so if Node.js version is mis-match the version specified in package.json, bail with error.
Examples
node 16.x
```
You are using Node.js 16.18.0. Node.js >= v18.17.0 is required.
```
node.18.16
```
You are using Node.js 18.16.1. Node.js >= v18.17.0 is required.
```
The app router reducer state used to be managed by `useReducer`, so it
was written to be resilient to rebasing — the same action may be
processed multiple times. Now that we've lifted the reducer outside of
React (#56497), each action runs only a single time. So we can simplify
some of the logic.
Previously, actions that update that cache were passed an empty cache
object as part of the action payload. Now, we can instead create these
objects on demand in the reducer.
(We should do the same for the `mutable` object, but there's a unit test
which relies on this implementation detail, so I've left that for a
separate PR.)
<!-- 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 previously used preloadComponent to render nested page/layouts in
parallel, but now that all layouts are passed to React at the top level
(#58669), we no longer need this special module.
A flaw of preloadComponent was that it only called the top-most
component per layout. In the new approach, React can preload non-layout
components, too.
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
In anticipation of #58885 (and to avoid adding another spot where we're checking the same headers), this unifies the logic that parses the request headers and determines if the request corresponds with a server action.
There was already some drift between the check in `base-server` and `action-handler` (unsure if this was intentional - let me know if so, in which case maybe separated handling is the better approach. I couldn't think of a good reason why it would be different, though).
Existing tests should be sufficient for testing this changeset.
No change in behavior, this just moves a util that performs the same
error digest parsing into the other file that performs similar behavior
& validation. Since splitting & parsing the digest string is a strange
operation, this keeps it close to where that happens & where it's
validated so it's easier to follow.
Since this file is imported in the same spots that we're importing the
other redirect utils, there doesn't seem to be a reason to keep them
separated.
### What?
Shows the actual request url that triggered a compilation in the console
message
### Why?
makes it easier to find accidental compilation
### How?
Closes PACK-2017
### What?
* rename `ssr` in app to `app-ssr`
* rename `_` to `-` in layer names
### Why?
`ssr` layer name was used twice, but it must be unique to avoid hanging
compilation
Closes PACK-2036
### What?
We can use the GitHub actions artifact (which is already produced right
now) instead of a separate git branch to get the latest test results.
This also means we don't have a dependency back to the turbo repo for
the daily tests.
Closes PACK-1951
The sandboxed request processing do not share the same async context with the `BaseServer` and thus the context should be propagated independently.
Notably, the `headers` API is different in `BaseServer` (`Record<string, string | string[]>`) vs in the sandbox (`Headers`), so additionally, we have to use the right `getter`.
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
### What?
* remove the additional check which verifies identity of resolved and
external module.
* `serverComponentsExternals` will force it being an external
### Why?
### How?
Closes PACK-2032
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Since we reset the test project on every e2e CI run, deployment protection is automatically enabled by default.
This adds an option to the reset project workflow to disable deployment protection. Our test runners need to be able to hit these pages from an unauthenticated browser in order for the tests to work.
Verified tests are running properly in [this run](https://github.com/vercel/next.js/actions/runs/6971348806/job/18971225559) (fixing any failing tests themselves are out of scope for this PR; will evaluate once the run finishes)
Closes NEXT-1732
We have identical `resetProject` code used in `bench/vercel` and our e2e workflow action -- this updates the `resetProject` script to side-effects free (hence removing the env var) and shared between bench & e2e
Closes NEXT-1731
* Add docs link to the warning, add codemod link to viewport docs section
* Only log the warning once after the metadata resolving process, this will avoid multiple duplicated logs showing for one page.
Closes NEXT-1723
### What?
Rewrites to an edge route currently throw an invariant rather than properly serving up the page that is rewritten to.
### Why?
The `NextRequest` object that is provided to the edge route handler contains pathname information only for the "origin" request (e.g., when visiting `/one/example` which rewrites to `/two/example`, the pathname is still `/one/example`. This hits an invariant since the route matcher is unable to find `/one/example` since it does not exist.
### How?
This updates the module wrapper to grab the pathname from the route definition rather than the request object. For dynamic segments, we extract them from `request.nextUrl` since we know that even if `nextUrl` is referencing the origin path, the parameters it has are relevant for the rewrite.
This adds the `getUtils` utility that's also used in base-server to handle the URL normalization, which also provides an interface for normalizing dynamic params from a `ParsedUrlQuery`.
Closes NEXT-1724
Fixes#48295
### What?
This virtual module was created in a weird path/filesystem: [node]/.next/server/app/.../page/actions.js. It's in the output filesystem, which can't access the monorepo root, so it can't resolve the tsconfig. But it shouldn't be in that filesystem in first place.
Closes PACK-2025
This PR adds more information to `.next/trace` for local development:
- Break down server startup times into setting up the dev bundler and running the instrumentation hook
- Add top level span for handling a request such as a page request, app router request, or API request
- Add span for compilation time tracking the path of the route that triggered the compilation.
- Track memory usage after every request
- Track event when server is restarted due to reaching the memory limit
Platform stats and memory usage on startup:
Memory usage after each request:
<img width="340" alt="Screenshot 2023-11-20 at 9 16 44 AM" src="https://github.com/vercel/next.js/assets/7355009/d14279d6-35c5-45a6-b431-b485d5d14ac6">
Split server startup times into setting up the dev bundler and running the instrumentation hook:
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
This PR doesn't treat an instrumentation hook as a `PAGES` page which
avoids compiling `_app`, `_document`, and `_error` when compiling the
instrumentation hook.
