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)
