[pull] canary from vercel:canary #51
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…y api (#78032) [HashMap’s raw_entry api](rust-lang/rust#56167), an unstable nightly feature, was removed from the Rust compiler entirely. This migrates us to use the equivalent API in HashBrown’s HashMap.
Show a redbox when specifying a non-existent plugin instead of crashing Turbopack The error location could be better, but we don't actually know the line/column here 
The conventional wisdom of Node.js and other runtimes is to treat
unhandled errors as fatal and exit the process.
But Next.js is not a generic JS runtime — it's a specialized runtime for
React Server Components.
Many unhandled rejections are due to the late-awaiting pattern for
prefetching data. In Next.js it's OK to call an async function without
immediately awaiting it, to start the request as soon as possible
without blocking unncessarily on the result. These can end up triggering
an "unhandledRejection" if it later turns out that the data is not
needed to render the page. Example:
```js
const promise = fetchData()
const shouldShow = await checkCondition()
if (shouldShow) {
return <Component promise={promise} />
}
```
In this example, `fetchData` is called immediately to start the request
as soon as possible, but if `shouldShow` is false, then it will be
discarded without unwrapping its result. If it errors, it will trigger
an "unhandledRejection" event.
Ideally, we would suppress these rejections completely without warning,
because we don't consider them real errors. But regardless of whether we
do or don't warn, we definitely shouldn't crash the entire process.
Even a "legit" unhandled error unrelated to prefetching shouldn't
prevent the rest of the page from rendering.
So, we intentionally override the default error handling behavior of the
outer JS runtime to be more forgiving.
---
This was already the behavior of Next.js for self-hosted deployments —
i.e. `next start` — but the rejection listeners were being installed in
a code path that does not run for other deployment targets, like Vercel.
So what this PR does is move the rejection handling code to a path
that's common to all deployement targets.
One possibly controversial aspect that is new to this PR is that it
removes all existing "unhandledRejection" handlers, before Next.js
installs its own. This is to override any handlers that exit the
process. Generally we think this is fine because it's unlikely that
Next.js will be deployed in such a way that it's sharing a process with
non-Next.js applications; however, if we get feedback to the contrary,
we'll figure out a strategy to deal with it.
Attempts to reland parts of #77054. - Removed `#![feature(extract_if)]` - Removed `#![feature(hash_extract_if)]` - Removed no-op `#[must_use]` - Addressed new clippy violations Test Plan: - [ ] Manual build and deploy
…config (#77905) When using both pages & app routers, during `next dev` and `next start`, if a function triggers a 404 error, we serve the app router not found page rather than the pages router one. When paired with the `i18n` configuration in `next.config`, the Next.js builder ignores the app router 404 and bundles the localized pages router 404 pages with the deployed functions. This leads to a 500 error, and is fixed in vercel/vercel#13222 However, to match the dev/start handling, we also need to update the `pages-manifest` so the builder knows to resolve `/404.html` and not the pages router variant when deployed. Fixes NEXT-4045 Validation: [vtest314-e2e-tests-bkc89ab40-ztanner.vercel.app/app-dir/foo](https://vtest314-e2e-tests-bkc89ab40-ztanner.vercel.app/app-dir/foo)
… from crashing (#78042) This broadens the scope of the `removeUnhandledRejectionListeners` flag to also remove `uncaughtException` listeners. The motivation is the same: uncaught exceptions in one part of the page should not prevent the rest of the page from rendering. See #77997 for more context. I renamed the experimental flag to `removeUncaughtErrorAndRejectionListeners` to better reflect increased scope but the name isn't really that important since at this stage we just need to try out the behavior; it isn't documented anywhere.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )