[pull] canary from vercel:canary #928
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
Batch the dependency messages sent from our nodejs worker process. Some large projects using tailwind may report thousands of dependencies which can cause the node process to hang due to memory pressure. We are addressing the memory pressure issue independently in #78462, but by reducing the number of small packets we can also improve performance.
This enables a new set of cardinality changes for pages with PPR and
Dynamic IO enabled on it. When a set of more specific routes are
generated, we no longer error when the static shell is empty and instead
infer that as a sign that the user doesn't want to provide a route
fallback. If the user does in fact place suspense boundaries above
params access, the fallback shell will not be empty and will be used.
Given the following application structure:
```
/[lang]/layout.tsx
/[lang]/[teamSlug]/page.tsx
```
Where we have the following returned for `generateStaticProps`: `[{
lang: "en", teamSlug: "nextjs"}]`, we'd have the following rendered:
```
/[lang]/[teamSlug] <- empty shell won't cause error
/en/[teamSlug] <- empty shell won't cause error
/en/nextjs <- empty shell will cause error
```
If `/[lang]/[teamSlug]` generated an empty shell, then a request to
`/fr/nextjs` wouldn't use the `/[lang]/[teamSlug]` fallback shell and
would instead generate a new blocking route shell. Otherwise if it
didn't generate an empty shell, it would use the fallback shell that's
outputted.
If `/en/[teamSlug]` generated an empty shell, then a request to
`/en/react` wouldn't use the `/en/[teamSlug]` fallback shell and would
instead generate a new blocking route shell. Otherwise if it didn't
generate an empty shell, it would use the fallback shell that's
outputted.
Support `readFileSync(/* turbopackIgnore: true */ path, 'utf8')` (and same for `path.resolve` and `path.join`) to ignore it during NFT tracing We already had the infrastructure, just member calls and then specifically the NFT access functions needed to be handled. Would fix the failing test in #78358 Part of PACK-4426
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
This auto-generated PR updates font data with latest available Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
…ute to be rendered (#78555) When there's a more specific route available to render, when PPR is disabled but Dynamic IO is enabled, we should skip the prospective diagnostic render because it would have been skipped as a part of the PPR render anyways.
This PR prunes references to Vercel in the documentation. Some of the mentions were egregious and unneeded. Others were documenting specific behavior for how Next.js runs on Vercel, which is better suited for the Vercel documentation. It also restructures our deployment documentation to remove any previous bias toward Vercel. Rather than separating self-hosting (Node.js server, Docker, static export) into its own section from managed platforms, it now lists them all together. Vercel is listed under "Adapters", alongside Netlify, Cloudflare, and AWS Amplify (in alphabetical order). These are the companies we're working with on the [Deployment Adapters API](#77740), who currently maintain their own adapters and will eventually migrate to use this new API. We've [started working on](#78166) that API. For different features in the docs, like ISR or Middleware, this PR also adds a new feature matrix that shows the different deployment options and whether this feature is supported. For example, features that require using the server are not supported with static exports. Additionally, when there is configuration possible (like changing the caching behavior of ISR) we link back to our guide which explains these options in detail.  This PR also updates the Middleware section of the self-hosting guide to mention [Node.js runtime support](https://nextjs.org/blog/next-15-2#nodejs-middleware-experimental). I've also removed the "Managed Next.js (Vercel)" entry for the docs sidebar, as it is not necessary and Vercel should not have additional priority there over other providers.  Netlify has confirmed they're okay with the specific feature matrix link included in the adapters section, and I did my best to include the Cloudflare and Amplify versions based on their documentation. If any of the providers want to see changes to those links, please let me know and I'll open a PR.
Total nit. As soon as i saw the word `strongly` i thought: 'huh, maybe there is a circumstance where this doesn't hold', which isn't true, so lets fix the doc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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 : )