The function we use to generate a string with named parameters to pass
into `path-to-regexp` currently doesn't properly handle non-word
characters (namely, for the purposes of this bugfix, hyphens). As a
result, `pathToRegexp` will convert something like `/foo/:bar-baz` into
`/^\/foo(?:\/([^\/#\?]+?))-baz[\/#\?]?$/i`, effectively only treating
the `:foo` as part of the regex capture group and leaving a dangling
-baz.
This means using an interception route within a dynamic segment (such as
`/foo/[bar-baz]`) would not properly trigger the route interception
Fixes#64766
### What?
I submitted PR #64499 , it got merged, but it contains a mistake.
I'm terribly sorry about this!
By removing the traceparent from the cachekey, we mistakenly removed the
header from the original object.
Causing the actual request to be executed without the traceparent
header.
### Why?
Creating a cachekey should not alter the original object.
### How?
Flip the arguments for Object.assign
---------
Co-authored-by: Jeffrey <jeffrey@jeffreyzutt.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Why?
This typo was resulting in this error in deploy.
```
Failed to get from fetch-cache TypeError: s.tags.include is not a function
```
Closes NEXT-3168
<!-- 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 ensures that the body limit option is enforced on all request
bodies sent to the Node.js runtime, not just the multipart field size
limits.
### Why?
The documentation states that this should limit the body size,
previously it only limited the field size.
### How?
This uses a `Transform` stream from Node.js. [Based on my
benchmarks](https://gist.github.com/wyattjoh/c470d98095da2f95f5920396aba2a206)
using the transform stream added next to no overhead, yet it did
simplify the implementation quite a bit. Assuming this is due to the
already performant stream support within Node.js.
Closes NEXT-3151
The `params` example in the docs for `default.js` have the slot/params
in the wrong order, giving the impression that you can deeply nest
`default` slots.
This clarifies that the params received by a slot are based on the
dynamic params leading up to the segment containing the slot.
Fixes#64708
Closes NEXT-3160
This ensures we only track fetch metrics in development mode as that's
the only time we report them currently, this also adds an upper limit on
how many metrics we store per-request as previously this was unbounded,
on top of that this ensures we don't keep tracking fetch metrics after
the request has ended as we only report on request end, and finally this
adds a clean-up to the reference we attach to the request object
containing the fetch metrics once we have used them.
Closes: https://github.com/vercel/next.js/issues/64212
Closes NEXT-3159
When a server action triggers a redirect, we're incorrectly applying a
refresh marker to the segment they were on, rather than the segment they
were being redirected to. As a result, when revalidation occurs (via
`revalidateX` or `router.refresh()`), the top-level segment would be
replaced with data for an incorrect segment.
For example, if triggering a redirect action from `/redirect` to `/`,
the router state tree would save a reference to `/redirect`. The next
time a refresh or revalidate happens, it'd refresh the segment data for
`/redirect` instead of `/`.
Fixes#64728
Closes NEXT-3156
## What?
In the past folks on the team have reported that anytime the SWC /
Turbopack binary changes they had to suddenly run `pnpm build-native` in
`packages/next-swc`, even though they didn't build from source before.
While investigating optimizing packing for tests I found that it's
copying the native binary into the original repository not the temporary
repository, which then keeps the file there, even after the tests
finish. This fixes the path to use the tmp repository instead.
<!-- 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-3157
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 #
-->
