### Description
- Adds the page path to the middleware template (and also uses the template from the next.js loader)
- ESM aliases for the edge context
- Fix for the process polyfill to make it possible to import from `dist/esm`
- Fix for the `server-only`/`client-only` aliases
Closes WEB-1779
### What?
Adding back `x-forwarded-*` headers.
### Why?
Starting with #52492, these headers were lost.
### How?
We can populate these headers before executing a request.
Closes NEXT-1663
Fixes#55942
### What?
app code is different from pages code and need to be in a separate layer
### Why?
Otherwise it tries to share chunks and will cause conflicting writes
### How?
Closes WEB-1778
`useParams` is not referentially equal between renders which can lead to unexpected behavior when used as a dep.
This memoizes the response from `useParams` similar to `useSearchParams`.
[slack x-ref](https://vercel.slack.com/archives/C04DUD7EB1B/p1697145987740229)
Based on feedback from #56603, the `/` can be interpreted as file paths instead of filename separators / delimiters. We'll change them to use pipes `|` instead.
This adds a new `Revalidate` type which is used internally by Next.js to associate the user inputted value of `revalidate` from `getStaticProps` or the exported `revalidate` variable in app directory.
As discussed with @feedthejim this breaks our E2E deploy tests workflow into it's own so it can be triggered on cron/manually easier.
One thing we'll need to consider with the cron/manual workflow is if a canary isn't published yet and Next.js relies on swc changes it will fail since this doesn't pack/publish a fresh built swc binary currently.
This change is to pick the esm assets for RSC server layer and server rendering side, this is for production and development perf purpose, also to let them apply with the ESM related optimization such as tree-shaking, barrel files optimizations, etc.
We found a few packages that can't be optimized easily in bundling because we're using "main" field so the packages are not able to be tree-shaked, ending up with large bundle in the dist. This will change a lot for the bundling improvements as some packages are only having "main" and "module" field. So switching from CJS to ESM means better bundling, more optimization, and faster code.
#56501 was a precondition for this, as previously the bundling strategy was applied to some library but triggered the invalid hooks erroring.
### Other Monior Change
Previously we'll prefer to resolve CJS as there're 2 versions of react, using CJS assets will help let them pass by require-hook to use canary react for app router bundling assets. But now we changed the approach to bundling nextjs runtime and react packages. Now we dropped the condition that prefered to resolve CJS exports for externals, since if you're putting them in `serverComponentsExternalPackages`, they're not using the built-in react, so could potentially having trouble if any dependency is using react but excluded in bundles. So far we didn't see any report to this.
Closes NEXT-1286
While investigating the failing test case of `test/integration/scroll-forward-restoration/test/index.test.js` I found that navigating from `/another` to `/` using `next/link` with a `href="/"` errored on `ensurePage` as "this page was not built". Turns normalization wasn't applied on these so the input `page` was `/index` instead of `/`, where it expects `/` as the input.
Ensures the webpack-hmr socket is not reconnected infinitely while (and
very quickly) when the dev server is offline. I've implemented a gradual
backoff, after 5 tries at 1 second it'll try 20 times at 5 seconds.
After those 25 retries it reloads the page as something must be wrong
(i.e. the server is offline).
<!-- 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 #
-->
⚠️ This is an internal API and will be removed soon. Please do not use.
Refactors #56404 to have a better internal API used by both Edge SSR and Edge Route Handlers.
This new API can buffer non-synchronously created "waitUntil"s even after the response has been returned, just need to make sure that there's at least one "waitUntil" queued. E.g.:
```js
async function handler() {
internal_runWithWaitUntil(async () => { // ← no await
await taskA()
internal_runWithWaitUntil(async () => { // ← no await
await longRunningTaskB()
})
await taskC()
})
return Response(...)
}
```
Internally, the "waitUntil" promise will resolve after all tasks are finished.
cc @ijjk @cramforce @feedthejim as we've synced about some of the details here. Not using ALS because of some promise-related issues.
In [55841](https://github.com/vercel/next.js/pull/55841), this file was reworked to improve type safety and readability, but it changed the behavior of how we were invoking methods on the worker. Specifically, when a restart occurred, this timeout wrapping function was referencing an already ended worker, resulting in a "Farm is ended, no more calls can be done to it" build error.
This PR ensures that we're fetching the method from the current `this._worker` at the time of invocation, not at the time of method creation.
[Slack x-ref](https://vercel.slack.com/archives/C04KC8A53T7/p1697064752635179?thread_ts=1696952142.759769&cid=C04KC8A53T7)
The build manifest when using webpack includes the rewrites config so
that the Pages Router can correctly match the path. The manifest for
Turbopack was missing these properties which caused a bunch of the
middleware tests to fail. This PR reuses the function to generate
rewrites from build-manifest-plugin.
<!-- 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 #
-->
