Sends web vitals to Vercel analytics.
My plan for the test was to assert the data sent by the client but there's a bug where it's always null when sending a blob https://github.com/microsoft/playwright/issues/6479.
When adding support for a custom web vitals reporter it will be easier to assert the values sent by the reporter.
Small change leveraging the `createFromFetch` method instead.
## 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)
When the error comes from the RSC transform in SWC, we want to enforce the verbose mode because the module trace can be critical here. An example:
<img width="635" alt="CleanShot 2022-09-18 at 12 37 02@2x" src="https://user-images.githubusercontent.com/3676859/190898135-7b258ae1-64e4-4c7b-b4d3-b2e9d2ee0245.png">
Also in this PR I changed `trace.originName` to `trace.moduleName` in the output as the former can contain loader information and options:
```
Import trace for requested module:
./app/dashboard/index/page.js
../../../../packages/next/dist/build/webpack/loaders/next-app-loader.js?name=app%2Fdashboard%2Findex%2Fpage&appPaths=%2Fdashboard%2Findex%2Fpage&pagePath=private-next-app-dir%2Fdashboard%2Findex%2Fpage.js&appDir=%2FUsers%2Fshu%2FDocuments%2Fgit%2Fnext.js%2Ftest%2Fe2e%2Fapp-dir%2Fapp%2Fapp&pageExtensions=tsx&pageExtensions=server.tsx&pageExtensions=client.tsx&pageExtensions=ts&pageExtensions=server.ts&pageExtensions=client.ts&pageExtensions=jsx&pageExtensions=server.jsx&pageExtensions=client.jsx&pageExtensions=js&pageExtensions=server.js&pageExtensions=client.js!
```
## 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)
This is an initial implementation of the Server Components SWC
transformer. For the server graph, it detects client entries via the
`"client"` directive and transpile them into module reference code; for
the client graph, it removes the directives. And for both graphs, it
checks if there is any invalid imports for the given environment and
shows proper errors.
With that added, we can switch from `next-flight-client-loader` to
directly use the SWC loader in one pass. Next step is to get rid of the
`.client.` extension in other plugins.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## 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
- [ ] 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)
x-ref: https://github.com/facebook/react/pull/25267
Bump the version of `react-server-dom-webpack` and use `experimental_use` to unwrap the promise to access RSC payload instead of using `readRoot`. `readRoot` is removed from the response type.
This masks flight parameters from middleware so it doesn't interfere with RSC or routing.
## 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: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Another step toward fixing #40025.
Multiple `next/script` components with the same `src` may exist in the
Next.js app. So the `loadScript` function will always attach the
`onLoad` handler to the `loadingPromise` every time it executes.
However, with strict mode (or wrapped inside the `<OffScreen />`
component), the `useEffect` could execute more than once for the same
`next/script` component, thus the `loadScript` for each `next/script`
component could execute more than once (and `onLoad` to be attached more
than once), results in `onLoad` fires more than once.
The PR makes sure that for every `next/script` component mounted, the
`loadScript` will always be executed only once for each of them.
The corresponding `onload fires correctly` integration test case is also
updated to run in dev mode.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
- Use React.startTransition instead of useTransition
- Upgrade to latest React experimental
- Split router cache invalidate into separate function
Some minor cleanup while verifying behaviors.
Found that the cause was that `React.useId()` returns the same value across requests whereas it was being used to create a unique key. On further inspection that code could be removed altogether as `id` was not used client-side and the `rscCache` map is no longer needed as the flight instance is already being created per request so it can live in the context of the request execution.
## 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 allows you to resize a statically imported image using only `width` or only `height`. For example:
```jsx
import img from './img.jpg'
<Image src={img} width="200" />
```
Previously, you had to specify both or else the image aspect ratio would not be preserved.
Follow-up to #37551
Implements prefetching for the new router.
There are multiple behaviors related to prefetching so I've split them out for each case. The list below each case is what's prefetched:
Reference:
- Checkmark checked → it's implemented.
- RSC Payload → Rendered server components.
- Router state → Patch for the router history state.
- Preloads for client component entry → This will be handled in a follow-up PR.
- No `loading.js` static case → Will be handled in a follow-up PR.
---
- `prefetch={true}` (default, same as current router, links in viewport are prefetched)
- [x] Static all the way down the component tree
- [x] RSC payload
- [x] Router state
- [ ] preloads for the client component entry
- [x] Not static all the way down the component tree
- [x] With `loading.js`
- [x] RSC payload up until the loading below the common layout
- [x] router state
- [ ] preloads for the client component entry
- [x] No `loading.js` (This case can be static files to make sure it’s fast)
- [x] router state
- [ ] preloads for the client component entry
- `prefetch={false}`
- [x] always do an optimistic navigation. We already have this implemented where it tries to figure out the router state based on the provided url. That result might be wrong but the router will automatically figure out that
---
In the first implementation there is a distinction between `hard` and `soft` navigation. With the addition of prefetching you no longer have to add a `soft` prop to `next/link` in order to leverage the `soft` case.
A heuristic has been added that automatically prefers `soft` navigation except when navigating between mismatching dynamic parameters.
An example:
- `app/[userOrTeam]/dashboard/page.js` and `app/[userOrTeam]/dashboard/settings/page.js`
- `/tim/dashboard` → `/tim/dashboard/settings` = Soft navigation
- `/tim/dashboard` → `/vercel/dashboard` = Hard navigation
- `/vercel/dashboard` → `/vercel/dashboard/settings` = Soft navigation
- `/vercel/dashboard/settings` -> `/tim/dashboard` = Hard navigation
---
While adding these new heuristics some of the tests started failing and I found some state bugs in `router.reload()` which have been fixed. An example being when you push to `/dashboard` while on `/` in the same transition it would navigate to `/`, it also wouldn't push a new history entry. Both of these cases are now fixed:
```
React.startTransition(() => {
router.push('/dashboard')
router.reload()
})
```
---
While debugging the various changes I ended up debugging and manually diffing the cache and router state quite often and was looking at a way to automate this. `useReducer` is quite similar to Redux so I was wondering if Redux Devtools could be used in order to debug the various actions as it has diffing built-in. It took a bit of time to figure out the connection mechanism but in the end I figured out how to connect `useReducer`, a new hook `useReducerWithReduxDevtools` has been added, we'll probably want to put this behind a compile-time flag when the new router is marked stable but until then it's useful to have it enabled by default (only when you have Redux Devtools installed ofcourse).
> ⚠️ Redux Devtools is only connected to take incoming actions / state. Time travel and other features are not supported because the state sent to the devtools is normalized to allow diffing the maps, you can't move backward based on that state so applying the state is not connected.
Example of the integration:
<img width="1912" alt="Screen Shot 2022-09-02 at 10 00 40" src="https://user-images.githubusercontent.com/6324199/188637303-ad8d6a81-15e5-4b65-875b-1c4f93df4e44.png">
The PR is the first step toward fixing #40025. The PR makes the `script-loader` integration test run on both dev and production modes.
Some existing test cases are skipped in dev mode because corresponding features are not strict mode resilient and thus will fail. They will be included in dev mode tests in the future.
The PR also merges some duplicated logic in `next/script`, and adds a detailed comment about how `onReady` works.
In the next PR, I will try to fix `onLoad` being called more than once under strict mode.
Co-authored-by: Houssein Djirdeh <houssein.djirdeh@gmail.com>
This PR updates a few features from experimental to stable status:
- `next/future/image` component
- `remotePatterns` configuration
- `unoptimized` configuration
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
## Feature
As the title, support `has` match, `local` that works the same with the `rewrites` and `redirects` of next.config.js on middleware config. With this PR, you can write the config like the following:
```js
export const config = {
matcher: [
"/foo",
{ source: "/bar" },
{
source: "/baz",
has: [
{
type: 'header',
key: 'x-my-header',
value: 'my-value',
}
]
},
{
source: "/en/asdf",
locale: false,
},
]
}
```
Also, fixes https://github.com/vercel/next.js/issues/39428
related https://github.com/vercel/edge-functions/issues/178, https://github.com/vercel/edge-functions/issues/179
- [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
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR removes `<noscript>` from `next/future/image` since it is no longer needed now that we use a svg blur placeholder (as opposed to css filter).
- Fixes #38621
- Closes#39736
This PR updates the `next/future/image` component so that CSS `filter` is never needed. Previously, we used SVG to blur for prod and CSS to blur for dev, but now we use SVG for both.
This required a shared function `getImageBlurSvg()` used between both client and server because `next dev` doesn't create Data URIs and instead defers blur generation until request time. So we also need to defer svg generation to request time (on the server) during next dev.
This is the first step to removing `<noscript>` completely (see #39736).
Typescript published 4.8.2 today and it fails CI, bump our typescript version to 4.8.2 and tweak some typings to make existing e2e typescript tests work properly
* Bump web-vitals from 3.0.0-beta to 3.0.0 stable for typing fix (there's an undefined type but it wasn't caught by ts 4.7), also force compiled it as CJS for pre-compiled
* Bump ncc to 3.34.0 for ts-loader compatibility for new typescript version, ncc 3.33.x cannot work with ts 4.8
* Update pre-compiled
We only use `if (child.type === Script)` on the server side to check the
element type, that's unnecessary because we can add a special flag for
that (`__nextScript` in this PR).
This reduces the server bundle by ~13kb if `next/script` is not imported
by the user.
## 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)
Fixes#39993.
Before the PR:
- `next/script` component mount, `useEffect` for `onReady` executes
- The script's cacheKey is not added to `LoadCache`, skip `onReady`
- The second `useEffect` for `loadScript` executes
- The script's cacheKey is added to `LoadCache` even if it might not fully load yet
- Because of React's strict mode, `useEffect` for `onReady` executes again
- Since the script's cacheKey is in `LoadCache`, `onReady` is called (even when the script is not loaded yet)
- After the script is actually loaded, inside the `script.onload` event handler the `onReady` is called again
After the PR:
- `next/script` component mount, `useEffect` for `onReady` executes
- The script's cacheKey is not added to `LoadCache`, `useEffect` skips `onReady`
- The second `useEffect` for `loadScript` executes
- The script's cacheKey is added to `LoadCache` only if it is an inline script
- Because of React's strict mode, `useEffect` for `onReady` executes again
- The script is not yet loaded, its cacheKey is not in `LoadCache`, `useEffect` skips `onReady` again
- After the script is actually loaded, inside the `script.onload` event handler the `onReady` is finally called
In short, the PR resolves a race condition that only occurs under React strict mode (and makes the `next/script` component more concurrent rendering resilient).
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This warning was incorrectly printed when `fill` and `placeholder="blur"` were used together:
> Image with src "/test.jpg" is smaller than 40x40. Consider removing the "placeholder='blur'" property to improve performance.
This PR is a follow up to PR #39190 so that we can dynamically set the `feComponentTransfer` when we know the image doesn't have transparency (at this time its just jpeg).
We also set the stdDeviation to 1 and the viewbox to the placeholder's width/height to avoid any rounding issues.
Finally, we also fix the conversion from `objectPosition` to `backgroundPosition` because they have different default values according to the spec.
Fixes#39807.
When statically importing an image, the `width` and `height` will always be provided alongside the `src` by the Webpack. `next/image` will ignore `width` and `height` come from Webpack when `layout === 'fill'`, while `next/future/image` will not, hence the issue. The PR fixes that. The corresponding integration test cases are also added.
cc @styfle
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Removed the hack of client-side CSS injection via `chunk`. Instead collect them with the manifest plugin and SSR them as link tags.
Next step is to adjust HMR to not relying on mini-css-extract plugin and webpack.
Improve PR improves the error message on `next/future/image` when `objectFit` or `objectPosition` is provided and suggests using `style` instead. It also prints the stack trace so its clear where the error came from.
The PR neither fixes a bug nor introduces a new feature. It just makes the current code be more clearer.
We track the `unobserve` method (to clear the side-effect) in a ref before this PR which is not required anymore:
- The `unobserve` method can only be created during the `useEffect`
- The `unobserve` method will be called during `useEffect` cleans up.
In short, the "life cycle" of the `unobserve` method now only lives inside the `useEffect`. So we can remove the usage of `useRef`.
The PR is similar to #39791.
Currently, `<Portal />` saves the container in a ref (with initial value as `null`). The update of the ref happens during the `useEffect`, after creating the corresponding HTMLElement. However, `<Portal />` has to use `forceUpdate` since mutating a ref will not cause the component to update.
The PR fixes that by saving the container of the `Portal` in a state, so no more `forceUpdate`.
Follow-up to the earlier enabling of classes/variables etc.
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
Co-authored-by: Steven <steven@ceriously.com>
WIP.
## 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: Shu Ding <3676859+shuding@users.noreply.github.com>
This PR adds default style properties to a fill-mode image using `next/future/image` of 0 for all positions. This should replicate the existing `layout="fill"` behavior better, and make it easier to migrate.
Tests are also added for fill styling.
## Bug
- [fixes#39035 ] 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>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## Bug
- [x] Fixes#38047
- ~[ ] Integration tests added: do you want them added for such an unusual edge case?~ [Comment below: skipping](https://github.com/vercel/next.js/pull/38046#issuecomment-1207444526)
- [x] Errors have helpful link attached, see `contributing.md`: ~I'll wait until this approach & error message are confirmed before thinking more deeply on how to explain the error~
Sending a draft PR as reference ahead of time. 🙂
Doesn't resolve the root issue of why `_devPagesManifest.json` might fail to load. But does improve the log for when it happens. I'd suggest applying this same fix to `_devMiddlewareManifest.json` too.
<table>
<thead>
<tr>
<th></th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<th>Console</th>
<td>
<pre>
<code>
Failed to fetch devPagesManifest TypeError: Failed to fetch
at PageLoader.getPageList (page-loader.js?e87a:30:53)
at _callee$ (router.js?8684:955:45)
at ...
</code>
</pre>
<pre>
<code>
router.js?8684:1319 Uncaught (in promise) TypeError: Cannot \
read properties of undefined (reading 'includes')
at resolveDynamicRoute (router.js?8684:1319:16)
at _callee$
at ...
</code>
</pre>
</td>
<td>
<pre>
<code>
Failed to fetch devPagesManifest: TypeError: Failed to fetch
at PageLoader.getPageList (page-loader.js?e87a:30:53)
at _callee$ (router.js?8684:955:45)
at ...
</code>
</pre>
</td>
</tr>
<tr>
<th>Visual</th>
<td><img alt="Screenshot of a Next.js runtime error: TypeError: Cannot read properties of undefined (reading 'includes')" src="https://user-images.githubusercontent.com/3335181/175854728-8d5c2051-1229-4da7-8af1-fc95236befae.png" /></td>
<td><img alt="Screenshot of a Next.js runtime error: Error: Failed to fetch _devPagesManifest.json. Is something blocking that network request?" src="https://user-images.githubusercontent.com/3335181/175854774-07895846-1a1c-4bb8-bf57-fa696b8c6ba4.png" /></td>
</tr>
</tbody>
</table>
In many browsers (other than Chrome), the `alt` text is visible while the image is loading. This causes a sense layout shift since you'll see a flash of text and then the image (although lighthouse measures 0 CLS, likely because Chrome doesn't have this problem). This PR updates `next/future/image` to hide the alt text, unless there is an error while loading the image in which case the `alt` text because relevant as the fallback.
Example:
<img width="115" alt="image" src="https://user-images.githubusercontent.com/229881/183128008-0660c50c-18aa-4e64-872e-ada9a652130f.png">
Unfortunately, Safari also shows a border while lazy loading images and it cannot be styled.
See upstream issue here: https://bugs.webkit.org/show_bug.cgi?id=243601
Hi,
- Remove inlined CSS style which have minor performance loss. And hoist it to top of the component.
> Each time you inline an object, React re-creates a new reference to this object on every render. This causes components that receive this object to treat it as a referentially different one which have some performance pitfalls.
_Extremely sorry if I made any mistakes :(_
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>
Use flush effects to custom apply css-in-js solution to app. Re-introduce flush effects to app-render, and remove default support of styled-jsx in `app/`. So that users will choose their own css-in-js solution if they need any customization. styled-jsx won't appear in client bundle if you didn't use it.
For now we have to inject the initial styles before `</head>` to avoid hydration errors. Later on we can remove this once react can handle it.
- [x] inject styles before end of head element
- [x] add tests
This ensures we properly leverage the `assetPrefix` for `app`. Note for reviewing the test changes are mostly spacing so hiding that may help.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes: [slack thread](https://vercel.slack.com/archives/C035J346QQL/p1659387244559979)
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>
x-ref #39199
The change in #39199 isn't correct. Middleware manifest should only contain middleware route, so that when router navigates, it only try to apply middleware instead of checking all edge routes. This PR also changes the middleware manifest global value from array to object for easier access
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Add `next/dist/client/components/shared/dynamic` as shared api which server and client components can both support.
Dynamic imports will be part of flight on server side.
This pr doesn't contain preloading part for client components.
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>
- Add additional comments for reducer functions.
- Add comments for CacheNode
## 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)
