Turning this flag off would have already caused client-side invariants
because we deleted all the old codepaths. This fully removes the
remaining plumbing that supported the flag.
### What?
This PR refactors the Google Tag Manager implementation on
`@next/third-parties`, it rewrites the implementation of the script url,
params and types to allow `gtmId` to be optional when a script URL is
provided.
### Why?
Google released [Google Tag Gateway for
Advertisers](https://developers.google.com/tag-platform/tag-manager/gateway/setup-guide?setup=manual)
which allows first-party tracking on GTM. When running GTM using the
current implementation, it doesn't work because the `?id=` is hardcoded
into the implementation as it doesn't consider the possibility of tag
gateway or any other setup where the ID is already part of the url.
### How?
- Expanded the types
- Refactored the initialisation of the script URL
- Updated documentation relevant to GTM
Closes#81009
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Looks like `_next/data` is always matched to prevent accidental security
issues with protecting the page but not the data route. Documenting
using this PR
There are a lot of things in here that aren't quite fully fleshed out
yet (eg runtime prefetching) as well as some inaccuracies (eg `use
cache: private` is not required for runtime prefetching, it's just
another thing that _can_ be runtime prefetched).
This trims the doc down until we can focus on proper guidance.
<!-- 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
### 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>
The second “used” seems unnecessary.
<!-- 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
### 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: Joseph <joseph.chamochumbi@vercel.com>
Closes https://github.com/vercel/next.js/issues/84307
It seems that the `regexp` prop is not currently supported in the
matcher object
(./packages/next/src/build/segment-config/middleware/middleware-config.ts
→ MiddlewareMatcherInputSchema). Adjusting docs accordingly.
---------
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
Bringing back some info lost when next lint was removed, and accounting
for `isolatedDevBuild` in v16
---------
Co-authored-by: Ismael <ismael@vercel.com>
This PR adds an error doc for the Middleware deprecation warning that it
can refer to.
- Explain why this error occurred
- Provide migration guide
- Explain the rationale for the renaming to Proxy
---------
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
### What?
Updated Zod syntax to v4 conventions in documentation examples.
### Why?
Zod 4 deprecates `message` parameter in favor of `error`, and string
format methods like `.email()` in favor of top-level functions like
`z.email()`.
### How?
- Replaced `{ message: '...' }` with `{ error: '...' }`
- Changed `z.string().email()` to `z.email()`
---------
Co-authored-by: Maxim Andriushin <maksim.andriushin@gmail.com>
Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
As part of stabilizing `cacheComponents`, `cacheLife` profiles should
also be accessible from a top-level config. This updates the
configuration, adds the warning, and updates relevant docs.
This moves `experimental.cacheComponents` to a top level config. As part
of this, I disabled some tests in `build-output-prerender` that assert
on `cacheComponents` appearing in the experimental list. In a separate
PR, I'm going to show that Cache Components is enabled next to the
bundler info.
This also updates some docs pages to remove "experimental" language.
Follow up on https://github.com/vercel/next.js/pull/84710,
`instrumentation` docs had `onRequestError` function's param
`context.routeType` has value of `'middleware'`. As it's a user-facing
value, update it to `'proxy'`.
Joseph