This fixes an issue when playwright spawns a new page from the same
context (a popup window) where requests were not being proxied correctly
Co-authored-by: Shu Ding <g@shud.in>
`react-dom` also contains a `react-server` condition that need to be
picked up in RSC bundle layer, like what we did for react. This will
ensures the server runtime smaller and you don't accidentally use the
client apis on server side.
Closes NEXT-2898
---------
Co-authored-by: Janka Uryga <lolzatu2@gmail.com>
### What
* Remove the erroring of force-dynamic is not able to use during static
generation
* Export the route segments properly in sitemap conventions
### Why
We discovered this error is showing up when users are using
force-dynamic with generating multi sitemaps.
When you have a dynamic `route /[id]/route.js` , and you have
generateSitemaps defined which is actually using `generateSitemaps`
under the hood , then you set the route to dynamic with `export dynamic
= 'force-dynamic'`.
We should keep the route still as dynamic. `generateStaticParams` is
only for generating the paths, which is static in build time. And the
`force-dynamic` is going to be applied to each generated path.
Closes NEXT-2881
Followup on https://github.com/vercel/next.js/pull/52520 and
https://github.com/vercel/next.js/pull/54014
**Enhancements**
- Removes `--experimental-test-proxy` CLI argument from `next dev` and
`next start`
- Adds a new experimental config option `testProxy?: boolean`
- Instead of throwing an error, return the `originalFetch` response if
the current request context does not contain the `Next-Test-*` HTTP
headers
**Why?**
These changes allow us to write mixed Integration + E2E tests within the
same Playwright process.
```ts
// some-page.spec.ts
test.describe('/some-page', () => {
test('some integration test', async ({ page, next }) => {
// by using the `next` fixture, playwright will send the `Next-Test-*` HTTP headers for
// every request in this test's context.
next.onFetch(...);
await page.goto(...);
await expect(...).toBe('some-mocked-value');
});
test('some e2e test', async ({ page }) => {
// by NOT using the `next` fixture, playwright does not send the `Next-Test-*` HTTP headers
await page.goto(...);
await expect(...).toBe('some-real-value');
});
})
```
Now I can run `next dev` and locally develop my App Router pages AND run
my Playwright tests against instead of having to,
- run `next dev` to locally develop my change
- ctrl+c to kill server
- run `next dev --experimental-test-proxy` to locally run my integration
tests
---------
Co-authored-by: Sam Ko <sam@vercel.com>
This PR upgrades `enhanced-resolve` to `5.16.0` so as to benefit from
https://github.com/webpack/enhanced-resolve/pull/301, recently merged.
Without this diff, importing dependencies from files from external PnP
projects would fail. It's a little niche, but I'm working on a
documentation website that leverages that to allow deploying multiple
websites from the same template.
Co-authored-by: Sam Ko <sam@vercel.com>
Co-authored-by: Steven <steven@ceriously.com>
This ensures that the instrumentation hook for Node.js will run
immediately during `next start` instead of waiting for the first request
like does it `next dev`.
However, if there is a separate instrumentation hook for Edge, that will
still be lazy evaluated and wait until the first request.
Fixes#59999
Fixes NEXT-2738
This causes Turbopack to fail and communicate when a file with an
unhandled or unregistered extension is built.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/development/basic/hmr.test.ts`
Closes PACK-2803
### What
Actions that revalidate the router state by kicking off a refetch (such
as `router.refresh()` or dev fast refresh) would incorrectly trigger an
interception route if one matched the current URL, or in the case of
already being on an intercepted route, would trigger the full detail
page instead.
### Why
Interception rewrites use the `nextUrl` header to determine if the
requested path should be rewritten to a different path. We currently
forward that header indiscriminately, which means that if you were on a
non-intercepted route and called `router.refresh()`, the UI would change
to the intercepted content instead (since it would treat it the same as
a soft-navigation).
### How
This updates various reducers to only forward the `nextUrl` header if
there's an interception route present in the tree. If there is, we want
to refresh its data, rather than the data for the underlying page. The
reverse is also true: if we were on the "full" page, and triggered a
`router.refresh()`, we won't forward `nextUrl` meaning it won't fetch
the interception data.
In order to determine if an interception route is present in the tree, I
had to add a new segment type for dynamic interception routes, as by the
time they reach the client they are stripped of their interception
marker.
**Note: There are a series of bugs related to `router.refresh` with
parallel/interception routes, such as the previous page/slot content
disappearing when triggering a refresh. This does not address all of
those cases, but I'm working through them!**
Fixes#60844Fixes#62470
Closes NEXT-2737
This PR is a follow up to #63427 and simplifies the
`createRootLayoutValidatorStream` function to check each chunk
individually instead of combining all of them into one. This should
improve performance
Closes NEXT-2868
Currently when we generate payloads in app router, the order of RSC
chunks aren't deterministic even if the content stays the same. This
means that any caches that rely on etags for detecting changes in
content aren't able to reliably cache/and avoid invalidating properly.
To avoid this we can manually sort the content before generating the
etag. Eventually this can be fixed upstream in react although that is a
bigger lift so we are doing this for now to alleviate the issue.
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1709937748240119?thread_ts=1709856182.174879&cid=C042LHPJ1NX)
Closes NEXT-2825
In #61573, I updated the navigation reducer to request a new prefetch
entry if it's stale. But this has the unintended consequence of making
instant loading states effectively useless after 30s (when the prefetch
would have expired). Blocking navigation and then rendering the loading
state isn't ideal - if we have some loading data in a cache node, we
should re-use it.
Now that #62346 stores loading data in the `CacheNode`, we can copy over
`loading` during a navigation.
This PR repurposes `fillCacheWithDataProperty` which wasn't being used
anywhere, to instead be a utility we can use to programmatically trigger
a lazy fetch on a particular segment path by nulling out it's data while
copying over other properties. We could have used the existing util
as-is, but ideally we only have a single spot where lazy fetching can
happen, which currently is in `LayoutRouter`.
When a stale prefetch entry is detected, rather than applying the data
to the tree, this PR will copy over the `loading` nodes and will
"delete" the data so it can be refetched.
<!-- 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-2806
This PR is strictly a performance improvement. It should not change
implementation behavior in anyway.
This PR replaces `decoder.decode()` operations by operating with the
encoded `Uint8Array` instances directly. I added some utility functions
to make things a bit easier to understand.
Ideally, this change also maintains a fair amount of code readability.
Will measure estimate performance improvement shortly.
Closes NEXT-2848
## What?
Got a report from @juliusmarminge that running examples in the
[uploadthing monorepo](https://github.com/pingdotgg/uploadthing) would
result in resolving errors with Turbopack.
Turns out the monorepo root couldn't be resolved and the reason for that
is that they are using `bun install` as the package manager, which we
didn't account for in the `findRootLockFile` logic. This PR adds
`bun.lockb` to the existing list that already check npm/pnpm/yarn.
<!-- 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-2766
script tag cannot be placed under html directly, users reported a case
in #51242 that having `<Script>` under html will cause hydration error,
this will display the React hydration error related warning of bad usage
for it.
You will see this warning in dev overlay instead of displaying nothing
```
In HTML, <script> cannot be a child of <html>.
This will cause a hydration error.
```
Added two other react warnings detection patterns as well
* `Warning: In HTML, text nodes cannot be a child of <%s>.\nThis will
cause a hydration error.',`
* `Warning: In HTML, whitespace text nodes cann...`
But tested they're not generating hydration errors, only warnings in
console, so we don't need to have tests for them.
Closes NEXT-2835
Two small changes. There's no need to check `payload === undefined` as
it will always be a string. At the other place we can reuse the global
`textEncoder` instance.
Closes NEXT-2830
### What?
This fixes more CSS ordering issues with production and webpack dev.
* CSS Modules must not be side effect free as side effect free modules
are per definition order independent which is not true for CSS
* fix order of iterating module references
* disable splitChunks for CSS
* special chunking for CSS with loose and strict mode
* more test cases
Closes PACK-2709
Currently, we always fallback to https as the protocol for redirection
requests inside Server Actions even for the local server host, which can
be `0.0.0.0` and result in SSL errors.
Closes#63114, partially resolves
https://github.com/vercel/next.js/issues/62903#issuecomment-1984179180.
Closes NEXT-2829
### What?
* Allow to apply webpack loaders depending on "conditions".
* add a few next specific conditions depending on context type
### Why?
Some loaders need different behavior depending on context
### How?
Closes PACK-2748
Fixes#34448
Before this PR, next/lib/find-config fails to load \*.config.mjs files
and \*.config.js files when `"type": "module"` is set in package.json.
It expects CommonJS files although the \*.config.{js|mjs} files are
written in JS modules format (i.e. using `import` and `export`).
This PR fixes it so that it can load configs written in JS modules
format.
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Turbopack HMR: Log when more errors cause full page reload
Depends on vercel/turbo#7715
This adds messaging when HMR updates fail because:
- An HMR update could not be applied, such as updating an anonymous
function component
- An update follows a server-rendered error
Test Plan: See now passing tests in the manifest
Closes PACK-2728