This replaces the `(global as any)._nextDevHandlers` invocation with references to a specific service instance while also removing the module scoped `devInstances`. This ensures that correct types are used.
This was done while changing the `match` parameter in `ensurePage` to `definition` which didn't cause a typescript error (it should have).
The PR supersedes the https://github.com/vercel/next.js/pull/53150, which is way too outdated, has way too many conflicts, and also heavily relies on GitHub Copilot (which makes the progress slow and tedious).
The PR uses [`json-schema-to-zod`](https://github.com/StefanTerdell/json-schema-to-zod) (instead of the GitHub Copilot) to generate the zod schema, and manually replaces all generated `z.customRefine` with my hand-written zod schema.
TODO:
- [x] Convert schema
- [x] Reduce `z.any()` usage
- [x] Create human-readable errors from the `ZodError`
- [x] Update test cases to reflect the latest error message
-----
The benefit of using zod over ajv:
- Easier maintenance: zod schema is straightforward to compose.
- Better typescript support: config schema now strictly reflects the `NextConfig` type.
- Smaller installation size: by replacing `ajv` and `@segment/ajv-human-errors` w/ `zod`, I am able to reduce installation size by 114 KiB.
- Better Extension: the zod error message is easy to customize.
-----
In the previous PR https://github.com/vercel/next.js/pull/56083, @feedthejim replaces `zod` w/ `superstruct`. `superstruct` is lightweight and fast, which makes it perfect for creating simple schemas for RSC payload. But, this also means `superstruct` has its limitations compared to `zod`:
- `superstruct`'s syntax is different, and some utilities's usage is counter-intuitive:
- `z.array(z.string()).gt(1)` vs `s.size(s.array(s.string()), 1)`
- `z.numer().gt(1)` vs `s.size(s.number(), 1)`, `s.min(s.number(), 1)`
- `z.boolean().optional().nullable()` vs `s.nullable(s.optional(z.boolean()))`
- `superstruct` has weaker TypeScript support and worse DX compared to `zod` when composing huge schema:
- `zod.ZodType + z.object()` can provide a more detailed type mismatch message on which specific property is the culprit, while `Describe + s.object()` provides almost no information at all.
- `zod`'s schema is more powerful
- `z.function()` supports `z.args()` and `z.returns()`, while `superstruct` only has `s.func()`
- zod also has Promise type `z.promise()` and intersection type `z.and()`
- `superstruct`'s error is harder to parse compared to `zod`'s `ZodError`
So in the PR, I re-introduced `zod` for `next.config.js` validation.
This adds types for the component modules so that the modules no longer need to rely on `ComponentMod` being `any`. This allows stricter typing for those elements.
This also improves types around template files to allow their exports to form the `ComponentMod` types.
### What?
This implements Server Actions inside the new Turbopack next-api bundles.
### How?
Server Actions requires:
1. A `.next/server/server-reference-manifest.json` manifest describing what loader module to import to invoke a server action
2. A "loader" entry point that then imports server actions from our internal chunk items
3. Importing the bundled `react-experimental` module instead of regular `react`
4. A little 🪄 pixie dust
5. A small change in the magic comment generated in modules that export server actions
I had to change the magic `__next_internal_action_entry_do_not_use__` comment generated by the server actions transformer. When I traverse the module graph to find all exported actions _after chunking_ has been performed, we no longer have access to the original file name needed to generate the server action's id hash. Adding the filename to comment allows me to recover this without overcomplicating our output pipeline.
Closes WEB-1279
Depends on https://github.com/vercel/turbo/pull/5705
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
There's lots of situations in Next.js where we want to ensure that only one operation is in progress at a time for a given task. An example of this is our response cache. The expectation is that for multiple requests for the same page should only result in a single invocation. This isn't new behavior, but this abstracts the batching interface away so we don't duplicate it.
There should be no shared react packages in our server runtime. rsc should always be separate from ssr.
This update reconfigures the runtiem to eliminate shared react modules. the jsx runtime will now be separate for RSC and SSR. this is necessary because the implementations for the jsx runtime rely on React and they need to see the right versions.
Additionally I fixed an alias so that the shared subset react is used when using react-server condition.
I also fixed a bug in 2 tests related to class/className.
Note: this PR blocks upgrading React canary due to internal changes in how React state is managed in when using the `react-server` condition
### What?
* node.js doesn't allow module requests starting with `.` since node.js
18, so we need to remove out .pnpm special case
* externals should be resolvable from the project dir instead of the
root dir
* fix a problem when the list of externals is empty
### Why?
### How?
Closes WEB-1703
Example usage of `readFileSync().toString()` first creates a `Buffer` instance and later does another C++ call to convert Buffer to UTF-8. This pull request reduces the C++ calls.
When the function name is omitted webpack generates a name from the loader config which can be really long un-necessarily. Providing a name for the default function alleviates this. cc @shuding who found this
Using `await fs.access` has couple of downsides. It creates unnecessary
async contexts where async scope can be removed. Also, it creates the
possibility of race conditions such as `Time-of-Check to Time-of-Use`.
It would be nice if someone can benchmark this. I'm rooting for a
performance improvement.
Some updates from Node.js land:
- There is an open pull request to add V8 Fast API to `existsSync`
method - https://github.com/nodejs/node/pull/49893
- Non-existing `existsSync` executions became 30% faster -
https://github.com/nodejs/node/pull/49593
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Today when we hydrate an SSR'd RSC response on the client we encounter import chunks which initiate code loading for client components. However we only start fetching these chunks after hydration has begun which is necessarily after the initial chunks for the entrypoint have loaded.
React has upstream changes that need to land which will preinitialize the rendered chunks for all client components used during the SSR pass. This will cause a `<script async="" src... />` tag to be emitted in the head for each chunk we need to load during hydration which allows the browser to start fetching these resources even before the entrypoint has started to execute.
Additionally the implementation for webpack and turbopack is different enough that there will be a new `react-server-dom-turbopack` package in the React repo which should be used when using Turbopack with Next.
This PR also removes a number of patches to React src that proxy loading (`__next_chunk_load__`) and bundler requires (`__next_require__`) through the `globalThis` object. Now the react packages can be fully responsible for implementing chunk loading and all Next needs to do is supply the necessary information such as chunk prefix and crossOrigin attributes necessary for this loading. This information is produced as part of the client-manifest by either a Webpack plugin or Turbopack.
Additionally any modifications to the chunk filename that were previously done at runtime need to be made in the manifest itself now. This means we need to encode the deployment id for skew protection and encode the filename to make it match our static path matching (and resolutions on s3) when using `[` and `]` segment characters.
There are a few followup items to consider in later PRs
1. we currently bundle a node and edge version of react-server-dom-webpack/client. The node version has an implementation for busboy whereas the edge version does not. Next is currently configured to use busboy when handling a fetch action sent as multipart with a node runtime. Ideally we'd only bundle the one platform we are buliding for but some additional refactoring to support better forking is possibly required here
This PR also updates react from 09285d5a7 to d900fadbf.
### React upstream changes
- https://github.com/facebook/react/pull/27439
- https://github.com/facebook/react/pull/26763
- https://github.com/facebook/react/pull/27434
- https://github.com/facebook/react/pull/27433
- https://github.com/facebook/react/pull/27424
- https://github.com/facebook/react/pull/27428
- https://github.com/facebook/react/pull/27427
- https://github.com/facebook/react/pull/27315
- https://github.com/facebook/react/pull/27314
- https://github.com/facebook/react/pull/27400
- https://github.com/facebook/react/pull/27421
- https://github.com/facebook/react/pull/27419
- https://github.com/facebook/react/pull/27418
### What?
Deduplicates our env var injection between the JS and rust side
Closes WEB-937
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
This refactors a bit of the typescript types around the export and build pipelines. This does not introduce any new functionality.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
This updates to make build/server tracing parallelized with our webpack
compilations so that it can start right after the server compilation is
finished instead of after all compilations are finished. This
parallelizing requires the `experimental.webpackBuildWorker` config be
enabled and doesn't change behavior without it.
Part of this also cleans up our plugin state restoring/handling to use
serializable structures instead of serializing/deserializing manually.
### What?
Fixes the pages router not receiving a hash when being linked from the
app router.
### Why?
The hash being removed breaks sites that rely on it for client side
features.
### How?
The hash gets omitted from the URL when used as a key for the
preflightCache. Once it's clear that it's an external URL and that it's
not empty we can use the initial href to send the hash as well.
Not completely sure if there's an edge case that might break, I added an
extra check for when the hash is only used to scroll the page.
This might need an additional test case just for
`navigate-reducer.test.tsx`.
Fixes#56212
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Fixes#53190.
Next.js App Router comprises two categories of resources, same-origin ones (RSC payload, in the form of inline `<script />`) and possibly third-party ones (chunks that respect the `assetPrefix`). The latter should also respect the `crossOrigin` option from `next.config.js`.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Reland #54403
Also modifies the implementation of #55950 to not change the prefetch behavior when there is flight router state - we should only check the entire loader tree in the static prefetch case, otherwise we're inadvertently rendering the component tree for prefetches that match the current flight router state segment. ([slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1695862974745849))
This includes a few other misc fixes for static prefetch generation:
- `next start` was not serving them (which also meant tests weren't catching a few small bugs)
- the router cache key casing can differ between build and runtime, resulting in a bad cache lookup which results suspending indefinitely during navigation
- We cannot generate static prefetches for pages that opt into `searchParams`, as the prefetch response won't have the right cache key in the RSC payload
- Layouts that use headers/cookies shouldn't use a static prefetch because it can result in unexpected behavior (ie, being redirected to a login page, if the prefetch contains redirect logic for unauthed users)
Closes NEXT-1665
Closes NEXT-1643
This PR enables the generation of source maps for the bundled runtimes. This is fast enough that we can just use the optimal source map option directly. This is useful if you're having some errors in Next.js itself.
### What?
clear require cache only when there has been changes
Before we cleared the require.cache after every ensurePage call. This is
too much. The new approach compares the hashes of all emitted files with
the previous hashes and only clears require.cache when they differ.
### Why?
reloading a page and client navigation is slow due the re-requiring
server files
Closes WEB-1686
It's merged into single process after #54813 , we don't need to filter ipc server headers anymore. Still need to keep header filters for server actions
This ensures we properly set the `isReady` flag when building with `experimental-compile` and enables our main app dir test suite to ensure we don't regress on it.
Depends on vercel/turbo#6036
This constructs a general asset prefix (depending on if basePath and/or assetPrefix is defined), and sets it on Next's and Turbopack's chunking context.
Test Plan: Use a `create-next-app` with corresponding Next.js PR and basePath and assetPrefix specified.
Tested:
- Browser (async) chunk loading
- Static asset loading on server and browser
Closes WEB-1666
This adds the define env for listed options below:
- `crossOrigin`
- `devIndicators`
- `output`
- `analyticsId`
- `optimizeFonts`
- `experimental.useDeploymentId`
- `experimental.useDeploymentIdServerActions`
- `experimental.deploymentId`
- `experimental.manualClientBasePath`
- `experimental.optimisticClientCache`
- `experimental.middlewarePrefetch`
- `experimental.optimizeCss`
- `experimental.nextScriptWorkers`
- `experimental.webVitalsAttribution`
For some there might still be missing pieces, for example `crossOrigin` needs something in Turbopack's script injection but most others will "just work" after this PR.
Added the few ones that did not come directly from config as todos, this PR can be landed without those.
This PR renames some confusing parts of app-render to explicitly name things as Fizz or Flight streams. There're also 2 memory optimizations that in `streamToBufferedResult` we don't need to buffer these chunks and `join` them later. Also the `rscChunks` array isn't used but it is kept in memory for the entire request lifetime.
### What?
This PR is pinning the installed versions of dependencies in `create-next-app`
### Why?
Currently, we write `latest` to `package.json`,
### How?
As far as I can tell, there is no way to update the `package.json` file based on the lockfile (which does have the information needed).
Major versions are bumped less frequently, so this should be fine to update manually.
Other alternatives would be:
- return to the previous way of running `npm i --save` and `npm i --save-dev` instead (ref: #55730). This might be slightly slower than one `npm i` pass though.
- fetch the latest versions of each package from the registry. Might be even slower
NOTE: The user has always the alternative to update the versions to their desired ones afterward.
Fixes#56174
This ensures we properly set a cache-control header for automatically statically optimized pages so we aren't re-re-rendering every time for them when leveraging this mode.
Disable server components and server actions SWC transform when it's running jest. You can only do basic DOM testing like what we described in #54891 instead the server action itself.
Closes#53065
Closes NEXT-1473
This PR adds an option to forcefully bundle node_modules packages in `pages` on the server. This should benefit cold boots for projects that uses pages, at the cost of build time increase.
This one only requires the environment variable to be set. Existing
tests already cover this feature.
With these changes `test/e2e/skip-trailing-slash-redirect` can run,
didn't check if there are failing tests yet.
<!-- 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: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This consolidates our trace handling between turbotrace and the default
`nodeFileTrace` handling to prevent over-tracing. With node-file-trace
it's extremely more efficient to trace in a single `nodeFileTrace` run
so that all resolving/analysis etc can be efficiently cached.
Furthermore, this reduces the amount of chunks we need to trace by
waiting until post build since automatically statically optimized paths
don't need to be traced as they are rendered to purely HTML and never
re-rendered.
This reduces builds times by upwards of 4 - 5 minutes on larger
projects.
Investigating problems this is causing where incorrect flight data is being generated (potentially not correctly bailing on non-static data) causing navigation issues.
Reverts #54403
This PR changes the type for the config `experimental.logging.fullURL` from `false` to `boolean`, i tested it and this config can accept both true and false and will work as expected, it is just the types that are wrong.
### Why?
`permanentRedirect` currently still returns a 307 response if called inside a route handler
<img width="465" alt="image" src="https://github.com/vercel/next.js/assets/44609036/e0cddd37-0292-4865-a423-7bf11ad6beae">
This PR tries to fix that.
### How?
Make `handleTemporaryRedirectResponse` (now renamed `handleRedirectResponse`) accept a status value, then `getRedirectStatusCodeFromError` is used to retrieve that status (307 or 308).
### What?
fixes
```
[Error: Invalid segment components, catch all segment must be the last segment
Debug info:
- Execution of directory_tree_to_entrypoints_internal failed
- Invalid segment components, catch all segment must be the last segment] {
code: 'GenericFailure'
}
```
Closes WEB-1668
**TL; DR**
The PR updates the `jest-worker` to the latest `@27` (which is `jest-worker@27.5.1`) and pre-compile.
---
I use `config.experimental.workerThreads` for my personal website built with Next.js, and I noticed that the react alias (from `require-hook`) is not working, causing `react-dom-server-webpack/client.edge` to fail to resolve.
So I modify the `node_modules/next/dist/build/worker.js` in my personal website project folder to print `process.env.__NEXT_PRIVATE_PREBUNDLED_REACT`:
<img width="761" alt="image" src="https://github.com/vercel/next.js/assets/40715044/f22d72f8-ffd4-49d0-831a-ee3bfd0513ca">
To my surprise, the `process.env.__NEXT_PRIVATE_PREBUNDLED_REACT` prints `undefined` with `config.experimental.workerThreads: true`:
<img width="760" alt="image" src="https://github.com/vercel/next.js/assets/40715044/ad8add14-7ac3-45f5-8f1e-2fec18397410">
But If I disable worker threads with `config.experimental.workerThreads: false`, the `process.env.__NEXT_PRIVATE_PREBUNDLED_REACT` is passed down correctly.
So I dig a little deeper. It turns out to be an old issue of `jest-worker` and has been fixed in https://github.com/jestjs/jest/pull/12069 (in that PR, the custom `env` was passed down to `jest-worker`'s `forkOption`). The bugfix was released in `jest-worker@27.4.0`, but Next.js is still using `jest-worker@27.0.0-next.5`, hence the issue.
### Why?
Whenever I run `create-next-app` and reach this question
```
Would you like to customize the default import alias? No / Yes
```
I always have to select "No", because I don't remember what this default import alias here is. [It _is_ documented to be `@/*`](https://nextjs.org/docs/app/api-reference/create-next-app#non-interactive), but the documentation is relatively hidden and not many people know about it – it's also easy to forget.
Even more confusingly, the next question ("What import alias would you like configured?") doesn't have this `@/*` as the default answer, but the user's last choice as the default answer instead (which could be different from `@/*` – making people wonder if Next.js changed their defaults overnight).
I suppose it would be better to just make it clear in the prompt itself, so people with skill issues who happen to forget that default value (like me) can still confidently select "Yes" if they want `@/*`, without having to do "No" and manually type `@/*` again.
### How
```diff
- Would you like to customize the default import alias?
+ Would you like to customize the default import alias (@/*)?
```
**low-priority chore change**
## What?
This PR removes the 'beta.' prefix from links beginning with it. These links are no longer in beta and are now automatically redirected to their non-beta versions. The change serves as a minor enhancement.
Re-export the original route segment config in metadata routes loader, so they can be picked up by app route module wrapper
Closes#54057
Closes NEXT-1645
The barrel optimization loader creates a virtual module to re-export
from the original file, which causes the situation that now there are 2
modules with the same resource but only one of them is the actual code.
When the code contains `"use client"`, the Flight plugin has to collect
its `buildInfo` and generate the manifest and client entry module.
However, we currently deduplicate module by resource in the traversal
logic to avoid unnecessary loops. To make it work together with the
virtual barrel module, we'll need to prefix the resource path to make it
different from the original module.
Closes#54967.
Closes#55609.
Closes#55566.
This PR implements progressive enhancement for `useFormState`:
1. Inline the form state in `__next_f` and use it for hydration.
2. Encode the new form state based on the action return value, and pass
it to Flight/Fizz.
Also fixed a problem caused by inconsistent React tree structure between
static-generation and non-static-generation.
Inferring the protocol from the request meta is not reliable when the next server is running over `http` but sitting behind an https proxy. This instead plumbs the experimental https flag through to the optimizer so we can more reliably determine the protocol
Fixes#55971
We've rearchitected Next.js+Turbopack so Turbopack does not run
reimplement pieces of Next.js in its devserver. This:
- Removes the `next-dev` binary, which is no longer reachable through
`next --turbo`.
- Removes its test suite, as much of it is tested (and often more
thoroughly) by the Next.js test suite
- Removes its benchmark suite, which should be covered by
`Turbopack-bench` by
https://github.com/vercel/turbo/tree/main/crates/turbopack-bench
Test Plan: CI
Closes WEB-1652
### What?
This PR fixes import source for turbopack's compiler.emotion config, mimics the current webpack configuration behavior.
Unfortunately this does not fixes the whole emotion transform with appdir yet, it looks like there are additional problems with server components.
Closes WEB-1655
This ensures we don't block sending the stream down when handling stale revalidates, in edge runtime we leverage the existing `waitUntil` handling and in node.js runtime we couple this into our pipe readable handling to wait to close the writable until after the promise resolves.
x-ref: https://github.com/vercel/next.js/issues/54193
If multiple weights or styles are requested, e.g. `Open_Sans({ weight: ['300', '400']})` or `Open_Sans({ style: ['normal', 'italic']})`, don't insert css rules for those properties.
Prior behavior was to insert the first ('300' or 'normal' in the above cases), which did not match webpack's behavior.
Closes WEB-1645
Noticed a couple of directories had unit tests in `dist` which are being
run and reported during the Turbopack runs. These are generally quite
small so I'm not expecting this to have much effect on the package size
or CI runs, just making sure the data is correct.
<!-- 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 #
-->
- Related issues linked using fixes#55891
Wrap binaryPath, keyPath, certPath with double quotes
this with casing an error if there is a directory name has a space for ex. folder with name **test https**
### What
#51394 introduced a pretty strict type of return value of route type
that causing failure with `next build`.
There're few ways of writing a app route, it could contain few return
values based on the usage:
* return a `Response` or promise of it
* return `NextResponse` of promise of it, since it's extended from
`Response`, same type
* use `redirect()` or `notFound(), since it returns `never`, and the
below code is not reached, the handler itself could still return void.
e.g. using `redirect` in a `GET` route
We loosed the type so `redirect()` can be still allowed without
specifying the return value there.
Related typescript issue:
https://github.com/microsoft/TypeScript/issues/16608#issuecomment-309327984
### How
* Re-enable the bail on types / build error in the app-routes tests
* Separate the tests, move runtime erroring ones to
`test/e2e/app-dir/app-routes-errors`
* Add new case to app-routes tests of mixed return value
Closes#55623
Related #55604
This fixes some scenarios where executing a server action after navigation can cause the action to behave incorrectly (double submitting, not resolving). There are two separate issues:
- `canonicalUrl` and `pendingNavigatePath` were not constructed using the same function (`createHrefFromUrl`) so in certain situations they'd be comparing different values
- a fulfilled inFlightServerAction should not be invoked again
Closes NEXT-1655
Closes NEXT-1654
Fixes#55845Fixes#55814Fixes#55805
This swaps the existing minifier for the Next.js runtime bundling from [terser](https://github.com/terser/terser) over to [swc](https://swc.rs/docs/configuration/minification). This small change has slightly decreased development file sizes, and dramatically decreased the time it takes to bundle the runtime. The results below were ran once on my MacBook Pro (M1 Pro).
## Compilation Speed
About 3 times faster
- `next_bundle_pages_dev`: improved from 7.28s to 1.85s.
- `next_bundle_pages_turbo`: improved from 7.28s to 1.85s.
- `next_bundle_pages_prod`: improved from 7.28s to 1.93s.
- `next_bundle_server`: improved from 7.28s to 2.68s.
- `next_bundle_app_turbo`: improved from 8.09s to 2.89s.
- `next_bundle_app_turbo_experimental`: improved from 7.74s to 2.77s.
- `next_bundle_app_prod`: improved from 7.86s to 2.77s.
- `next_bundle_app_dev`: improved from 9.41s to 2.86s.
- `next_bundle_app_prod_experimental`: improved from 8.01s to 3.12s.
- `next_bundle_app_dev_experimental`: improved from 9.11s to 3.58s.
- `next_bundle`: improved from 9.50s to 3.69s.
## File Sizes
About the same, small improvements in development bundle sizes
```shell
# Using terser
692K packages/next/dist/compiled/next-server/app-page-experimental.runtime.dev.js
460K packages/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js
460K packages/next/dist/compiled/next-server/app-page-turbo-experimental.runtime.prod.js
436K packages/next/dist/compiled/next-server/app-page-turbo.runtime.prod.js
672K packages/next/dist/compiled/next-server/app-page.runtime.dev.js
436K packages/next/dist/compiled/next-server/app-page.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route-experimental.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api-turbo.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.dev.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.prod.js
64K packages/next/dist/compiled/next-server/pages-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/pages.runtime.dev.js
64K packages/next/dist/compiled/next-server/pages.runtime.prod.js
204K packages/next/dist/compiled/next-server/server.runtime.prod.js
# Using swc
684K packages/next/dist/compiled/next-server/app-page-experimental.runtime.dev.js
460K packages/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js
460K packages/next/dist/compiled/next-server/app-page-turbo-experimental.runtime.prod.js
436K packages/next/dist/compiled/next-server/app-page-turbo.runtime.prod.js
660K packages/next/dist/compiled/next-server/app-page.runtime.dev.js
436K packages/next/dist/compiled/next-server/app-page.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route-experimental.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api-turbo.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.dev.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.prod.js
64K packages/next/dist/compiled/next-server/pages-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/pages.runtime.dev.js
64K packages/next/dist/compiled/next-server/pages.runtime.prod.js
204K packages/next/dist/compiled/next-server/server.runtime.prod.js
```
This:
- Updates to the latest api change for `StdError` in `error_generic_member_access` rust-lang/rust#99301
- Updates `pathfinder_simd` for compatiblity
Closes WEB-1636
### What?
This PR enables basic support for next.config.js's `distDir` config. PR have two main pieces, one for honoring distDir and construct output path other than `.next`, and secondly assign `process.env.__NEXT_DIST_DIR` to client / edge. The latter increased size of PR bit as had to downstream to the compile_define calls.
Corresponding tests are enabled to verify its behavior.
Closes WEB-1610
The IPC request to `imageOptimizer` assumed the server was listening on http, so this updates it to pull the protocol from `getRequestMeta` instead. This also adds the option to pass in a path to the CA Root so that the dev server can add it to `NODE_EXTRA_CA_CERTS`
Closes NEXT-1646
Fixes#55706
### What?
I'm not sure if this is necessary, but while investigating #55689 I found that the RSC code that we send to the client continues to use the ESM outputs during resolution.
The problem is that the RSC server code uses ESM, then tries to send that down to the client. We have a `NextSharedRuntimeResolvePlugin` which handles rewriting _some_ modules (the shared runtimes) to CJS, but that doesn't apply to the main entry points that are RSC rendered, like `app-router`.
### Why?
Webpack seems to only resolve to CJS routes.
### How?
We manually rewrite "transition" entry points to the CJS output, just like the resolve plugin.
Closes WEB-1618
### What?
This was a stopgap for the previous turbopack to ignore some config
validation, but we shouldn't need it anymore with new turbopack to run
test correctly.
Closes WEB-1626
## Why?
Although the left padding makes the output looks good in the terminal, it causes this weird alignment in almost all bug reports:
```yaml
Operating System:
Platform: win32
Arch: x64
Version: Windows 10 Pro
Binaries:
Node: 18.12.0
npm: N/A
Yarn: N/A
pnpm: N/A
Relevant Packages:
next: 13.5.2-canary.2
eslint-config-next: 13.5.2
react: 18.2.0
react-dom: 18.2.0
typescript: 5.2.2
Next.js Config:
output: N/A
```
If I want it to look nice in the bug report
```yaml
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 23.0.0: Thu Aug 17 21:23:02 PDT 2023; root:xnu-10002.1.11~3/RELEASE_ARM64_T8112
Binaries:
Node: 20.3.1
npm: 9.6.7
Yarn: 1.22.19
pnpm: 8.6.12
Relevant Packages:
next: 13.5.2
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0
typescript: 5.2.2
Next.js Config:
output: N/A
```
I have to paste this to a text editor and manually remove the first four spaces on every lines.
### How?
This PR removes that four-space padding to make future bug reports look a bit nicer.
This was causing issues due to needing to run the watcher in a detached process to avoid it clobbering the other build tasks. For now this disables the watcher so we still get the initial types which is generally all that's needed
This fixes memory leaks caused by `prevExports` in react-refresh-utils.
It happens in code like the following:
```tsx
const DATA = Array.from({ length: 100000 }, (_, i) => Math.random());
export const App = () => {
return (
<div>
<div>REWRITE_HERE</div>
<div>{DATA.length}</div>
</div>
);
};
```
After we edit this file to trigger fast refresh, previous `DATA` will be
still retained in the memory since it forms `App(new) -> prevExports ->
App(old) -> DATA` reference chain (there is some screenshots
[here](https://github.com/pmmmwh/react-refresh-webpack-plugin/pull/766)).
I believe there is no reason to retain the whole exports as
`prevExports`. We can just retain "signature" (`string[]`). By only
holding this, we no longer create reference to the old exports, which
fixes the memory leak here. Note that I filed a similar PR in
https://github.com/pmmmwh/react-refresh-webpack-plugin/pull/766 and also
https://github.com/naruaway-sandbox/fast-refresh-hmr-memory-leak-demo is
a reproducible example of this issue, which also explains that
interestingly this issue is not easily solved for Vite.
## Should we fix it?
I think yes, as long as there is no unintended side effect, it's better
to fix it since we cannot predict whether users would load large payload
AND does Fast Refresh many times without reloading the browser or not.
In [this extreme
case](https://github.com/naruaway-sandbox/fast-refresh-hmr-memory-leak-demo),
it eats several hundred mega bytes of RAM.
## Verification
I confirmed that the memory leak is gone with this change by running
https://github.com/naruaway-sandbox/fast-refresh-hmr-memory-leak-demo
with the change.
I am not sure whether new tests are needed but my concern is to
accidentally break Fast Refresh behavior somehow. I believe we have
enough existing test cases 🙏 and I also tested manually.
Since these values are inserted into the cache and read with
`readRecordValue`, they need to have a `status` property otherwise it'll
be re-thrown in `navigate-reducer`. Investigating if this resolves an
issue where under certain circumstances navigations get stuck
suspending.
Closes NEXT-1643
### What?
This updates `NextSharedRuntimeResolvePlugin` to match on `next/dist/esm` pattern instead of matching on `node_modules/next/dist`. While the old code is more correct, it prevents the plugin from working when we're developing Next.js locally, because the imported path is resolved to `packages/next/dist/esm/`, not `node_modules/next/dist/esm/`
### Why?
So that we can develop locally without bugs.
### How?
A simple glob change.
Closes NEXT-
Fixes #
-->
Closes WEB-1616
In order to support updates to the prerendering pipelines, this breaks out some of the prerendering
code into discrete chunks importable for each route kind rather than them all sharing the same
function.
Some small optimizations were made, namely some matcher memoization (only the last one) that should
help with large builds locally.
When running the `dev` task, types aren't emitted so there's a good chance of running into a TypeError like:
```
Type error: Module '"next/dist/lib/metadata/types/metadata-interface.js"' has no exported member 'ResolvingMetadata'.
```
during a `next build` from within the monorepo.
This creates a task to run `types` from within taskr as part of the build step.
### What?
Fixes the error:
```
Refused to apply style from '...' because its MIME type ('application/javascript') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
```
Closes WEB-1606
Can't verify this because there is no clear reproduction and I can't
reproduce it when manually trying, but this will probably fix#55649.
Not sure how they exit the process that it doesn't clean up on the
Node.js side though 🤔
<!-- 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: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
When errors are thrown in middleware it could re-send headers for the same response
```
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
at __node_internal_captureLargerStackTrace (node:internal/errors:490:5)
at new NodeError (node:internal/errors:399:5)
at ServerResponse.setHeader (node:_http_outgoing:645:11)
at origSetHeader (/next.js/packages/next/src/server/base-server.ts:777:16)
at ServerResponse._res.setHeader (/next.js/packages/next/src/server/base-s
erver.ts:777:16)
at setHeader (/next.js/packages/next/src/server/base-http/node.ts:84:15)
at renderErrorImpl (/next.js/packages/next/src/server/base-server.ts:2790:
11)
at <anonymous> (/next.js/packages/next/src/server/base-server.ts:2777:19)
at trace (/next.js/packages/next/src/server/lib/trace/tracer.ts:213:14)
at DevServer.renderError (/next.js/packages/next/src/server/base-server.ts
:2776:24)
at DevServer.renderError (/next.js/packages/next/src/server/next-server.ts
:1299:18)
at DevServer.handleRequestImpl (/next.js/packages/next/src/server/base-ser
ver.ts:1185:23) {
code: 'ERR_HTTP_HEADERS_SENT'
}
```
Migrate middleware-errors test to e2e test to avoid flaky assertion due to duplicated logging collected in integration test.
Closes NEXT-1629
In JS, Promise's are used to help manage async tasks and control flows. When code calls methods on a promise like `.then()`, `.catch()`, or `.finally()` the results of the promise are forwarded to the callback as soon as they're resolved. This serves to make a change to the promise creation such that we do not await on the promise until we're within the try/finally block. This will ensure that the promise will always be added to the map before it's resolved or rejected and it's cleanup (removing it from the active promises) is also completed.
This additionally introduces a new `scheduleOnNextTick` method and polyfill for `Promise.withResolvers()`.
`scheduleOnNextTick` is based on the scheduling algorithm used by https://github.com/graphql/dataloader which utilizes a `Promise.resolve()` combined with `process.nextTick` in order to schedule an operation to occur after the promises have resolved (see [graphql/dataloader](d336bd1528/src/index.js (L213-L255)))
The `Promise.withResolvers()` polyfill is an implementation of a soon-to-be-landed spec for inside-out promises. [Read the spec](https://tc39.es/proposal-promise-with-resolvers/)
## Fixing a bug
### What?
On these versions, SIGINT signals are `string`, exit callback recieves code `number`
### How?
We use code argument to quit process for `event`, and exit with code `0` for `SIGINT` and `SIGTERM` signals
Fixes#55605
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
[As of Bun v1.0.0](https://bun.sh/blog/bun-v1.0#changelog-since-v0-8), `bun dev` runs the "dev" script from package.json. Therefore, as with Yarn and pnpm, the "run" command is not necessary.
This PR changes the `create-next-app` README templates to show `bun dev` instead of `bun run dev`.
`isAppLayer` condition was missing `app-metadata-route` layer, made it
as a util now like other webpack layer utils, add metadata route layer
to the group. Then `React.cache` can be available there.
Also update regex to be compatible across platform
Fixes#55561
Closes NEXT-1635
This consolidates how we're evaluating when to opt into `react@experimental` since it's sprinkled in a lot of spots. Also adds a new flag to opt into the experimental channel
Closes NEXT-1632
Feedback from https://github.com/vercel/next.js/issues/48748#issuecomment-1714292279.
As per my testing, an App Router route of
```tsx
'use client'
import { Button } from 'mui-core'
export default function Page() {
return <Button>Hi</Button>
}
```
was improved from `2.4s (1221 modules)` to `1458ms (649 modules)` for the local dev.
Seems we occasionally have unhandledRejections with `ensurePage` due to
the our memoize handling not attaching `.catch` quick enough. This
updates to ensure `.catch()` is always present for that promise and
re-throwing separately.
Also, ensures the necessary `module.compiled` files for `route-modules`
are included in our build traces.
x-ref: [slack
thread](https://vercel.slack.com/archives/C04KC8A53T7/p1695072157528389?thread_ts=1695060035.024789&cid=C04KC8A53T7)
We need to disable the default treat `middleware` and `pages/api` as
server-only, unless users explictly import "server-only" to poison it.
This will avoid the case that when a library is mixing "client-only" API
and shared components API in one bundle, and the shared API is used in
middleware or `pages/api` that might cause error. See the test case
added.
Follow up for #55394
## For Contributors
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide
### What?
add bun run dev command to template readme for create-next-app
Some people are using `ReactDOM/server` in some contexts like App Routes and Server Actions. The changes in #55362 made it so that there were no more aliases if they wanted to use it so it would fallback to their versions of React, which might not include the APIs you would expect from canary.
Also reverting the decision to proxy `ReactDOM/server` to `ReactDOM/server.edge` in the SSR layer as the APIs are not the same.
### `useSearchParams`
server router's query includes both search params and path params, this PR eliminate the path params from `useSearchParams` to make it aligned between app router and pages router
### `useParams`
For pages, we extract the params keys with `getRouteRegex`, and pick them out from `router.query`
Fixes#54242
Closes NEXT-1536
Users want to use `server-only` to restrict the middleware / app routes / pages api, but now it's failing as we're treating them as different webpack layers, but validating the `server-only` only with server components layers.
Here we modify the rules a bit to let everyone can use "server-only" for the bundles that targeting server-side.
For next-swc transformer, we introduce the new option `bundleType` which only has `"server" | "client" | "default"` 3 values:
* - `server` for server-side targets, like server components, app routes, pages api, middleware
* - `client` for client components targets such as client components app pages, or page routes under pages directory.
* - `default` for environment like jest, we don't validate module graph with swc, replaced the `disable_checks` introduced [#54891](https://github.com/vercel/next.js/pull/54891).
Refactor a bit webpack-config to adapt to the new rules, after that `server-only` will be able to used in the server-side targets conventions like middleware and `pages/api`
Fixes#43700Fixes#54549Fixes#52833
Closes NEXT-1616
Closes NEXT-1607
Closes NEXT-1385
Found that the require hook has some overhead because of reading process.env. This removes the condition after Jimmy reviewed in #55494 as it seems to be no longer needed. Seems to improve RPS by about ~100.
