### What?
Adds a warning when `useSearchParams` deopts the entire page to
client-side rendering.
When there is no Suspense boundary the entire page becomes client-side
rendered, you can learn more about that here:
https://beta.nextjs.org/docs/api-reference/use-search-params#static-rendering
### Why?
We've seen a few cases where people accidentally deopt the entire page
by calling `useSearchParams` as there was no indicator that this deopt
happened.
### How?
When the full page deopt happens the error is caught by the rendering
code so we warn there.
Closes NEXT-589
<!-- 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 or adding/fixing 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 #
-->
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 or adding/fixing 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?
This PR adds next-types-plugin's support for Route Handlers.
### Why?
Since `route.js` is somewhat like `page.js` and `layout.js`, I find it to be necessary that we also enable TS checks for these files as well.
### How?
Just changing the `createTypeGuardFile` function a bit and adding a few new tests, yeah.
More cleanup flowing out of the removal of the `target` option.
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Ensures `useParams` can be called in `pages`. In that case it returns
`null` similar to other navigation hooks that can't be backported.
### Why?
When migrating you can have components that are rendered in both `app`
and `pages`.
### How?
Uses the same approach as `useSearchParams` and `usePathname`. Type is
added to `navigation.d.ts` that overrides `next/navigation` only when
`pages` exist, that way applications built entirely on `app` don't get
the `null` type.
<!-- 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 or adding/fixing 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: JJ Kasper <jj@jjsweb.site>
### What?
Removes `head.js` file convention in favor of built-in SEO support through `metadata`: https://beta.nextjs.org/docs/guides/seo
### Why?
The `head.js` convention was superseded by the built-in SEO support which is designed specifically for Server Components.
### How?
Removed the `head.js` handling in app-loader and the tests for it.
fix NEXT-812 ([link](https://linear.app/vercel/issue/NEXT-812))
### What?
This PR is another part of making parallel routes viable!
- enables some of the tests, partially only in dev (build fails because
the intersection routes are not implemented)
- introduces a new type of special file: a `default` file that can be
added to any segment, next to `page` etc, that will act as the
default/placeholder when a layout does not match
- this also fixes bugs when navigating within parallel routes
### Why?
### How?
<!-- 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 or adding/fixing 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 #
-->
fix NEXT-748 ([link](https://linear.app/vercel/issue/NEXT-748))
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Fixes issue with app directory that caused problems with `i18n` was
enabled. Previously, when you accessed a URL like `/blog/first-issue`,
you would expect it to hit the app route at `/app/blog/[slug]/page.tsx`,
but instead it internally attempted to access
`/app/{defaultLocale}/blog/[slug]/page.tsx` (where `{defaultLocale}` is
set in `next.config.js` via `i18n.defaultLocale`). This is because while
the path did not assume the locale, the domain/default was enough to
suggest it, causing the mismatch.
This adds a new internal parameter for tracking this _default_
assignment so it can be handled by the matcher correctly.
Fixes#46814Fixes#46841
fix NEXT-777 ([link](https://linear.app/vercel/issue/NEXT-777))
fix NEXT-834 ([link](https://linear.app/vercel/issue/NEXT-834))
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Revert some code in #47379 and finalize HOC support. We should require
the HOC to return a "use server" function, so there's no need to compile
the function call specially now.
To make that wrapping logic work, we need to allow passing a server
reference to another server reference. This usually happens in the
function closure in the HOC case, but ideally it's also allowed to
directly pass it as an argument. This requires adding React server DOM's
`encodeReply` and `decodeReply` and other corresponding changes,
including adding `busboy` (can probably be vendored?) as we need to
parse the multipart body now.
fix NEXT-808 ([link](https://linear.app/vercel/issue/NEXT-808))
([link](https://linear.app/vercel/issue/NEXT-808))
### What?
In `app` all directories starting with `_` are now considered private
and won't be routed.
E.g. `app/_components/page.js` -> does not route
If you want to have a route starting with an underscore like
`/_settings` you can use `%5F` which is the url encode version of `_`:
`app/%5Fsettings/page.js`-> does route
### Why?
Ensures that you can create directories that will never conflict with
Next.js internal naming. E.g. when additional conventions are added for
file names.
### How?
It's a bit more involved than you might expected:
- build
- While resolving entries by traversing `app` parts with `_` are ignored
- While normalizing entires `%5F` is replaced with `_`
- I've changed one case that was relying on the entry name for resolving
to use the full path to the file instead.
- dev
- Ignored paths with underscore from being generated as part of the
initial scan of the filesystem
- Updated development and production the route matcher to replace `%5F`
with `_` so that it matches the right path.
fix NEXT-798 ([link](https://linear.app/vercel/issue/NEXT-798))
([link](https://linear.app/vercel/issue/NEXT-798))
<!--
## For Contributors
### Improving Documentation or adding/fixing 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: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
introduce a new hook `useReportWebVitals` that would register a function to handle web-vitals metrics.
### Why?
next.js users who use [Axiom](https://axiom.co) has been [asking](https://github.com/axiomhq/next-axiom/issues/109) for this feature for nextjs 13, as it was working for nextjs 12.
This ensures we only honor cache entries from the in memory cache for up
to 2 seconds so that revalidates can correctly propagate and also
increases max fetch cache entry size to 2 MB. The `fetchCache` export is
also being detected in this PR but not yet honored which will be done in
a follow-up.
As discussed this adds a publish workflow that can be triggered for
canary or stable releases which ensures we are publishing from a
consistent environment and local config doesn't affect a release.
These tests are copy/pasta from existing tests
- from `test/integration/next-image-new/default`
- to `test/integration/next-image-new/app-dir`
There were a handful of changes need to migrate the fixture from `pages` to `app` but the test assertions are the same.
There is one test assertion for preload that wasn't working so its marked as "skip" until it can be fixed in a future PR.
fix NEXT-849 ([link](https://linear.app/vercel/issue/NEXT-849))
* Add `contenthash` as query (`?<hash>`) for dynamic image and icon
routes as well.
* Merge the metadata image info extration into 1 single loader, dynamic
and static image route will all pass through
`next-metadata-image-loader` to extract the image info such as size,
content type, etc.
* Applying same cache header from `@vercel/og`, for development we use
"no cache" header, for production, we use "long cache" header
Closes NEXT-882
This avoids the case that one can accidentally return a `Response` object in the Node.js runtime in `pages/api/`, that causes the request to hang forever.