There're 3 layers in the RSC module graph: server → client → action. "Action" means that a Client Component re-enters the server layer by importing a file with `"use server"`, and it should behave the same as the server layer but you can't enter the client layer again (hence we have a 3rd layer name).
Since the action layer has the same behavior and module resolution rules, it should be bundled just like the server layer.
Closes#50658. Originally the issue was that `auth/next` isn't being bundled on the action layer, and it has the async local storage imported. Because of that, that storage comes from node_modules instead of the server bundle.
fix NEXT-1290
This attempts to avoid IPv6 and IPv4 resolve issues across network
setups by locking down our internal IPC requests to just one address for
consistency. This way there aren't issues when `localhost` resolves to
one or the other in different cases.
x-ref: https://github.com/vercel/next.js/issues/49677
This PR updates `.vercel.approvers` files to fix some validation errors
and to more closely match desired behavior for assigning and notifying
members of the team for reviews that was discussed on an internal Slack
thread.
- Owners files for `.cargo/` and `.config/` are moved to their
respective directories instead of being placed at the root.
- Fixes the `@vercel/next-js` team name (it uses a dash instead of a
period)
- Adds `:notify` to reviewers so that all of the people listed are
notified of the pull request, but only a single person would be
requested as a reviewer.
- `@vercel/web-tooling:optional` was made optional so that they are not
requested for any change to `pnpm-lock.yaml` but still have the ability
to approve PRs that modify it.
---------
Make sure we are using `var` instead of `const` as we always put the new
appended statements to the end of the module body, but they can still be
referenced before in the HOC case in the runtime. This causes a runtime
error.
Tl;dr: `a = 1; var a` is fine, but `a; const a = ...` will result in a
compilation error.
Closes#49344.
It's valid to want to output JSON instead of HTML for the bundle
analyzer so we can expose this specific config the same as
`openAnalyzer`. cc @mknichel
Remove the Server CSS manifest and related logic, and use the chunkGroup
CSS files instead for each entry to inject stylesheet links.
Why was that manifest needed in the first place? When implementing CSS
collection for RSC and nested layout initially, we collect CSS imports
at each layer and create corresponding client entries. But then soon got
hit by the problem of duplication and improper tree-shaking. Two layers
can have the same CSS imported so we solved it in a way that "if an
upper layer imports this module, skip it in child layers". Note that
this is deduped by module, so we need to keep the information of "layer
(entry) → CSS modules" somewhere, in a manifest.
Another reason is that we create the client entry before Webpack
optimizes modules, so we can inject the client entry into the same
compilation. But that means the collected client modules from the server
layer are not properly optimized (DCE). **This is a general issue at the
moment that's not specifically related to CSS, although using that
manifest to collect DCE'd info and join the original collected CSS files
with that info temporarily solved it.** That's why I disabled some tests
related to font CSS collection and want to improve it in a more general
way.
Why is that not needed anymore? Main reason is to keep a good balance
between duplication and number of chunks, and delegate the decision to
Webpack's splitChunks plugin. It is not possible to get to a point of 0
duplication unless we ship every CSS module as a single chunk. And since
in #50406 we made the duplication better but at the chunk asset level,
instead of the original module level.
Prior work: #50406, #50610.
### What?
Fixes https://github.com/vercel/next.js/issues/50129
### Why?
The current denormalization of app dir paths doesnt account for the
normalization done in `normalizeAppPath`, causing build log outputs for
certain paths such as anything under a route groups to be incorrect
### How?
There's 2 ways this could be fixed:
1.) Denormalize the app dir paths by reading the
`app-path-routes-manifest.json` and mapping back to the original file
path
2.) (what I chose to do) Normalize the keys of `appBuildManifest`
### Result
App dir paths, including route groups, now have their correct output
size
<img width="494" alt="image"
src="https://github.com/vercel/next.js/assets/93682696/0eee79b8-7d60-4c88-b07a-dfb750aa9592">
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This cleans up some setup functions within the route modules, improves logic around headers, and handles the case where the URL is invalid better for routes using the request adapters.
Similar to tags and paths, when `cookies().set()` is called we have to
invalidate the client router cache as well so routes with
`cookies().get()` will not holding the stale data. This is critical for
auth and other scenarios.
In the future we can have an optimization to only invalidate routes that
actually rely on cookies, similar to paths.
This PR fixes a few reports that we were double fetching when navigating via a link that had prefetch false.
## Context
The bug was happening because we were inadvertently eagerly fetching even if we potentially bailed out of the optimistic navigation, which would then trigger another fetch from going through the regular navigation path.
There's potentially another bug here where we should potentially not bail out of optimistic navigation in the cases reported but we can fix that later.
fix#49844
link NEXT-1287
## What?
While looking at the CPU profile of booting up Vercel's site I noticed
that we call `getPageStaticInfo` a lot. Looking into this more it turns
out `getPageStaticInfo` is currently called for all routes, `pages` and
`app`, even though the data is only being used to keep track of which
routes are edge functions, however, this is already tracked as part of
the build output so this didn't make sense to me. First I tried
commenting out this entire block and all tests were passing, so I
removed it except for middleware as middleware can provide a `matcher`
which does need to be known before compiling the file as of right now.
After that change a different set of tests started failing, specifically
the one that checks if we warn correctly. Interestingly by fixing
`getPageStaticInfo` being called early and for all routes it also caused
these warnings to no longer trigger as there was a case in the manifest
plugin that called `getPageStaticInfo` with less information. Calling
`getPageStaticInfo` there was not needed either as we call
`getPageStaticInfo` at the beginning of the build for each entrypoint so
we already have the information required, it just had to be passed down
so that the manifest plugin could use it.
For Vercel's site this change improves booting the dev server by over 1
second.
Related to #48748
<!-- 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
- 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: Jiachi Liu <inbox@huozhi.im>
### What?
Adds mikroORM to external package list
### Why?
To prevent developers using
[MedusaJS](https://github.com/medusajs/medusa) modules with NextJS from
having to add this in their next config.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
When navigating to a route with a hash parameter, the layout router
jumps to the element by scrolling to the node's `offsetTop` value.
However, this will ignore `scroll-padding`, which deviates from browser
behavior.
It looks like this isn't an issue in the pages router which currently
makes use of
[`scrollIntoView`](https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/router/router.ts#L2262).
Closes NEXT-1171
Fixes#49612
---------
### What?
Add all available options to cli commands
Consistent formatting for all options
### Why?
Options were not consistent across all commands, some were missing
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Tweak code owners after some testing and feedback.
- Move the Next.js team up to be optional global code owners (so that everyone can review but are not tagged for review). Global individuals should still be tagged if there are no specific `.vercel.approvers` files in subdirectories.
- Adds @vercel/devex to image files so there's coverage on those files for the docs
- Target specific folder and files for Styfle to get notified
- Deletes some rules in the old GitHub codeowners
This removes the `__internal_nextjs_integration_test` compile-time feature. This would end up requiring an additional set of build targets for running integration tests was only used for two cases:
* Determining whether to read from an env var to load mocked Google fonts responses in next/font/google tests. This now uses the presence of this variable to determine whether to use mocked responses.
* Enabling the `next-dev/serializable` feature. This is now set directly instead.
Test Plan:
* Integration tests with Turbopack.
* Manual test of next/font/google with Turbopack
Both of our bundlers won't split different exports of a module into different chunks, we can rely on https://github.com/facebook/react/pull/26624 to simplify the structure. This reduces the size of the client reference manifest by ~70%.
Fixes#50232
Passing down the private env into `'render-server'` module to pick up the proper react with require-hook in standalone server
fix NEXT-1260
