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
