The `@appsignal/nodejs` instrumentation package fails to load in Next.js
14 due to Webpack failing to bundle its Node.js native extension. Adding
it to the server components external packages list fixes this issue.
Part of https://github.com/appsignal/appsignal-nodejs/issues/1014.
GitHub recommends blobless clones over shallow clones:
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/
> For these reasons we do not recommend shallow clones except for builds
that delete the repository immediately afterwards. Fetching from shallow
clones can cause more harm than good!
I've been using blobless clones for development for the last couple
weeks. The blobless clone has the benefit of including the full
repository history (for the cloned branch). Tools like `git blame` will
be slower as git fetches the related blobs on-demand.
Benchmarks (using all the flags in the docs):
- The blobless clone is faster on my machine, taking 11.1 seconds versus
13.1 seconds for the shallow clone.
- The blobless clone takes up 256M on disk, versus 244M for the shallow
clone. It's worse, but not by much.
### What?
Adds a Node.js example for using assets with `ImageResponse` to create
og images.
### Why?
The only examples available use `new URL` and `fetch` which does not
work when the runtime is using Node.js.
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
When the router cache can't find a cache node for the requested segment,
it performs a request to the server to get the missing data. This
request to the server currently will always include the `next-url`
header, and on soft-navigations, the router will route the request to
the intercepted handler. This lazy fetch is treated as a soft navigation
by the server, and will incorrectly return data for the intercepted
route.
Similar to the handling in `router.refresh`, and the server action
reducer, we should not include the `next-url` header if there's no
interception route currently in the tree, as otherwise we'll be
erroneously triggering the intercepted route.
Fixes#64676
Closes NEXT-3146
Reverts vercel/next.js#64271
This appears to be causing problems rendering error boundaries on SPA
navigations and needs further investigation
Closes NEXT-3150
### Why
If you have a client entry that mixing `default` re-export and `*`
re-export, atm we cannot statically analyze all the exports from this
the boundary, unless we can apply barrel file optimization for every
import which could slow down speed.
```js
// index.js
'use client'
export * from './client'
export { default } from './client'
```
Before that happen we high recommend you don't mixing that and try to
add the client directive to the leaf level client module. We're not able
to determine what the identifiers are imported from the wildcard import
path. This would work if we resolved the actual file but currently we
can't.
### What
When we found the mixing client entry module like that, we treat it as a
CJS client module and include all the bundle in client like before what
we have the client components import optimization.
Ideally we could warn users don't apply the client directive to these
kinda of barrel file, and only apply them to where we needed.
Fixes#64518
Closes NEXT-3119
* https://github.com/vercel/turbo/pull/7995 <!-- Benjamin Woodruff - fix(turbopack-node) postcss.config.js path resolution on Windows -->
(plus unrelated turborepo + CI changes)
This PR should not be cherrypicked into the 14-2-1 branch. Instead https://github.com/vercel/next.js/pull/64677 should be merged into that branch, as that PR contains only the one above Windows commit.
## Info
I did not create a GitHub issue, but this PR for fixing the issue. Hope
that's okay.
## The bug
We run a 'normal' custom server described here:
https://nextjs.org/docs/pages/building-your-application/configuring/custom-server
```ts
const next = require('next');
const dev = process.env.NODE_ENV !== 'production';
const port = 3000;
const app = next({ dev, port, quiet: !dev })
const handle = app.getRequestHandler()
// ...
```
The `quiet` settings is missed in some deeper Next.js internal api
calls. For that reason, the setting did not work at all. This works only
in production mode.
## Testing
I tried to implement a test in `/test/production/custom-server` but I
failed to get the `stderr` messages. When someone give me some guidance,
I will add a new test.
Here are some criteria:
- need: custom server with `quiet: true` setting
- need: a next.js page with thrown error. e.g. `export const
getServerSideProps = () => { throw new Error('failed') }`
- need: collect all `stderr` messages
I tested the fix in our project by editing the files in `node_modules`
-- it worked.
## Background
We upgrade our project from next `13.3.4` to `14.2.0` and saw this
regression. I can not tell in which version this bug was added. We run a
Next.js + 'custom server' + Docker setup. Because we have a lot of
traffic, we need to suppress the standard Next.js logging and using our
own logging.
<!-- 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 #
-->
## What?
- Changes webpack output target to `es6` (required for `async function`
output)
- Adds tests for top level await in server components and client
components (App Router)
- Converted the async-modules tests to `test/e2e`
- Has one skipped test that @gnoff is going to look into. This shouldn't
block merging this PR 👍
Adds additional tests for top level `await`.
Since [Next.js
13.4.5](https://github.com/vercel/next.js/releases/tag/v13.4.5) webpack
has top level await support enabled by default.
Similarly Turbopack supports top level await by default as well.
TLDR: You can remove `topLevelAwait: true` from the webpack
configuration.
In writing these tests I found that client components are missing some
kind of handling for top level await (async modules) so I've raised that
to @gnoff who is going to have a look.
<!-- 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 #
-->
Closes NEXT-3126
Fixes https://github.com/vercel/next.js/issues/43382
### Why
For app page rendering on edge, the `AsyncLocalStorage` (ALS) should be
bundled as same instance across layers. We're accessing the ALS in
`next/dynamic` modules during SSR for preloading CSS chunks. There's a
bug that we can't get the ALS store during SSR in edge, I digged into it
and found the root cause is:
We have both import paths:
`module (rsc layer) -> request ALS (shared layer)`
`module (ssr layer) -> request ALS (shared layer)`
We expect the ALS to be the same module since we're using the same layer
but found that they're treated as different modules due to applying
another loader transform on ssr layer. They're resulted in the same
`shared` layer, but with different resource queries. This PR excluded
that transform so now they're identical across layers.
### What
For webpack, we aligned the loaders applying to the async local storage,
so that they're resolved as the same module now.
For turbopack, we leverage module transition, sort of creating a new
`app-shared` layer for these modules, and apply the transition to all
async local storage instances therefore the instances of them are only
bundled once.
To make the turbopack chanegs work, we change how the async local
storage modules defined, separate the instance into a single file and
mark it as "next-shared" layer with import:
```
any module -> async local storage --- use transition, specify "next-shared" layer ---> async local storage instance
```
Closes NEXT-3085
### What
When rendering a parallel slot multiple times in a single layout, in
conjunction with using an error boundary, the following TypeError is
thrown:
> Cannot destructure property 'parallelRouterKey' of 'param' as it is
null
### Why
I'm not 100% sure of the reason, but I believe this is because of how
React attempts to dededupe (more specifically, "detriplficate") objects
that it sees getting passed across the RSC -> client component boundary
(and an error boundary is necessarily a client component). When React
sees the same object twice, it'll create a reference to that object and
then use that reference in future places where it sees the object. My
assumption is that there's a bug somewhere here, as the `LayoutRouter`
component for the subsequent duplicated parallel slots (after the first
one) have no props, hence the TypeError.
### How
Rather than passing the error component as a prop to `LayoutRouter`,
this puts it as part of the `CacheNodeSeedData` data structure. This is
more aligned with other properties anyway (such as `loading` and `rsc`
for each segment), and seems to work around this bug as the
`initialSeedData` prop is only passed from RSC->client once.
EDIT: Confirmed this is also fixed after syncing the latest React, due
to https://github.com/facebook/react/pull/28669Fixes#58485
Closes NEXT-2095
`initialCanonicalUrl` differs from the `canonicalUrl` that gets set on
the client, such as when there's a basePath set.
This hoists the `canonicalUrl` construction up so we can re-use it when
adding refetch markers to the tree.
This also renames `pathname` -> `path` since it also includes search
params. I added a test to confirm no extra erroneous fetches happened in
both cases.
Fixes#64584
Closes NEXT-3130
Since `AppRouterState` is promise-based (so we can `use` the values and
suspend in render), the state itself isn't stable between renders. Each
action corresponds with a new Promise object. When a link is hovered, a
prefetch action is dispatched, even if the prefetch never happens (for
example, if there's already a prefetch entry in the cache, and it
doesn't need to prefetch again). In other words, the prefetch action
will be dispatched but won't necessarily change the state.
This means that these no-op actions that don't actually change the state
values will trigger a re-render. Most of the context providers in
`AppRouter` are memoized with the exception of `LayoutRouter` context.
This PR memoizes those values so that consumers are only notified of
meaningful updates.
Fixes#63159
Closes NEXT-3127
Clarify best practices for implementing authentication in Next.js,
including what Next.js and React features to use and when. With the
minimum number of tools, we'll try to teach authentication from first
principles (simple password + email), then recommend Next.js-compatible
libraries, and further resources.
**Authentication:**
- [x] Forms and Server Actions
- [x] Server-side form validation and early returns
- [x] Form errors with `useFormStatus()`
- [x] Pending states with `useFormState()`
**Session Management:**
- [x] Stateless Sessions
- [x] Database Sessions
- [x] Setting cookies on the server
- [x] `cookies()`
- [x] `sever-only`
**Authorization:**
- [x] Optimistic vs. secure checks
- [x] Middleware for optimistic checks
- [x] Performance caveats - what not to do
- [x] DAL - centralizing data requests, verifying auth state close to
the data source
- [x] `redirect()`
- [x] DTO - returning the minimum data, preventing exposure on the
client
- [x] Recommendations for:
- [x] Server Components
- [x] Partial rendering and `layout` caveats
- [x] Server Actions
- [x] Route Handlers
DX Content: ["What is the right way to do
authentication?"](https://www.notion.so/vercel/00b2a5121a264939a5d4d10f76b36954?v=cac009672f9d411f900f41a0c3971702&p=2a80e8d450f54ea58da5cf8b42c15ac1&pm=s).
Test Example: https://github.com/vercel-labs/app-router-auth/pull/1
This is how I currently visualize it, this diagram is not meant for
users, but to help clarify our current understanding. What am I missing?
---------
Co-authored-by: Michael Novotny <manovotny@gmail.com>
Co-authored-by: Anthony Shew <anthonyshew@gmail.com>
Co-authored-by: Lee Robinson <me@leerob.io>
### What
Fixes a regression to enable wasm fallback for the know target triples
(that does not have native bindings). The condition was skewed when
introducing `useWasmBinary` flag.
Closes PACK-2969
### What?
Toolchain is updated as well.
Should improve compile times marginally, also added the new parallel
frontend.
Depends on https://github.com/vercel/turbo/pull/7409
Closes PACK-2526
### What
When middleware.js is present, the logging is duplicated. We should
filter out the 1st middleware request and only log the actual one going
through request handler / renderer
Closes NEXT-3125
When an action is marked as "discarded", we enqueue a refresh, since the
navigation event will be invoked immediately without waiting for the
action to finish. We refresh because it's possible that the discarded
action triggered some sort of mutation/revalidation, and we want the
router to still be able to respond to that new data.
However there's a bug in this logic -- it'll only enqueue the refresh
action if there were no other actions in the queue, ignoring the case
where something is still in the queue. This makes sure that the refresh
is handled after `runRemainingActions` finishes.
When adding a test for the server component case (which doesn't hit this
refresh branch), I noticed `LayoutRouter` caused React to suspend
indefinitely, because it got stuck in the `use(unresolvedThenable)`
case. We should only suspend indefinitely if we kicked off a the
`SERVER_PATCH` action, as otherwise it's possible nothing will ever
break out of that branch.
Fixes#64517
Closes NEXT-3124
## What
Determine if the client module is a CJS file and `default` export is
imported, then we include the whole module instead of using webpack
magic comments to only extract `default` export.
## Why
Unlike ESM, The `default` export of CJS module is not just `.default`
property, we need to include `__esModule` mark along with `default`
export to make it function properly with React client module proxy
Fixes#64518
Closes NEXT-3119
### What
This PR's goal is to improve the throughput performance of the Next.js
server when handling Pages Router routes.
Note that the results from this are very synthetic and do not represent
the real-life performance of an application. If we only wanted to handle
hello worlds, we could probably make this even faster but on production,
a slow fetch call to your DB is probably what's slowing you down.
I'll look into App Router next.
### Why?
I guess I got nerd-sniped into it 😃
### How?
A few optimizations:
- I looked deeply at the pipeline for rendering a Pages Router page. I
noticed a lot of intermediary streams being created here and there to
eventually be concatenated to a simple string. I think this is probably
left over code from when we wanted to support streaming there and so
there's some code that was shared with the App Router, which we
absolutely don't need I think. I refactored it to be slightly simpler
with just a few string concats here and there.
- misc: I removed some redundant Promises being created here and there
and added a small inline optimisation to eliminate `if (renderOpts.dev)`
code in production.
### Nummies
Test setup: hello world pages router app, next start + autocannon
- requests handled in 10s: 18k -> 33K, **~80% improvement**
- avg latency: 4.89ms -> 2.8ms, **~42% improvement**
- avg req/res: 1846.5 -> 2983.5, **~61% improvement**
Before
<img width="742" alt="image"
src="https://github.com/vercel/next.js/assets/11064311/658e7ade-eba7-4604-a7c9-619bd51a5ec8">
vs
after
<img width="880" alt="image"
src="https://github.com/vercel/next.js/assets/11064311/2f46cf69-b788-4db2-bf90-6f65dc7abd82">
<!-- 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 #
-->
Closes NEXT-3103
### What?
Add validation to ensure that the user is not using postcss when `experimental.useLightningcss` is enabled.
### Why?
It's confusing.
### How?
Closes PACK-2928
<!-- 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 #
-->
### What?
This enhances the typings in the `BaseServer`, `NextNodeServer`, and
`NextWebServer` to simplify types for request and responses across the
entire server. Rather than relying on manual environment checks only as
the source with error-prone type casts, this adds basic guards (albeit
naive) that assert the typings depending on the runtime environment
variables. This greatly enhances the typings used across the servers as
the servers no longer use the `as` keyword when working with these
request and response types.
This is a precursor to future planned work to further split the
different rendering runtimes to assist with code elimination and
framework organization.
### Why?
As a step to utilizing these more unified types, the `app-render.tsx`
(App Pages rendering pipeline) has been modified to instead accept the
abstract `BaseNextRequest` and `BaseNextResponse` types. This is a
precursor to future work to split the streaming behaviour based on the
runtime environment (ie, in Node.js, we can utilize the native streams
instead of web streams, which offer significant performance gains).
### How?
The server types were modified to be generic, allowing the three server
implementations to have their types flow safely between the different
methods. This enables us to only reference the `NodeNextRequest` within
the `NextNodeServer`, and the `WebNextRequest` within the
`NextWebServer` for example.
🎥 [Loom
Video](https://www.loom.com/share/76af2225cf0246d0b4f609ab3e35fff9?sid=c948a919-ac9e-4571-8a75-bd9d0a0776e2)
Closes NEXT-3102
