### What
Fix bad detection of dynamic route of sitemap metadata route, the swc
AST check should process when the text are detected. But prevuious if
there's text with `generateSitemap` such as comment but not the actual
export it will fail.
### How
Add both checks on metadata loader side and detection helper side
* Only call `generateSitemaps` helper when the export existed
* Fix the helper detection logic (major part of this PR)
Fixes#59698Closes#60344
Closes NEXT-2007
### What?
Our
[docs](https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#convention)
point out that `app/page.js` is equivalent to `app/@children/page.js`,
however in practice this is not the case, and causes type errors when
using `@children` slots as well as incorrect behavior when matching
catch-all routes.
### Why?
- When typechecking, `@children` slots would be added to the typeguard
file for the associated layout, resulting in duplicate identifiers for
the `children` prop
- When determining where to insert catchall slots, the `hasMatchedSlots`
check wasn't considering that the `@children` slot corresponds with the
page component, so matching another page would clobber the previous one.
### How?
- Filters out the `@children` slot when collecting slots for
typechecking
- Filters out the `@children` slot when running the `hasMatchedSlots`
function in the catch-all normalizer
Closes NEXT-1984
### Fixing a bug
I'm sorry, I have no idea how I managed to delete this, as I just copied
the code.
However, I had to figure out why the tests passed. When I test the
running application locally, it works as expected.
So, when a route is first used in a running production application in a
test, `ctx.fetchCache` is `undefined`. Therefore, the error rule does
not trigger on the first request, and the cache is successfully written.
This may result in artifacts in FetchCache in Vercel and possibly in
other parts of the code.
```ts
if (
ctx.fetchCache && // <- Undefined on first request
// we don't show this error/warning when a custom cache handler is being used
// as it might not have this limit
!this.hasCustomCacheHandler &&
JSON.stringify(data).length > 2 * 1024 * 1024
) {
if (this.dev) {
throw new Error(`fetch for over 2MB of data can not be cached`)
}
return
}
```
I'm 95% sure that this is a bug and it shouldn't work like this. I'll
look into this later and if there is an error, I'll put it into a task
and try to figure it out later.
Unfortunately, the
[test](7e028fb6d8/test/e2e/app-dir/app-static/app-static.test.ts (L3080))
from [previous PR](https://github.com/vercel/next.js/pull/59976) is not
working yet, although it is correct from my point of view. I think it
should be kept and the problem above should be fixed.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
When relying on a `default` route as a fallback, greedier catch-all
segments in the application hierarchy would take precedence, causing
unexpected errors/matching behavior.
### Why?
When performing parallel route catch-all normalization, we push
potential catch-all matches to paths without considering that a path
might instead be matched by a `default` page. Because of this, the
catch-all take precedence and the app will not try and load the default.
For example, given this structure:
```
{
"/": ["/page"],
"/[[...catchAll]]": ["/[[...catchAll]]/page"],
"/nested/[foo]/[bar]": ["/nested/[foo]/[bar]/@slot/page"],
"/nested/[foo]/[bar]/[baz]": ["/nested/[foo]/[bar]/@slot/[baz]/page"],
}
```
(Where there's a `/nested/[foo]/[bar]/default.tsx`)
The route normalization logic would produce:
```
{
"/": ["/page"],
"/[[...catchAll]]": ["/[[...catchAll]]/page"],
"/nested/[foo]/[bar]": [
"/nested/[foo]/[bar]/@slot/page",
"/[[...catchAll]]/page",
],
"/nested/[foo]/[bar]/[baz]": [
"/nested/[foo]/[bar]/@slot/[baz]/page",
"/[[...catchAll]]/page",
],
}
```
This means that when building the `LoaderTree`, it won't ever try to
find the default for that segment. **This solution operates under the
assumption that if you defined a `default` at a particular layout
segment, you intend for that to render in place of a greedier
catch-all.** (Let me know if this is an incorrect assumption)
### How?
We can't safely normalize catch-all parallel routes without having
context about where the `default` segments are, so this updates
`appPaths` to be inclusive of default segments and then filters them
when doing anything relating to build/export to maintain existing
behavior. We use this information to check if an existing default exists
at the same segment level that we'd push the catch-all to. If one
exists, we don't push the catch-all. Otherwise we proceed as normal.
Closes NEXT-1987
### 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>
This fixes a case in the PPR navigations implementation where page data
was not being applied.
During a navigation, we compare the route trees of the old and new pages
to determine which layouts are shared. If the segment keys of two
layouts are the same, they are reused.
However, the server doesn't bother to assign segment keys to the leaf
segments (which we refer to as "page" segments) because they are never
part of a shared layout. It assigns all of them a special constant
(`__PAGE__`).
In the PPR implementation, I overlooked this and compared the segment
keys of all segments, including pages, not just shared layouts. So if
the only thing that changed during a navigation was the page data, and
not any parent layout, the client would fail to apply the navigation.
The fix is to add a special case for page segments before comparing
nested layouts. I also moved an existing special case for default pages,
since those are also leaf segments and are conceptually similar.
### Fixing a bug
### What?
Disable 2MB limit for custom incrementalCacheHandler
### Why?
The limit is necessary because `FetchCache` has a 2MB limit, but it
seems there was a miscommunication regarding the key coincidence, where
`fetchCache` is a flag indicating that the method is called from fetch,
rather than indicating that the `FetchCache` Provider is currently being
used.
We do not use Vercel, and as I understand it, we do not have the
opportunity to use this functionality.
In any case, it is more important for us to increase the limits, and in
some cases, using a file storage is even preferable.
### How?
I have created a flag that determines whether the use of `FetchCache` is
possible at least in theory - if no custom provider is passed, and
additionally configured it so that it is not an implementation of
`FetchCache` as a protection against special individuals (*like me :)*).
If everything is fine, I will write proper tests.
Also, I would like to recommend making `FileSystemCache` public (_i.e.
support it as public functionality_) so that it can be imported and
extended or simply used to fix only it.
Fixes#48324 (partially)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Fixes#57038
# What?
Added an error message when `generateStaticParams` returns an empty
array with `output:export`.
# Why?
To provide developers with clear feedback when `generateStaticParams` is
not used correctly.
# How?
Modified the condition checks around the use of `generateStaticParams`
to include a check for an empty array and added a corresponding error
message.
---------
Co-authored-by: Steven <steven@ceriously.com>
### What & Why?
When visiting a route that attempts to render a slot with no page & no default, the fallback behavior is to trigger a 404. However this can lead to a confusing development experience for complex parallel routing cases as you might not realize a default is missing, or which slot is causing the error.
Previous issues where this caused confusion:
- https://github.com/vercel/next.js/issues/51805
- https://github.com/vercel/next.js/issues/49569
### How?
This is a dev-only modification to track parallel slots that are using the default fallback (aka missing). When the `NotFoundBoundary` is triggered in development mode, this will log a warning about why it 404ed, along with a list of slot(s) that were determined to be missing.
### Future
We should eventually lift this into some sort of dev-only UI to help catch it when not monitoring the browser console (similar to the error overlay). However, this will require some design thought and isn't necessary for the first iteration.
Closes NEXT-1798
## What?
Currently there is a bug in Server Actions when you `fetch` as it uses
the same defaults (caching when not specified) as rendering, this causes
some issues as you want to read your writes in Server Actions.
This change adds the `no-store` default for Server Actions, you can
still override it by specifying `cache: 'force-cache'` for example, but
it defaults to `cache: 'no-store'`.
Fixes NEXT-1926
<!-- 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 #
-->
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
get value, issues and diagnostics in a single strongly consistent call
### Why?
Before issues and diagnostics where not received strongly consistent,
which could result in stale data.
### How?
Closes PACK-2194
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>
Had some spare time and was trying to get more familiar with the
codebase.
Added a few types to `create-next-app` here. Nothing fancy!
---------
Co-authored-by: Steven <steven@ceriously.com>
This commit updates some of the code organization in app-render in
preparation for supporting dynamic RSC repsonses on top of static SSR
responses for PPR. The main change to notice is the separation of
creating the server component renderer which initiates the RSC render
and executes in the RSC layer with the consuming component which lives
in the SSR layer. By organizing the code this way we can later only call
the server render in certain cases, omitting the SSR render entirely.
This is different than just using the generaetFlight pathway because
that pathway serves client navs and does not actually render the same
output that the intial render does.
Closes NEXT-1889
Previously in #58967 we set all the module type as `'es6'` to let swc
parse app router code as ESM and output as ESM due to the incorrect
detection of CJS module by auto-cjs plugin, but this is not accurate
when the external library bundle is CJS. The problem is when swc
compiling modern syntax for example private properties in CJS bundle but
emitted the swc helpers with ESM imports.
We had a auto-cjs swc plugin to determine if the file is using CJS or
not, @kdy1 fixed the bug of it so now we can use the default module
type, and let the plugin to determine its module type, to make sure
we're emitting the right helpers.
Closes NEXT-1942
Based on #60118
Use dynamic import instead of require to load the incremental cache
handled, so when using ESM it will still work.
Updated the tests and merged them into new test suite, include 3 cases
of custom cache definition:
- CJS with `module.exports`
- CJS with `exports.default` with ESM mark
- ESM with `export default`
Closes NEXT-1924
Fixes#58509
The start line of build logging `Creating an optimized production build
...` was logged by spinner, and when all build is finished we stop that
spinner. But the problem is all the logs from a page such as warnings
will be also leaded by it since they interrupted the spinner.
We changed the spinner to a one-line log now that will make the warning
logs more clear and let the page-level build logs print without messed
with app-level build logs.
#### After
```
▲ Next.js 14.0.5-canary.34
Creating an optimized production build ...
⚠ Next.js can't recognize the exported `runtime` field in "/Users/huozhi/workspace/next.js/test/e2e/app-dir/app-edge/app/expo
rt/inherit/page.tsx" as it was not assigned to a string literal.
The default runtime will be used instead.
⚠ Next.js can't recognize the exported `preferredRegion` field in "/Users/huozhi/workspace/next.js/test/e2e/app-dir/app-edge/
app/export/inherit/page.tsx" as it was not assigned to a string literal or an array of string literals.
The default runtime will be used instead.
```
#### Before
```
▲ Next.js 14.0.5-canary.34
Creating an optimized production build ... ⚠ Next.js can't recognize the exported `runtime` field in "/Users/huozhi/worksp
ace/next.js/test/e2e/app-dir/app-edge/app/export/inherit/page.tsx" as it was not assigned to a string literal.
The default runtime will be used instead.
⚠ Next.js can't recognize the exported `preferredRegion` field in "/Users/huozhi/workspace/next.js/test/e2e/app-dir/app-edge/
app/export/inherit/page.tsx" as it was not assigned to a string literal or an array of string literals.
The default runtime will be used instead.
Creating an optimized production build ... ⚠ Next.js can't recognize the exported `runtime` field in "/Users/huozhi/worksp
ace/next.js/test/e2e/app-dir/app-edge/app/export/inherit/page.tsx" as it was not assigned to a string literal.
The default runtime will be used instead.
⚠ Next.js can't recognize the exported `preferredRegion` field in "/Users/huozhi/workspace/next.js/test/e2e/app-dir/app-edge/
app/export/inherit/page.tsx" as it was not assigned to a string literal or an array of string literals.
The default runtime will be used instead.
```
Closes NEXT-1939
Closes NEXT-1947
### What?
Next.js throws a hard `SEGMENT MISMATCH` error when the reducers were
unable to apply the a patch to the router tree from the server response.
### How?
Rather than crashing the router, this will treat segment mismatches as a
MPA navigation, to restore the client router into a working state.
### Test Plan
If there are specific scenarios where Next.js throws this error, it
should most likely be fixed in Next and not in user-land. Since it's not
currently obvious what scenarios will trigger this error, this PR serves
to recover from a mismatch more gracefully and provides some debug
information rather than crashing the application. As such, there's no
easy way to create an E2E test for this and I've instead opted for a
simple unit test.
Closes NEXT-1878
[slack
x-ref](https://vercel.slack.com/archives/C017QMYC5FB/p1704214439768469)
[slack
x-ref](https://vercel.slack.com/archives/C03KAR5DCKC/p1702565978694519)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
