## What?
Fixes the `should update server components pages when env files is
changed (edge)` tests. In order for changes to the environment to apply
to edge-runtime routes we need to call `clearModuleContext`, currently
that only supports a single path being provided, but in Turobpack the
compilation is much more granular than webpack, in case of webpack we
loop through all items coming out of the compilation and invalidate them
regardless, which is not needed for Turbopack. Instead, when an
entrypoint (route) is recompiled it'll automatically only invalidate
that part. For `.env` changes that don't affect compilation, which is
what the test checks, this wouldn't be sufficient as there is no
compilation difference between changing those env vars. In the case that
you change `.env` / tsconfig/jsconfig we have to clear all module
contexts, which is what this PR implements.
<!-- 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-2337
## What?
Whenever `.env` related files or tsconfig/jsconfig changes there's a
call to `invalidate()`, as far as I found the only call to
`invalidate()` even, which wasn't implemented for Turbopack yet. For
`NEXT_PUBLIC_` changes normal Turbopack HMR will kick in already but
this test was checking env vars that do not affect the compiled output,
so Turbopack would not trigger a HMR as no inputs changed. Similarly
webpack doesn't either and it implements this call in a similar way.
For edge runtime there's a different bug where changes are not
propagated even when you refresh, so while this change does fix another
bug for edge runtime it doesn't solve that underlying issue where the
values don't update to begin with. I'll investigate that next.
<!-- 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?
`exportPathMap` didn't work when Turbopack was enabled because the
`serializeNextConfig` function mutates the original values, overriding
`exportPathMap`.
This PR changes the serialization to copy the object and mutate only the
copied object.
Also refactored the test that was checking `_next`, the better way to
test that is to have the page render something dynamically, which is
what is added in this PR.
<!-- 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-2225
### What?
This fixes 2 issues with app 404 pages.
1. The root layout in a group was previously ignored when hitting the
404 page.
2. The default app 404 page was missing the correct path for dev
`/not-found` so it would fall back to the pages 404 page.
Closes PACK-2241
Fixes#60688
This:
- Makes makes reporting hmr changes more accurate by emitting an
explicit start event and lowering the aggregation period for reporting
completed turbo tasks
- Parameterizes the aggregation period, allowing JS subscribers to
request different intervals, such as for the next-rs-api test
- Aligns path pattern with webpack by normalizing its layer names
- Fixes a bug in `drainAndGetNext` where the stream never could drain
past the first item
- Sends `client-hmr-latency` spans from Turbopack in both page and app
router pages
Closes PACK-2252
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
## What?
Updates snapshots for Turbopack tests. They're slightly different than
the webpack output. Generally better because column information is
preserved. The import trace is not available in Turbopack as it would
make the parent module a direct dependency of the module, meaning it
would have to recompile every time you can the parent module. We'll
figure out if it can be added in a different way at a later point.
<!-- 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-2101
### What?
Turbopack does not apply same transform for the react server components,
which makes missing lot of compilation error validation and custom
comments. PR refactors transform to be used in next-swc / turbopack
both, then apply it into turbopack.
There are still some of test cases are not passing, might need further
digging for the transform condition.
Closes PACK-2155
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
In fact, this is an issue that has been solved in #52033, but it seems
#52492 introduced it again.
> During development, for fonts created via next/font the file path is
already containing the hash so we can always have them cached. This
fixes the problem of fonts causing FOUC in HMR.
Fixes#50782
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What?
Catch-all routes are being matched to parallel routes which causes
issues like an interception route being handled by the wrong page
component, or a page component being associated with multiple pages
resulting in a "You cannot have two parallel pages that resolve to the
same path" build error.
### Why?
#58215 fixed a bug that caused catchall paths to not properly match when
used with parallel routes. In other words, a catchall slot wouldn't
render on a page that could match that catch all. Or a catchall page
wouldn't match a slot. At build time, a normalization step was
introduced to take application paths and attempt to perform this
matching behavior.
However in it's current form, this causes the errors mentioned above to
manifest. To better illustrate the problem, here are a few examples:
Given:
```
{
'/': [ '/page' ],
'/[...slug]': [ '/[...slug]/page' ],
'/items/[...ids]': [ '/items/[...ids]/page' ],
'/(.)items/[...ids]': [ '/@modal/(.)items/[...ids]/page' ]
}
```
The normalization logic would produce:
```
{
'/': [ '/page' ],
'/[...slug]': [ '/[...slug]/page' ],
'/items/[...ids]': [ '/items/[...ids]/page' ],
'/(.)items/[...ids]': [ '/@modal/(.)items/[...ids]/page', '/[...slug]/page' ]
}
```
The interception route will now be improperly handled by
`[...slug]/page` rather than the interception handler.
Another example, which rather than incorrectly handling a match, will
produce a build error:
Given:
```
{
'/': [ '/(group-b)/page' ],
'/[...catcher]': [ '/(group-a)/@parallel/[...catcher]/page' ]
}
```
The normalization logic would produce:
```
{
'/': [ '/(group-b)/page', '/(group-a)/@parallel/[...catcher]/page' ],
'/[...catcher]': [ '/(group-a)/@parallel/[...catcher]/page' ]
}
```
The parallel catch-all slot is now part of `/`. This means when building
the loader tree, two `children` parallel segments (aka page components)
will be found when hitting `/`, which is an error.
The error that was added here was originally intended to help catch
scenarios like:
`/app/(group-a)/page` and `/app/(group-b)/page`. However it also throws
for parallel slots, which isn't necessarily an error (especially since
the normalization logic will push potential matches).
### How?
There are two small fixes in this PR, the rest are an abundance of e2e
tests to help prevent regressions.
- When normalizing catch-all routes, we will not attempt to push any
page entrypoints for interception routes. These should already have all
the information they need in `appPaths`.
- Before throwing the error about duplicate page segments in
`next-app-loader`, we check to see if it's because we already matched a
page component but we also detected a parallel slot that would have
matched the page slot. In this case, we don't error, since the app can
recover from this.
- Loading a client reference manifest shouldn't throw a cryptic require
error. `loadClientReferenceManifest` is already potentially returning
undefined, so this case should already be handled gracefully
Separately, we'll need to follow-up on the Turbopack side to:
- Make sure the duplicate matching matches the Webpack implementation (I
believe Webpack is sorting, but Turbopack isn't)
- Implement #58215 in Turbopack. Once this is done, we should expect the
tests added in this PR to start failing.
Fixes#58272Fixes#58660Fixes#58312Fixes#59782Fixes#59784
Closes NEXT-1809
## What?
Fixes a bug where `useOptimistic` wouldn't trigger a compiler error when
imported in Server Components.
Adds tests for the following `import { x } from 'react'` in Server
Components, where `x` is the value:
- Component
- createContext
- createFactory
- PureComponent
- useDeferredValue
- useEffect
- useImperativeHandle
- useInsertionEffect
- useLayoutEffect
- useReducer
- useRef
- useState
- useSyncExternalStore
- useTransition
- useOptimistic
These show a particular error explaining how to add `"use client"`:
<!-- Thanks for opening a PR! Your contribution is much appreciated.i:
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 #
-->
I want to give this field a name that's bit less generic and
distinguishes it from `lazyData` (because that one has a different type
and is a special case we want to eventually remove).
I'm also about to add an optional `prefetchRsc` field that represents a
prefetched version of the same value. The common suffix is meant to
communicate how they are related.
Doing this rename in its own PR because it's a pure find-and-replace,
whereas the later steps are not.
Closes NEXT-1846
### What?
switch turbopack to use a single client components entrypoint for all
client components on a page for development. This aligns it with the
webpack behavior.
### Why?
compiling a separate entrypoint for every client component is pretty
expensive in regards of compilation, chunking, code generation, file
writing and number of requests.
### Turbopack Changes
* https://github.com/vercel/turbo/pull/6713 <!-- Tobias Koppers - use
real emojis -->
* https://github.com/vercel/turbo/pull/6728 <!-- Tobias Koppers - fix
order of reverse topologic iteration -->
Closes PACK-2115
