It makes copy-pasting the code easier since the person will be aware of
the import
<!--
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 that you're making:
-->
## Documentation / Examples
- [ ] Make sure the linting passes by running `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: JJ Kasper <jj@jjsweb.site>
Added support for search params and NEXT_LOCALE cookie if set
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `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`
- [ ] Integration 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`
## Documentation / Examples
- [ ] Make sure the linting passes by running `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: JJ Kasper <jj@jjsweb.site>
<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order 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 that you're making:
-->
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Made an addition to the version history within the Script component
docs. In the docs there are examples where the Script component is being
used within a _document.js/tsx file, but it does not get mentioned that
this is only supported from version 12.2.2 onwards.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Follow-up to https://github.com/vercel/next.js/pull/39539 as discussed
this renames to `unstable_` prefix initially while we test this out
further.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
### 📖 What's in there?
Dynamic code evaluation (`eval()`, `new Function()`, ...) is not
supported on the edge runtime, hence why we fail the build when
detecting such statement in the middleware or `experimental-edge` routes
at build time.
However, there could be false positives, which static analysis and
tree-shaking can not exclude:
- `qs` through these dependencies (get-intrinsic:
[source](https://github.com/ljharb/get-intrinsic/blob/main/index.js#L12))
- `function-bind`
([source](https://github.com/Raynos/function-bind/blob/master/implementation.js#L42))
- `has`
([source](https://github.com/tarruda/has/blob/master/src/index.js#L5))
This PR leverages the existing `config` export to let user allow some of
their files.
it’s meant for allowing users to import 3rd party modules who embed
dynamic code evaluation, but do not use it (because or code paths), and
can't be tree-shaked.
By default, it’s keeping the existing behavior: warn in dev, fails to
build.
If users allow dynamic code, and that code is reached at runtime, their
app stills breaks.
### 🧪 How to test?
- (existing) integration tests for disallowing dynamic code evaluation:
`pnpm testheadless --testPathPattern=runtime-dynamic`
- (new) integration tests for allowing dynamic code evaluation: `pnpm
testheadless --testPathPattern=runtime-configurable`
- (amended) production tests for validating the new configuration keys:
`pnpm testheadless --testPathPattern=config-validations`
To try it live, you could have an application such as:
```js
// lib/index.js
/* eslint-disable no-eval */
export function hasUnusedDynamic() {
if ((() => false)()) {
eval('100')
}
}
export function hasDynamic() {
eval('100')
}
// pages/index.jsx
export default function Page({ edgeRoute }) {
return <p>{edgeRoute}</p>
}
export const getServerSideProps = async (req) => {
const res = await fetch(`http://localhost:3000/api/route`)
const data = await res.json()
return { props: { edgeRoute: data.ok ? `Hi from the edge route` : '' } }
}
// pages/api/route.js
import { hasDynamic } from '../../lib'
export default async function handle() {
hasDynamic()
return Response.json({ ok: true })
}
export const config = {
runtime: 'experimental-edge' ,
allowDynamic: '/lib/**'
}
```
Playing with `config.allowDynamic`, you should be able to:
- build the app even if it uses `eval()` (it will obviously fail at
runtime)
- build the app that _imports but does not use_ `eval()`
- run the app in dev, even if it uses `eval()` with no warning
### 🆙 Notes to reviewers
Before adding documentation and telemetry, I'd like to collect comments
on a couple of points:
- the overall design for this feature: is a list of globs useful and
easy enough?
- should the globs be relative to the application root (current
implementation) to to the edge route/middleware file?
- (especially to @sokra) is the implementation idiomatic enough? I've
leverage loaders to read the _entry point_ configuration once, then the
ModuleGraph to get it back during the parsing phase. I couldn't re-use
the existing `getExtractMetadata()` facility since it's happening late
after the parsing.
- there's a glitch with `import { ServerRuntime } from '../../types'` in
`get-page-static-info.ts`
([here](https://github.com/vercel/next.js/pull/39539/files#diff-cb7ac6392c3dd707c5edab159c3144ec114eafea92dad5d98f4eedfc612174d2L12)).
I had to use `next/types` because it was failing during lint. Any clue
why?
### ☑️ Checklist
- [ ] 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`
- [x] Integration tests added
- [x] Documentation added
- [x] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
I was a little confused by the `loading` property having the value `<header />`. I think that property is meant to show a loading state while the file is being loaded? If my assumption is correct, I think this change makes sense.
See the blog post:
https://nextjs.org/blog/next-12-3##swc-minifier-stable
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR updates the server components documentation to make it more clear the benefit of server components and what their current status is inside Next.js.
It removes code snippets and CTAs for trying them out, as things have changed with the Layouts RFC since these docs were previously written. With the upcoming changes, server components will now be the default inside `app`. The list of supported and unsupported features was no longer accurate.
We will be providing more guidance as the layouts and routing changes are ready to be tested.
[Read the Layouts RFC](https://nextjs.org/blog/layouts-rfc) for more details.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
The MDX guide is missing `@mdx-js/react` as a required dependency in the
setup section.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Hello,
Just update the docs to be aligned with the current middleware implementation 🙂
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order 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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR updates the next/image and `next/future/image` sizes docs to use `max-width` in the `sizes` media query, for code style and consistency reasons.
This PR is a minor change to the image docs (`next/image` and `next/future/image`). The example sizes media queries are switched from `em` to `px` for readability.
I found that `fallback: true` behaves like `fallback: blocking` when client-side page transition, but document doesn't mention the behavior.
I tried following.
* created a SSG page which has getStaticPaths and getStaticProps, and the getStaticProps is too slow(something like `await setTimeout(10000)`)
* `next build && next start`, not `next dev`
* tried page reload and client-side page transition both
getServerSideProps document explains about client-side page transition.
https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props#when-does-getserversideprops-run
On the other hand, getStaticPaths didn't explain this behavior, so I added it.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
### 📖 What's in there?
Middleware matchers are powerful, but very few people realized it, because they are not really documented.
This PR tries to bring more clarity, and includes a more advanced example.
The example shows how to exclude several pages (no `/static`, no `/public`), but also allow specific page in excluded paths (`/public/disclaimer`)
### 🧪 How to test?
Run the example: `pnpm next dev examples/middleware-matcher`, then browse to http://localhost:3000
The first 3 links should not match, the last 3 ones should.
Don't forget to clear your localhost cookies if you change the middleware code.
### 🆙 Note to reviewers
Using session cookies to pass information from middleware to the rendered page is not great, because `document.cookie` is not available during SSR, and because cookies persist when refreshing the page (making it hard to try different matchers)
However, I couldn't find a simpler way to convey the information from the middleware to the page, and I meant to have something visual. The other option is to use response headers and curl commands, but...
This PR updates a few features from experimental to stable status:
- `next/future/image` component
- `remotePatterns` configuration
- `unoptimized` configuration
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [X] Make sure the linting passes by running `pnpm lint`
- [X] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This `alt` attribute is required by `<img>` according to the HTML spec, so we should also make it required for `next/future/image`. In the cases where it is not needed, it can be set to the empty string.
https://html.spec.whatwg.org/multipage/images.html#alt
This PR improves the Testing documentation in [Setting up Jest (with the Rust Compiler)](https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler). It adds JSDoc typing in `jest.config.js`.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
Adding a precision because when you change the `pageExtensions` configuration in `next.config.js`, `middleware.ts` isn't recognized anymore.
Took me some time to debug this one, not sure if it should be considered a bug or just lack of documentation.
I'll let you be the judge of that.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Update the cache behavior with the correct Header name. Updated header name from `x-nextjs-cache` to `x-vercel-cache`
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Reverts vercel/next.js#39931
Let's instead add this to the custom server documentation, in a section on "Using Middleware". Since such a low percentage of folks eject out of the default server, this shouldn't be so high up on the Middleware docs page.
This makes it more clear that using Document is recommended for the best font experience, versus manually adding it every page. More updates coming to this page in the future as we add support for more features here.
This wasn't obvious to me when trying out middleware in our project, and the error message was `Invalid URL` - took me embarrassingly long to remember that we run a custom server. Would it be possibly to detect that middleware is used and then throw a descriptive error message when trying to call `next` without `hostname` and `port` in a custom server? If someone can point me to where that could be done, I would be happy to make a pull request.
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
I made the change in Github ui, so couldn't run `pnpm lint`. Is this automated or should I clone and run it locally?
The term client-side rendering is ambiguous and misleading.
Some people would assume the architecture where a blank page is returned from the server and HTML generation is totally done on the frontend.
So I changed the term to `client-side data fetching`, which is widely used throughout the rest of the document.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
The documentation is concise and straightforward, so I just added a sentence.
Let me know if you'd like to describe more, add an example, etc.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This PR adds a warning note for using the exportPathMap function with getStaticPaths. Any routes defined with EPM will get overridden if that page uses GSP.
Bug
Related issues linked using #534
Integration tests added
Errors have helpful link attached, see 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
Integration tests added
Documentation added
Telemetry added. In case of a feature if it's used or not.
Errors have helpful link attached, see contributing.md
Documentation / Examples
Make sure the linting passes by running pnpm lint
The examples guidelines are followed from our contributing doc
By making `NextPageWithLayout` generic and passing the type parameters to `NextPage`, our pages can continue to specify the props explicitly. This gives us type safety in `getInitialProps`, for example.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
See https://github.com/vercel/next.js/issues/39144
It's not completely clear that `/_error` should not be used as a normal page. Added a note under `Caveats` in the custom error page article
This PR adds section to `next/future/image` docs about Known Browser Bugs. This also includes workarounds that might vary depending on the image and how the user plans to use it.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Based on the PR #39407, the sidebar title for API middlewares is changed from "API Middlewares" to "Request Helpers".
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
The [comparison table for migration](https://nextjs.org/docs/api-reference/next/future/image#migration) to `next/future/image` looks odd layout-wise. The issue was brought up via this [Slack thread](https://vercel.slack.com/archives/C02F56A54LU/p1660040275310949).
This PR makes this improvement.
### New implementation
<img width="1216" alt="image" src="https://user-images.githubusercontent.com/12712988/183631902-6850836b-cb4e-44ea-909f-ba353725be15.png">
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
* Update `router.prefetch` documentation
Include documentation for setting the locale as an option within `router.prefetch`.
* apply suggestions
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR updates the documentation for the `sizes` proper in next/image to make it more clear what this prop does and why it's (very) important to use it. After feedback, I'll update this PR to also modify the future image component docs.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Co-authored-by: spcma <46758907+spcma@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR removes the default styling of `object-fit:"contain"` for images using the future image component. This means images will get the default `object-fit` behavior of `"fill"`.
The main reason for this change is that an inline style will take precedence over external CSS, making this default behavior difficult to override with some styling strategies.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Currently next.js polyfills a [subset](https://github.com/vercel/next.js/blob/canary/packages/next-polyfill-nomodule/src/index.js) of APIs for `nomodule` browsers (such as IE 11), however it's not immediately clear to developers which APIs are transparently polyfilled.
For example, currently `Object.entries` is polyfilled and thus is usable in IE 11, but [it was decided](https://github.com/vercel/next.js/pull/15772#discussion_r463984612) that `Object.fromEntries` should not be polyfilled. As a developer, this is a confusing situation until you end up finding the `next-polyfill-nomodule` list of polyfills that are included.
This PR attempts to improve the Supported Browser Features page by:
- linking to the list of polyfills
- clarifying that custom polyfills are required for IE11 (and other old browser) compatibility
- moving the section on Sever-Side polyfills further down the page so all browser polyfill sections are better grouped together
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Documentation / Examples
This PR specifically calls out in more clear language how the rewrites function behaves. This tripped me up recently as I recently came looking for more information, and the documentation left me with more questions than answers. This is an attempt to clear up the confusion I walked away with for anyone who comes in after me.
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR adds a `fill` attribute to the future image component, that behave similarly to the fill mode on the existing image component.
Functionally, it mainly adds `position: "absolute"` and `object-fit: "contain"` to the image element, along with `height: "100%"` and `width: "100%"` to preserve the image aspect ratio. All of these can be overwritten by the user, except for `position: "absolute"`, which will throw an error. This is because changing that property without height and width is likely to cause layout shift.
Because we no longer have the wrapper element, this new version of `fill` requires that the user set `overflow: "hidden"` on the parent element themself, if they want that behavior.
This PR also includes several runtime checks to catch instances where the fill mode may provide unexpected results. These runtime checks warn if:
* The image doesn't have the `sizes` attribute and loads much smaller than the viewport
* The containing element does not have `position: "relative"`
* The image height value is 0
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
In `Generating paths on-demand` section
It was mentioned that `getStaticProps` allows you to control which pages are generated during the build.
But `getStaticPaths` will allows us to control which pages are generated during the build.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Update `e2e/example.spec.ts` ([/docs/testing](https://nextjs.org/docs/testing#creating-your-first-playwright-end-to-end-test) page) to fix the failed test. Fixes: #39194
## Bug
- [ ] Related issues linked using fixes #number
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see 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
- [ ] Integration tests added
- [X] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see contributing.md
## Documentation / Examples
- [ ] Make sure the linting passes by running pnpm lint
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md?rgh-link-date=2022-07-13T09%3A09%3A13Z#adding-examples)
Closes: #30962
This PR adds a new `onReady` prop to `next/script` to handle shortcomings of the current `onLoad` prop. Some third-party providers and widgets require initialization code to run after the script's `load` event and every time the component is mounted. The `onReady` should solve that use case.
For more details, refer to the discussion in #30962.
CC @janicklas-ralph
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
"You [SHOULD NOT](https://datatracker.ietf.org/doc/html/rfc2119#section-4) remove ~n~or edit it" in place of "You cannot remove it or edit it".
Rational:
- It is a strong recommendation; not a weak possibility.
- ~Both actions have a negative connotation; as such, it is appropriate to use "nor"~.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
Fixes grammatical typo found on line 73 of `docs/basic-features/data-fetching/get-static-paths`
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Drop the `next/streaming` endpoint. Currently it only holds the only one experimental api and we'd like to deprecate it in favor of oher future APIs for app dir
Fixes#38533 by including `src/` as a default linting directory where all files within are linted
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Add [bundlejs](https://bundlejs.com/) site - an online tool to quickly bundle & minify your projects, while viewing the compressed gzip/brotli bundle size, all running locally on your browser.
The lowercase name is intentional.
This PR outlines the built-in features of Next.js that help make your application accessible, and will also include some resources for testing/improving accessibility in your app.
Related: https://github.com/vercel/next.js/pull/20428
Ref: #38461, #37346
As [introduced](https://github.com/vercel/next.js/pull/37177/files#diff-7ec7f47987bd890b5b47f6cf101398cd22fa37f874348d70036f85309a040c92
) in #37177, we statically analyze the `matcher` values, so we should make it clear.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This PR adds a missing closing curly bracket in the compiler option example of the [Styled Components](https://nextjs.org/docs/advanced-features/compiler#styled-components).
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [X] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Updated docs to reflect that
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
I've wasted a couple of hours trying to work out why my static build wasn't passing through the props automatically as the docs say it should
Turns out it's the default app doing that and a custom app has to manually passed the props through
It wasn't obvious to me to look in the custom app doc where it's mentioned, so I've added a small note to the `getStaticProps` doc about this that points to the custom app doc
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
According to https://github.com/vercel/next.js/issues/30802 SWC transforms for `styled-components` were updated with support for `cssProp`, `fileName` and `namespace`. The docs only mention support for `ssr` and `displayName`.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
## Documentation / Examples
- [X] Make sure the linting passes by running `pnpm lint`
- [X] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## The Issue
When it came to testing environment variables with jest in the current release of NextJS, I ran into an issue where my variables were seemingly undefined for no reason. With some research and the help from a friend in discussion post #38353 it was determined further configuration steps were needed in relation to the environment variables for jest. At the time being, no direct link is made between [Setting up Jest](https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler) and [Test Environment Variables](https://nextjs.org/docs/basic-features/environment-variables#test-environment-variables).
## The Change
This fix provides further clarification on the issue by creating a new link within the note on the [Setting up Jest](https://nextjs.org/docs/basic-features/environment-variables#test-environment-variables) page. Moreover, further explanations were added to ensure developers understand the `test` environment is completely separate from both `development` and `production` meaning files like `.env.development` and `env.prodution` won't be recognized when testing.
## Supporting Documentation
This is an issue time and time again for developers. Not only have I experienced this, but others have asked on both [GitHub Discussions](https://github.com/vercel/next.js/discussions/16270) and [StackOverflow](https://stackoverflow.com/questions/63934104/environment-variables-undefined-in-nextjs-when-running-jest/67997819#67997819). Moreover, many of the solutions from 2020 no longer work properly.
I hope this is sufficient enough for a contribution to the documentation. Minor improvements like these create the ideal developer experience Next.js is known for. :)
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
[Slack thread](https://vercel.slack.com/archives/C02UJ0QH45Q/p1656580818197009)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
According to the 12.2 release note and the source code, the `next/future/image` does not use `IntersectionObserver` anymore so the `lazyRoot` prop is also not used.
The example probably got left behind unintentionally.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [X] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
AFAIK router.query will still be an empty object during prerendering if you have `getStaticProps`. It will be its "correct" value during prerendering if you're using `getServerSideProps` so this change seems to more accurately describe `router.query`
Readds `@next/next/no-assign-module-variable` ESLint rule that was inadvertently removed in #34335 during the resolution of many merge conflicts.
This PR will get us back to a good / working state. I'll see if I can add a test to ensure all rule are accounted for in a separate PR.
Fixes#34335.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Fixes https://github.com/vercel/next.js/issues/37741. Allows `next/script` to be placed inside of `_document` body in addition to `Head`.
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This rule was good and kinda made sense when we had nested Middleware.
Now that we have a single Middleware, one might extract logic into different places
and I don't think we should limit importing `NextResponse` or `NextRequest`.
## Related
- Closes#36239
- Closes#37309
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This PR fixes flaky `onLoad()` test for `next/image/future`.
The test must modify the `src` after hydration to make sure it always works as expected.
This is because `next/image/future` uses native lazy loading and sometimes the event fires before hydration (docs were updated to mention this)
This PR introduces a new experimental component, `next/future/image`, which is inspired by the existing experimental `layout="raw"`.
The difference is that much of the code has been deleted in order to reduce client-side code as well as reduce complexity:
- No `layout` prop
- No `loader` config (although `loader` prop works)
- No `IntersectionObserver`, use native `loading="lazy"`
- No `lazyBoundary`
- No `lazyRoot`
- No `fill` (yet) so width & height are required
- No `objectFit` (use `style` instead)
- No `objectPosition` (use `style` instead)
This improves performance because native `loading="lazy"` doesn't need to wait for React Hydration and client-side JS.
In a future PR, we will modify `next/image` to remove `layout="raw"` since this new component supersedes it.
## Feature
- [x] Integration tests added
- [x] Documentation added
- [x] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
Follow-up to https://github.com/vercel/next.js/pull/37902 this moves the reference to avoid a change in `next-env.d.ts`. Also updates our doc note on the `next-env.d.ts` file to be more explicit about it being ignored.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This allows configuring / overriding the default options of the `styled-components` swc transform and allows using the `css` prop support, which was already implemented, but not available.
Edit: made the CSS prop transform run before the display name, so it gets picked up by that and receives the (deterministic) name.
Relates to #30802
This adds a new example under `cms-plasmic/`. It serves as a general-purpose example that should be able to work with any Plasmic project, which can be set via environment variables.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR adds a new section for the `userAgent` helper in `next/server`.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Hi~ I added the missing parentheses in document.
4ed0b78ab6/docs/advanced-features/middleware.md (L38-L40)
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
A small change, but eslint wasn't happy until I added this.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
In a previous PR (#19032), we added a hard error during `next export` if the default Image Optimization API is being used because it requires a server to optimized on demand. The error message offers several different solutions but it didn't consider that by the time someone runs `next export`, they are probably done writing their app.
So if `next export` is a hard requirement, the quickest path forward is to disable Image Optimization API. So this PR adds a new configuration option to `next.config.js`:
```js
module.exports = {
images: {
unoptimized: true
}
}
```
### Update
Upon further discussion, we might want to avoid doing this just for images and instead introduce a top-level config to indicate export is coming and then handle errors or warn for [unsupported features](https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features).
```
module.exports = {
nextExport: true
}
```
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Motivation/ Context
- When upgrading `next` from `11` to `12`, I followed [Upgrade guide from 11 => 12](https://nextjs.org/docs/upgrading#upgrading-from-11-to-12). I removed `.babelrc` to opt-in `SWC`. I thought that's all, but after removing `.babelrc`, Jest broke immediately. So I follow the guide https://nextjs.org/docs/advanced-features/compiler#jest to configure Jest to work with SWC. I copied the content of `jest.config.js` to my project but it does not work. The reason:
```diff
-const createJestConfig = nextJest({ dir }) // `dir` IS NOT DEFINED
+const createJestConfig = nextJest({ dir: './' }) // Should change to this. Sync with https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler
```
- This PR is to help others to configure Jest with SWC by copying code from the documentation site without encountering the same issue as I did.
## Documentation
- [x] Update the docs so users can just copy and paste when configuring Jest with SWC (Sync with https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler)
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Future work
- Since [Upgrade guide from 11 => 12](https://nextjs.org/docs/upgrading#upgrading-from-11-to-12) did not mention anything about Jest. If I remove `.babelrc` to opt-in SWC. The current Jest settings will crash (since it's using babel). We likely want to update the Upgrade guide to mention this cc: @leerob
In a previous PR (#34075), the ISR behavior was introduced to the Image Optimization API, however it changed the cache-control header to always set maxage=0. While this is probably the right behavior (the client shouldn't cache the image), it introduced a regression for users who have CDNs in front of a single Next.js instance (as opposed to [multiple Next.js instances](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#self-hosting-isr)).
Furthermore, the pros of client-side caching outweight the cons because its easy to change the image url (add querystring param for example) to invalidate the cache.
This PR reverts the cache-control behavior until we can come up with a better long-term solution.
- Fixes#35987
- Related to #19914
- Related to #22319
- Closes#35596
This PR adds new information to the Next.js deployment documentation to highlight examples or guides for deploying Next.js to a handful of services. This builds on the existing documentation around the Next.js Build API (from `next build`) and options for self-hosting with Node.js or Docker.
## 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`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Missing documentation around `NEXT_DATA` hydration when using `getServerSideProps()`. This PR warn users that the result of `getServerSideProps()/getStaticProps` is also available on the client-side due to React Hydration so they should not use any sensitive information in the props.
## Bug
- [x] Related issues linked using [fixes number](https://github.com/vercel/documentation/issues/418)
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
I couldn't understand well this sentence at the first time of reading as a non native english speaker. I think 'that' is needed here.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
I've improved jest configuration that :
1. Starts collecting test coverage
1. Does not collect coverage for derived files or coverage info itself
1. Uses coverage provider that is based on node itself.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Came across this [Slack thread](https://vercel.slack.com/archives/C02F56A54LU/p1642206518128400). Update the docs about adding `locale` string in `getStaticPaths` docs.
## Feature
- [ ] Related issues linked using #32772
- [x] Documentation added
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Closes: #32772
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
In order to turn the API Routes docs more clear about the file extensions when using `pageExtensions`.
I know that it was already explained [here](https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions).
But just think about the DX: If a developer have a trouble with an API endpoint not working properly should it check it on custom-page-extensions page or api-routes page itself??
Related to https://github.com/vercel/next.js/issues/8178.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Based on https://github.com/vercel/next.js/issues/36551#issuecomment-1113457752 making the docs more clear which also aligns with the wording of Environment Variables in Middlerware: https://nextjs.org/docs/api-reference/next/server#how-do-i-access-environment-variables
See also: https://github.com/vercel/next.js/pull/20869#issuecomment-757799953
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
We added custom _app as server component support in #33149, but we found it's pretty confusing on usage like support it both server component pages and regular pages at the same time for having similar layout purpose.
When using the _app.server and _app at the same time, applying them into proper places become more confusing.
In that case, we decide to make _app.js can't be a server component, and you can still keep all the existing thing there. And also you don't need to think of the corresponding APIs of custom _app in RSC
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Docs updated
_Hello Next.js team! First PR here, I hope I've followed the right practices._
### What's in there?
It has been decided to only support the following uses cases in Next.js' middleware:
- rewrite the URL (`x-middleware-rewrite` response header)
- redirect to another URL (`Location` response header)
- pass on to the next piece in the request pipeline (`x-middleware-next` response header)
1. during development, a warning on console tells developers when they are returning a response (either with `Response` or `NextResponse`).
2. at build time, this warning becomes an error.
3. at run time, returning a response body will trigger a 500 HTTP error with a JSON payload containing the detailed error.
All returned/thrown errors contain a link to the documentation.
This is a breaking feature compared to the _beta_ middleware implementation, and also removes `NextResponse.json()` which makes no sense any more.
### How to try it?
- runtime behavior: `HEADLESS=true yarn jest test/integration/middleware/core`
- build behavior : `yarn jest test/integration/middleware/build-errors`
- development behavior: `HEADLESS=true yarn jest test/development/middleware-warnings`
### Notes to reviewers
The limitation happens in next's web adapter. ~The initial implementation was to check `response.body` existence, but it turns out [`Response.redirect()`](https://github.com/vercel/next.js/blob/canary/packages/next/server/web/spec-compliant/response.ts#L42-L53) may set the response body (https://github.com/vercel/next.js/pull/31886). Hence why the proposed implementation specifically looks at response headers.~
`Response.redirect()` and `NextResponse.redirect()` do not need to include the final location in their body: it is handled by next server https://github.com/vercel/next.js/blob/canary/packages/next/server/next-server.ts#L1142
Because this is a breaking change, I had to adjust several tests cases, previously returning JSON/stream/text bodies. When relevant, these middlewares are returning data using response headers.
About DevEx: relying on AST analysis to detect forbidden use cases is not as good as running the code.
Such cases are easy to detect:
```js
new Response('a text value')
new Response(JSON.stringify({ /* whatever */ })
```
But these are false-positive cases:
```js
function returnNull() { return null }
new Response(returnNull())
function doesNothing() {}
new Response(doesNothing())
```
However, I see no good reasons to let users ship middleware such as the one above, hence why the build will fail, even if _technically speaking_, they are not setting the response body.
## Feature
- [x] 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`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
This PR deprecates declaring a middleware under `pages` in favour of the project root naming it after `middleware` instead of `_middleware`. This is in the context of having a simpler execution model for middleware and also ships some refactor work. There is a ton of a code to be simplified after this deprecation but I think it is best to do it progressively.
With this PR, when in development, we will **fail** whenever we find a nested middleware but we do **not** include it in the compiler so if the project is using it, it will no longer work. For production we will **fail** too so it will not be possible to build and deploy a deprecated middleware. The error points to a page that should also be reviewed as part of **documentation**.
Aside from the deprecation, this migrates all middleware tests to work with a single middleware. It also splits tests into multiple folders to make them easier to isolate and work with. Finally it ships some small code refactor and simplifications.
This PR changes the experimental `layout=raw` images to use the native lazy loading behavior (as opposed to the IntersectionObserver).
This will (eventually) lead to smaller client bundles and faster image loading since there is no JS needed to load the image.
However, we'll lose the `lazyRoot` and `lazyBoundary` behavior since those are specific to the IntersectionObserver implementation.
Clarify that the environment variables are ordered in descending priority and that the existing system environment is not overridden.
fixes https://github.com/vercel/next.js/issues/36966
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using [19693](https://github.com/vercel/next.js/discussions/19693)
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ x] Make sure the linting passes by running `yarn lint`
Closes#29959
If I understand correctly, a page that relies on `publicRuntimeConfig` must be server-side rendered, then that page need either `getInitalProps` or `getServerSideProps`, or the application has a Custom App with `getInitialProps` enabled.
* remove the experimental web vital hook api
* remove the exported flush effects api and only error on development, keep only usage to styled-jsx
for web vital hook API: The usage is not widly adopted since the existing exported vital api could do the same work. In the future we'll deprecate the `_app.server` in favor of `_app` in server component pages. so that this api won't be required.
for flush effects api: other css-in-js libs are not using the same approach like styled-jsx which holding a style registry and could flush it during streaming. emotion-js and styled-components are still relying on `Document.getInitialProps` atm and we have supported it in latest canary
Small docs fix. We've got a snazzy new website at typescript-eslint.io. Eventually the .md docs pages will serve just as partial docs sources, not the right URL to visit.
fixes#28453
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [X] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [X] Make sure the linting passes by running `yarn lint`
This PR moves the instructions for configuring CI providers to preserve Next.js's build cache out of the _No Cache Detected_ error message and into ~the _Deployment_~ a new page within the _Advanced Features_ docs.
This change is beneficial because it makes the CI configuration examples visible in the context of other helpful documentation for deploying Next.js.
👉 **Prior to this change, these CI configuration examples didn't show up in the Next.js docs.**
The relocated instructions are now linked on the _No Cache Detected_ error message page.
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
Co-authored-by: Lee Robinson <me@leerob.io>
Co-authored-by: Steven <steven@ceriously.com>
copy/pasting the SCSS example into VSCode results in linter warning. Fixed with semicolon on variable assignment. Added the second semicolon for consistency.
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This PR updates the copy in the source maps section of the docs to reflect the improvement made to webpack that generate source maps.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
## Documentation / Examples
- Updating Tina Demo URL
- Adding Tina to blog-starter example
- Adding Tina to Basic features section
- Updating Tina to actually work again
This PR introduces a more predictable API to manipulate cookies in an Edge Function context.
```js
const response = new NextResponse()
// set a cookie
response.cookies.set('foo, 'bar') // => set-cookie: 'foo=bar; Path=/'`
// set another cookie
response.cookies.set('fooz, 'barz') // => set-cookie: 'foo=bar; Path=/, fooz=barz; Path=/'`
// delete a cookie means mark it as expired
response.cookies.delete('foo') // => set-cookie: 'foo=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT, fooz=barz; Path=/'`
// clear all cookies means mark all of them as expired
response.cookies.clear() // => set-cookie: 'fooz=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT, foo=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT'`
```
This new cookies API uses [Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) interface, and it's available for `NextRequest` and `NextResponse`.
Additionally, you can pass a specific cookies option as a third argument in `set` method:
```js
response.cookies.set('foo', 'bar', {
path: '/',
maxAge: 60 * 60 * 24 * 7,
httpOnly: true,
sameSite: 'strict',
domain: 'example.com'
}
```
**Note**: `maxAge` it's in seconds rather than milliseconds.
Any cookie manipulation will be reflected over the `set-cookie` header, transparently.
closes#31719
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
…rding due to customer confusion
This PR updates the middleware (edge functions) api docs environment section to remove the dev and prod wording due to customer confusion
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
## Description
This PR implements a new configuration object in `next.config.js` called `experimental.images.remotePatterns`.
This will eventually deprecate `images.domains` because it covers the same use cases and more by allowing wildcard pattern matching on `hostname` and `pathname` and also allows restricting `protocol` and `port`.
## Feature
- [x] Implements an existing feature request.
- [x] Related issues linked
- [x] Unit tests added
- [x] Integration tests added
- [x] Documentation added
- [x] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
## Related
- Fixes#27925
- Closes#18429
- Closes#18632
- Closes#18730
- Closes#27345
This variable is exported by next but undocumented, and its usage is necessary to build auxiliary scripts for your server-side applications. See https://github.com/vercel/next.js/issues/36237#issuecomment-1117694528 for an example.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Mention that the HTTP.IncomingMessage object is augmented by `cookies` in getServerSideProps
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Improve wording
- [ ] Make sure the linting passes by running `yarn lint`
* Added type to Page Component for TypeScript
Following this tutorial, I noticed that TS was complaining that "getLayout" did not exist on Page. That is normal since Page is typed as NextPage. I simply exported the new type we create in "_App.tsx" and used it as the return type for Page. This will probably help others seeing that red in their editors and perhaps being confused.
* Small linting change
* Apply suggestions from code review
* Update layouts.md
* lint fix
* update type
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This should be made explicitly clear because other code may just call `next` instead of `next dev` (e.g. https://github.com/netlify/framework-info/blob/main/src/frameworks/next.json).
Being in the ninth circle of debug hell right now I could not take it for granted that the two were the same till I saw some kind of confirmation, either from the docs or from the source. Source is great, but calling it out in the docs would saved me some time.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
This makes it clear that the font optimization adds these for you.
This avoids duplicate `<link rel="preconnect" />` in the HTML output if the developer is unaware that it is being added automatically.
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
ISR works self-hosted, but there's some more guidance needed when hosting with container-based setups (e.g. Kubernetes) and how the files are shared between different pods. This was based on community feedback. Please let me know if you'd like to see any additions here! 🙏
This PR makes the following changes:
* Always add the `height` and `width` prop to image with `raw` layout (previously only added to images without `sizes`)
* Add a warning if a raw layout image is getting stretched (which can be caused by interaction of height and width prop with styles)
* Remove automatic aspect-ratio style from `raw` images. This is no longer necessary if all `raw` images have height and width props.
* Update tests and docs accordingly
Changing the paragraph to not include `beforeInteractive` as one of the possible use cases of `onLoad`.
*Update:* Added docs for `onError` in the API reference of `next/script`.
@housseindjirdeh does `onError` also has the same limitation or is this only for `onLoad`?
Closes https://github.com/vercel/next.js/issues/33402
## 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`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
