When you edit your code, and Next.js is compiling the application, a compilation indicator appears in the bottom right corner of the page.
In some cases this indicator can be misplaced on the page, for example, when conflicting with a chat launcher. To change its position, open `next.config.js` and set the `buildActivityPosition` in the `devIndicators` object to `bottom-right` (default), `bottom-left`, `top-right` or `top-left`.
I also added the documentation for both `devIndicators.buildActivity` & the new `devIndicators.buildActivityPosition`.
## Feature
- [x] Implements a new feature
- [x] Documentation added
Some users reported false hits when using complex loaders that implement Art Direction.
We can relax the warnings so that query string params named width should not warn.
When an compilation happens in the timespan between "page loaded client bundle" and "web socket got initial sync event" it didn't apply the hmr update.
## 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`
* Add experimental config for middleware
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Steven <steven@ceriously.com>
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] 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 PR adds support for [Middleware as per RFC ](https://github.com/vercel/next.js/discussions/29750).
## 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
As a follow up to #30041 which changed `<div>` to `<span>`, this PR makes sure that unexpected styles are not applied to the image wrapper or sizer spans.
For example: `.content span {}` would apply to all spans and incorrectly style the image wrapper.
This PR adds [`all: initial`](https://developer.mozilla.org/en-US/docs/Web/CSS/all) to effectively reset the span styles.
This replaces the server-sent events HMR connection with a WebSocket connection to prevent hitting browser connection limits, allow sending events back from the browser, and overall better performance.
This approach sets up the the `upgrade` event listener on the server immediately when created via `next dev` and on the first request using `req.socket.server` when created via a custom server. In a follow-up PR we can push the files changed via the WebSocket as well.
x-ref: https://github.com/vercel/next.js/issues/10061
x-ref: https://github.com/vercel/next.js/issues/8064
x-ref: https://github.com/vercel/next.js/issues/4495
## 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
In some cases, e. g. when introducing a build error and then returning to the successful build again, the build error modal stays open. That shouldn't happen
### Experimental
Introduce `next/vitals` and `useExperimentalWebVitalsReport` API which is not limited by `_app`.
`pages/index.js`
```jsx
import { useExperimentalWebVitalsReport } from 'next/vitals'
export default function Index() {
useExperimentalWebVitalsReport((metric) => {
// handle metric...
})
return 'sup'
}
```
See https://github.com/w3c/csswg-drafts/issues/6501 to see how I found this.
This line doesn't recompute layout in browsers, because `"height"` is given as a pseudo-element name rather than a property.
The right way to do what it wants is `getComputedStyle(document.body).height`, but given nobody noticed this (and this is generally never needed, manually triggering layout should never be needed to avoid FOUC) it seems better to keep current behavior and just remove the call.
This PR proposes a fix for https://github.com/vercel/next.js/issues/11107 (JS modules are loaded twice). A more detailed explanation of the investigation that led to this PR can be found in the issue's comments (https://github.com/vercel/next.js/issues/11107#issuecomment-791780168).
## Replicability
To identify that the issue replicates on any given project, you need to
1. look at the network tab (first/clean load of site, so preferably ⌘+⇧+R on an incognito tab),
2. sort by "name", and filter requests by `mime-type:application/javascript` (selecting "JS" in the devtools filters will actually show all "script" types, but ignore all "javascript" types)
3. look for pairs of identical calls with one originating from initial HTML (`preload` of priority "high" originating from "(index)" or "([page name])") and another one from a script (`prefetch` of priority "lowest" originating from a .js file), where neither of the files is served from the cache.
Here's a screenshot of an example of what to look for:
<img width="601" alt="Screen Shot 2021-03-07 at 09 59 18" src="https://user-images.githubusercontent.com/1325721/110234627-cf1c6d00-7f2b-11eb-9cd7-749bf881ba56.png">
The issue was reproduced easily on the following projects:
- On [nextjs.org](https://nextjs.org/) where duplicates add up to ~70kB of transferred javascript out of 470kB (14.9%).
- On [vercel.com](https://vercel.com/) where duplicates add up to ~105kB of transferred javascript out of 557kB (18.8%).
- On [tiktok.com](https://tiktok.com/en) where duplicates add up to ~514kB of transferred javascript out of 1556kB (33%).
- In my own project using `"next": "^10.0.1"` (private repo) where duplicates add up to about 5% of total transferred javascript.
- In the issue's comments, a developer reported a replication using `"^10.0.7"` on a [public repo](https://github.com/SidOfc/sidneyliebrand.io).
## Some information about the fix
- Both `preload` and `prefetch` values for `<link rel="x">` behave similarly, with the difference being in network priority level (preload is high priority, prefetch is lowest priority).
- Next.js uses `<link rel="preload">` in its initial HTML but then *only* uses `<link rel="prefetch">` for the rest of the lifetime of the page.
- However, when Next.js detects that a script should be requested in advance, it only checks for matching `<link rel="prefetch">` and not `<link rel="preload">` (which have higher priority and are present earlier in the DOM, thus have a greater likelihood of being already loaded).
This PR aims to fix that oversight.
## Potential issues (none AFAIK)
As far as I can tell by looking through the codebase, **there is no downside** not to add a `prefetch` when a `preload` is already in the DOM. No other script looks for a `<link>` based on its `rel` attribute.
* Remove inert font tag in font optimization
* Fix lint
* Remove inert font tag during font optimization
* Fix lint
* Fix lint
* Fix lint
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This applies the fix from the awesome investigation done in https://github.com/vercel/next.js/issues/28797 by @jayphelps and adds a test to ensure this is working as expected. It seems that the `route-loader` has a race condition while prefetching and if a script is executed before we have created a current "future" entry to resolve the entry stays in a pending state causing routes to hang so this handles the condition by ensuring pending/errored entries do not stay around.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/28797
Fixes: https://github.com/vercel/next.js/issues/27783
This type was added in PR #28269 but doesn't need to be public and was causing conflicts with `@types/react@17`.
We currently use `@types/react@16` so ideally we should upgrade to `@types/react@17` and then remove the `ts-ignore`.
Fixes#28647
This PR does a few things:
- Moves `<noscript>` usage below the blur image since so that the `<noscript>` image renders on top of the blur image
- Remove the `isVisible` check for `<noscript>` since we can't rely on client-side JS
- Add `loading=lazy` to the `<noscript>` image to take advantage of native lazy loading (can't rely on JS lazy loading)
Fixes#28251
Removes the extra webpack handling that was previously done, this ensures the file which is already minified and compiled does not get passed through minification again.
Largely based on #21418Closes#21418
The polyfill loading already has tests so no other changes are necessary.
## 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
This PR resurrects #23622 which has not been updated in a while. Makes the `Image` component handle `blob:` object urls.
closes#23622fixes#19291
credits: @sdn90
## 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
This PR adds a single data attribute to the image element generated by the image component `data-nimg`) which just serves to signal that this image element is from the component. Currently it's hard to quickly/programmatically determine with certainty whether an image is from the component or not, so this change should make it easier for us to diagnose and improve performance issues related to the image component.
Replaces Babel with SWC for Next.js core client-side files.
## 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
We've never supported the `style` prop as seen in the docs https://nextjs.org/docs/api-reference/next/image#other-props
TS users already get a build error but JS users were left in the dark.
This PR adds a warning so its clear during `next dev`.
The fix in PR #25749 only works some of the time. The reason why it
doesn't work all of the time is because the `devBuildResolve` function
is called when the assets have been built, but this can happen before
the `getFilesForRoute` promise chain has completed, and thus the
`cancelled` variable could not yet have been updated.
To fix this we wait for the `getFilesForRoute` promise chain to be
fulfilled and then resolve the `devBuildPromise` promise afterwards.
This allows the `getFilesForRoute` promise chain to be fulfilled before
and the `cancelled` variable can be updated accordingly.
If an error is thrown somewhere in the `getFilesForRoute` promise chain,
i.e. due to a failed fetch request, then that will also resolve the
`devBuildPromise` and the error will bubble up to ultimately become a
`routeChangeError` which will reload the page.
With this fix the need to listen for HMR events has become obsolete as
regardless of when the HMR build/sync events complete we still want to
ensure that the `getFilesForRoute` promise chain has been fulfilled
before resolving the `devBuildPromise`.
Co-authored-by: Tobias Järvelöv <tobias.jarvelov@oderland.se>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR adds `lazyBoundary` prop on Image Component.
This feature is to load the images earlier.
I'm not good at English. So, I couldn't explain enough in the documentation what `lazyBoundary` is.
Feature request: https://github.com/vercel/next.js/discussions/24552
## 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.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes
We shouldn't be setting `placeholder=blur` styles when JS is disabled because we'll have no way to know when the image is loaded and it will be stuck in blur permanently as mentioned in [this comment](https://github.com/vercel/next.js/pull/19052#issuecomment-882886068).
This PR avoids blur styles on the `<noscript>` version of the image.
Fixes inline scripts being duplicated when used with `next/script` component
## Bug
- [x] fixes#26860
- [x] Integration tests added
## Documentation / Examples
Updated docs to indicate that `id` is needed for inline scripts
- Use SWC to compile Next.js core server files
- Ensure only @babel/runtime/helpers/interopRequireDefault helper is used
Just an initial comparison to compare size difference of this change.
## 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
* Prevent timeout when loading routes in development
The new route loader (https://github.com/vercel/next.js/pull/19006) will timeout
loading routes after 3.8s (MS_MAX_IDLE_DELAY), but this can easily happen when
running dev on a large app.
Fixes https://github.com/vercel/next.js/issues/25675
* Delay route loading timeout in development
* refactor: Integrate onBuildCallback into resolvePromiseWithTimeout
* refactor: Tweak for better dead-code elimination
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Send can result in `false` when it did not send the result so we have to fall back in that case. Shared by @timer after my PR was landed.
## 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
Also ensures that even if the navigator.sendBeacon fails the fetch fallback is used.
Fixes#23856. This is likely, as no reproduction was provided it was not possible to verify if it actually fixes the issue.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
Since we are no longer accepting new built-in loaders, users may wish to use a different cloud provider.
So this PR renames `dangerously-unoptimized` to `custom` to handle this case as well as the intention of `next export`.
If the user doesn't add a `loader` prop, we throw an error.
If the user adds a `loader` prop but it doesn't return the width, we print a warning.
- Follow up to #26847
- Fixes#21079
- Fixes#19612
- Related to #26850
### Description
This changes the strict TS types to a looser implementation such that the user can pass `src` without TS errors.
### Pros vs Cons
- **Pros**: better support for wrapping `next/image` so that TS won't report false errors
- **Cons**: using `src: string` without `blurDataURL` will no longer show TS errors and instead fail with a runtime error
### Issues
- Fixes#26892
- Related to #26991
### Description
This changes the strict TS types to a looser implementation such that the user can always pass `width` and `height` (even when `layout=fill`) without TS errors.
### Pros vs Cons
- **Pros**: better support for wrapping `next/image` so that TS won't report false errors with `layout=fill`
- **Cons**: omitting width/height when using other `layout` will no longer show TS errors and instead fail with a runtime error
### Issues
- Fixes#26531
- Fixes#25440
fixes#19074
This change disables image lazy-loading when both of the following are true:
1) A image is being rendered following a client-side page transition
2) The image has been previously loaded during this session.
Before this change, all images with lazy-loading enabled have a visible flicker during client-side page transitions, even though they're already loaded.
With this change, there's are two performance risks:
1) There's a chance that some offscreen images will have lazy-loading disabled unnecessarily because they were previously loaded. I think the performance hit here is pretty negligible and the situation is unlikely to come up very often.
2) There's a chance a different-sized version of the image will be selected by the browser, but lazy-loading will be disabled anyway. This seems even more unlikely to me, and anyway the performance hit from a stray un-lazy-loaded image (on a client-side transition) is very minor.
In both cases, I think the performance risk is outweighed by the UX improvement of getting rid of the image flicker on page transition.
This will ensure `next/script` follows the same naming convention as `next/image`. For example:
```js
import Image, { ImageProps } from 'next/image'
import Script, { ScriptProps } from 'next/script'
```
Fixes#26290
If the `Image` src url had existing query params, the imgix loader would simply append another query string with `?` causing both query strings to break.
This PR adds a way to safely merge query strings if needed using [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams).
## Bug
- [X] fixes#26288
- [X] Integration tests added
This adds a new prop, `onLoadingComplete()`, to handle the most common use case of `ref`.
I also added docs and a warning when using `ref` so we recommend the new prop instead.
- Fixes#18398
- Fixes#22482
* fix: react 18 new hydration API
* support react 18
* compat latest react only, fix resolved version
* fix tests
* Some changes based on https://github.com/reactwg/react-18/discussions/5
* fix test
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This strongly types `Router.events.on` and `Router.events.off`. Previously the event type was `string` but now it's `'routeChangeStart' | 'beforeHistoryChange' | 'routeChangeComplete' | 'routeChangeError' | 'hashChangeStart' | 'hashChangeComplete'`
## Bug
- ~[ ] Related issues linked using `fixes #number`~
- [x] Integration tests added
Closes#25679Closes#23753Closes#15497
Updates the hotUpdateChunk to include `[runtime]` for web workers support.
Fixes#26152Fixes#19865Fixes#26144
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
## Bug
- [x] Related issues linked using `fixes #26135 `
- [x] Integration tests added
fixes#26135
## 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 #26135 `
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
In the `noscript` img version the correct `src` and `sizes` attributes are overwritten by not necessary inline declaration; in particular using the loaders the `src` attribute not take the right absolute path. I found this issue using a custom loader and because my site didn't indexing any images on the Google image search.
Fixes#24277
Previously, we had an arbitrary delay of 1500ms but instead we can wait until decoding is complete.
Co-authored-by: Kristóf Poduszló <kripod@protonmail.com>
There are strict conditions for using `placeholder=blur` documented in #25949 but this will give the user a better understanding during `next dev` and links to the error.
- Error when `placeholder=blur` and no `blurDataURL`
- The Error for small images with `placeholder=blur` has been changed to a warning
- Added support for blurring a webp image
- Added error page linking to relevant docs
* Add delay to placeholder removal
* Increase jest timeout for image tests
* Use check instead of immediately expecting the result
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Previously we were accepting a `s=1` query string parameter for static imports, but this is not necessary.
Instead, this PR looks at the file path to determine if the header should be `immutable`.
The nice thing here is we don't need to worry about someone trying `s=1` with an external image or 3rd party loader. In that case, we use the upstream `Cache-Control` header as usual.
This change also ensures we don't add the `immutable` header for `next dev`.
Related to PR #24993
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
fixes [#21606](https://github.com/vercel/next.js/issues/21606)
### Description
When using shallow routing and wanting to scroll to top by setting the `scroll` option to `true` it didn't work. This PR fixes this issue.
If you give a Static Image to the Image component, TypeScript will throw a type error. This Pull Request fixes it.
## Bug
- ~~Related issues linked using `fixes #number`~~
- [x] Integration tests added
## ~~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.~~
## ~~Documentation / Examples~~
- ~~Make sure the linting passes~~
---
follow-up #24993
cc @atcastle
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* Remove deprecated features
In the next major version we'll want to merge this PR that removes some of the long-time deprecated features, it'll have a positive effect on bundle size.
* Update tests
* Update tests
* Change unsized to layout=fill in test
* Update sizes
* Update rotation test
* Update size limit test
* Update test
* Update test
* Update test
Makes sure a helpful error is shown for `<Link>` with multiple children
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
### move all access to built pages into worker pool
to allow parallelizing and avoid loading the bundles in the main thread
This improves performance of the static check step a bit and helps reducing memory load in main thread
### enable splitChunks for server build in webpack 5
This improves performance for static generation by loading less code due to reduced duplication
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
This is the image component implementation of the blurry placeholder as described in #24004. The matching server side implementation is currently planned.
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issue #18858
- [x] Integration tests added
(Documentation and telemetry to follow after server side is implemented)
When using `sizes`, [`matchAll`](https://caniuse.com/mdn-javascript_builtins_string_matchall) isn't supported by older browsers like IE and Safari 12. This PR changes it to `exec`.
There're already tests of `sizes` with multiple `vw` values covered.
Fixes#23677.
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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 `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
This ensures when CSS requests stall that they are included in the route load timeout so that stalled CSS requests don't block us from falling back to a hard navigation. This handles a rare case noticed by @pacocoursey where a transition did not complete while attempting to load CSS assets.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
Previously, we weren't recording most (all?) of the Next.js measurements like `Next.js-hydration` in Concurrent Mode. This was mainly because the new API doesn't accept a callback.
Instead of special casing this, I've refactored it so that the measurements are just recorded when Root first flushes (via `useLayoutEffect`), which should be more or less the same timing for the old API.
Concurrent Mode is a little trickier for two reasons:
1. Flushes might be (slightly) delayed due to time-slicing and prioritization
2. Selective hydration might skew measurements in cases where full hydration is aborted
I don't have a good answer for those yet, so they'll need to be addressed when the time comes.
Just cleans up some code, doesn't change the underlying mechanism
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
This adds support for returning an object from `rewrites` in `next.config.js` with `beforeFiles`, `afterFiles`, and `fallback` to allow specifying rewrites at different stages of routing. The existing support for returning an array for rewrites is still supported and behaves the same way. The documentation has been updated to include information on these new stages that can be rewritten and removes the outdated note of rewrites not being able to override pages.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
This is a follow-up PR of #19052, where `visibility: inherit` was mistakenly added back. It was removed in #23278.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
The current `<Image />` component does not fallback gracefully when JavaScript is disabled in the client / browser.
You can test this with the [official Next/Image example](https://csb-4k0kr-p8ya8f304.vercel.app/), by disabling JavaScript in the browser's DevTools. Video demo: https://streamable.com/frkvw9
This PR aims to fix this behaviour by using `<noscript></noscript>` tags to conditionally display a standard `<img>` element using the `props` passed to `<Image />` when JavaScript is disabled.
For browser sessions where JavaScript is enabled, this will not cause an increase in network requests, so there should be no downside.
One area where this PR is a bit "hacky" is that it uses a negative `margin-top` to counteract `sizerStyle.paddingTop`. From what I can tell, `sizerStyle.paddingTop` is generated on the server side, where we can not know ahead of time whether JavaScript is enabled in the browser - hence why I've opted for this solution.
Fixes#19223Fixes#21214
This PR removes the `visibility` style property change from next/image. It was previously added in #18195 to fix a bug that when no `src` is set, and that bug is not valid anymore as all images will always have `src` (and a fallback too).
It also fixes the problem that screen readers ignore elements with `visibility: hidden`.
Fixes#23201.
## Bug
- [x] Related issues #23201
- [ ] Integration tests added
## 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.
## Documentation / Examples
- [ ] Make sure the linting passes
# Route Announcements
## Summary
This PR improves the accessibility of NextJS's client-side navigation by announcing route changes to screen readers.
## Context
When a user who is sighted clicks on a link, they can see the content change. It's an affirmation that what the user intended to do by clicking a link actually worked! Users navigating the page via a screen-reader will not get this feedback on NextJS sites (This is an issue on many SPA-like architectures).
https://user-images.githubusercontent.com/4213649/103017382-63b02b00-44f8-11eb-9940-fb530d2d3018.mov
## Solution
Whenever there is a route change, the new `<RouteAnnouncer />` will look for a name to give the new page and then announce it! The name is found by first looking for an `h1`, falling back to `document.title`, and lastly to `pathname`. `<RouteAnnouncer />` is a visually hidden component placed within the `<AppContainer />`.
## Demo
https://user-images.githubusercontent.com/4213649/103017401-6ad73900-44f8-11eb-8050-b3e9a7e0c3f2.mov
## Inspiration
First and foremost, this PR was inspired by @marcysutton's studies and writing, [What we learned from user testing of accessible client-side routing techniques with Fable Tech Labs
](https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/) as well as @madalynrose's [Accessible Routing](https://github.com/gatsbyjs/gatsby/pull/19290) PR for Gatsby.
There were also learnings gleaned from the conversations within #7681.
### Related Issues & PRs
- Resolves#7681
- Relates to #19963
Currently if you have `sizes` set in `next/image`, the image will likely be downloaded multiple times (usually twice) on Safari (macOS and iOS): the correct size for the viewport, and the original size specified in `src`.
Also make sure you have "Ignore Resource Cache" disabled in the Safari Devtools when trying to reproduce:
The root cause is the way Safari handles `<img>`'s attribute updates. Although React updates all the attributes one by one synchronously and programmatically, Safari will still try to fetch the resource immediately and won't wait for other DOM changes to be finished.
That means if we set the following 3 attributes in this order: `src`, `srcSet`, `sizes`. Safari will fetch the image when `src` is set. And then once `srcSet` is there it will fetch the resource again based on it. And finally, when `sizes` is updated it might correct the resource URL again.
So the fix here is simple: by just reordering those to `sizes`, `srcSet`, `src`, it will only load the image with the correct size only once:
<img width="1498" alt="CleanShot 2021-03-09 at 21 05 30@2x" src="https://user-images.githubusercontent.com/3676859/110477852-a27c7700-811e-11eb-88dc-d6e7895f67bd.png">
Fixes#19478.
In the current implementation, `idleTimeout` will always be thrown even if it didn't time out and `Promise.race` was resolved. This causes the error `Error: Route did not complete loading` on every route transition and Chrome Devtools will pause code execution if you have "Pause on exceptions" enabled.
This PR adds `resolvePromiseWithTimeout` which does the same thing as `Promise.race` and `idleTimeout`, but it cancels the rejection when it resolves successfully, in which case the error won't be thrown.
Fixes#21543.
Currently, the image component doesn't handle use of the `sizes` property with `layout="fill"` and `layout="responsive"` very well for small viewports. It will never include sizes smaller than the smallest viewport (640px) in the srcset, so even if you specify `sizes="30vw"` in your image, you have to download the full-viewport-width image on small devices.
This PR adds logic such that if you use `layout="fill"` and include a `sizes` property, the image component will include the full range of image sizes in the `srcset`.
It also includes an optimization where it finds the smallest `vw` value in the sizes value and combines that with the smallest viewport width, and uses that as the floor of the srcset. It does this so it doesn't unnecessarily increase transfer size by including ALL sizes. This is still a conservative optimization--for 95% of cases, taking the _largest_ `vw` size would work, but I don't see a way to do that without breaking a few corner cases.
The case of a sizes prop with `px` values is fixed but not optimized--though generally that case is less of a good fit for the fill or responsive layout anyway.
Fixes#16864
The `router` can be missing in a test environment when trying to render a `Link` component. This PR bails out of `router.prefetch()` when `router` is missing.
The alternative is for users to mock `next/link` or to mock the `router` and wrap their test components.
Please let me know any feedback.
This is a #19325 reconfigured to support a loader passed in via a `loader` prop on the Image component, rather than using a config-based approach.
The idea is that applications wanting to use a custom loader will create a wrapper element for the image component that incorporates that loader. See a simple example of this pattern in the integration tests.
This solution is similar to the one prototyped by @ricokahler in #20213 and described at https://github.com/vercel/next.js/issues/18606#issuecomment-720149156
---
Closes#19325Fixes#18606
This pull request correctly assigns boolean attributes for `<script />` to match the element as it is created by a server-side render.
Prior to this pull request, we'd double-execute `<script>` tags with the `async`, `defer`, or `nomodule` property.
---
Fixes#9070
This PR fixes a bug where we'd accidentally pass-through the user-provided `srcSet` if the image was lazy, just to then replace it when we hydrate.
---
Fixes#19041
This pull request adjusts our experimental scroll restoration behavior to use `sessionStorage` as opposed to `History#replaceState` to track scroll position.
In addition, **it eliminates a scroll event listener** and only captures when a `pushState` event happens (thereby leaving state that needs snapshotted).
These merely adjusts implementation detail, and is covered by existing tests:
```
test/integration/scroll-back-restoration/
```
---
Fixes#16690Fixes#17073Fixes#20486
This ensures we render the locale domain on the `href` when using `next/link` previously the provided `href` was stilling being rendered which differed from the resulting `href` that was navigated to.
Fixes: https://github.com/vercel/next.js/issues/20612
This pull request adds an `elements.delete` operation to the `useIntersection`'s cleanup function: `unobserve`.
Without this delete operation, next.js holds onto an unreachable reference of every observed element indefinitely (automatically every Link and Image is observed, so that means every rendered Link and Image element adds to the leak). I found this memory leak when building out an infinite feed in next.js with thousands of Link elements.
The final code block of the `unobserve` function body:
```tsx
// Destroy observer when there's nothing left to watch:
if (elements.size === 0) {
observer.disconnect()
observers.delete(id)
}
```
Is effectively unreachable without this delete operation, as the `elements` map will never decrease in size as it is currently. This means that there will always be at least one IntersectionObserver instance in memory if useIntersection has been used once, regardless of if there are currently any components still using the hook.
This ensures we detect domain specific locales and redirect them client-side. Tests have been added in the `i18n` suite to ensure the domain redirect is applied correctly during a client-side navigation
Fixes: https://github.com/vercel/next.js/issues/19174
This moves the scroll reset behavior to happen synchronously with the DOM commit, instead of a few ticks after the render completes.
This is necessary for components that read scroll state on mount.
---
Fixes#6462
This fixes `next/image` to properly ignore inherited styles applied to the `img` tag by a parent element.
Image styling should **always** be done by a wrapper element—not to the image itself!
---
Fixes#19817Fixes#19964
This removes `import type` usage from our core files since `import type` requires a higher TypeScript version than currently expected.
Fixes: https://github.com/vercel/next.js/issues/19300
Currently if sizes is not defined, Next.js is setting sizes as:
```
(max-width: 640px) 640px, (max-width: 750px) 750px, (max-width: 828px) 828px, (max-width: 1080px) 1080px, (max-width: 1200px) 1200px, (max-width: 1920px) 1920px, (max-width: 2048px) 2048px, 3840px'
```
This pull request will make sizes be `100vw` by default, which will allow us to download "smaller" images than what's currently happening.
In a demo app I have, the difference is between downloading 488KB vs 1.4MB (in images)
This makes sure SSG data is correctly prefetched for the default locale and other locales on the same page. Tests for this behavior have been added for catch-all and normal pages.
Closes: https://github.com/vercel/next.js/issues/19048
Fixes#18720
This removes image preloading. It doesn't work correctly on any browser other than Chrome (with Chrome's real engine). On all other browsers, it triggers 2x the bytes to be downloaded. The tradeoff isn't worth it here IMO.
Chrome itself should be smart enough to bump an `<img />` tag's priority over other preloads that are script type during the preparse phase.
We can reintroduce this when we don't hurt non-Chrome users.
This fixes a few things related to optional catch-all routes and i18n. The first thing is it ensures the correct data route is generated on the client so that the locale isn't duplicated for an optional catch-all route, the next is it ensures the browser history is updated correctly when only a locale change is occurring, and then it also ensures we handle the locales and normalizing for fallback optional catch-all pages correctly.
Tests have been added to ensure these cases are covered properly and we don't regress on them, these changes were also tested on Vercel [here](https://next-js-bug-i18n-root-params-nybg44l0b.vercel.app/)
Fixes: https://github.com/vercel/next.js/issues/18633
Fixes: https://github.com/vercel/next.js/issues/19059
This pull request completely replaces our old page loader with a brand new route loader.
Our existing comprehensive test suite means I did not need to add a bunch of tests. I did add them where behavior was added or fixed.
Summary of the changes:
- Eagerly evaluates prefetched pages in browser idle time (speeds up transitions)
- Router is **no longer frozen** indefinitely if the Build Manifest never arrives
- Router is **no longer frozen** indefinitely if a page fails to bootstrap
- New `withFuture` utility instead of ad-hoc deduping per resource
- Prefetching is now delayed until browser idle time to not impact TTI
- Browsers without `prefetch` now fall back to eager evaluation instead of using `preload`
- We're now ready to serve non-static assets **with `no-store` without breaking prefetching**
- **Application can now hydrate without fetching CSS assets—this is a huge performance win that was previously blocking hydration**
---
The minor size increase here is unfortunate, but we have to incur it for correctness.
---
Fixes#18389Fixes#18642
This PR fixes two bugs causing HTML validators to complain.
- Error: Bad value data:image/svg+xml;charset=utf-8, for attribute src on element img: Illegal character in scheme data: < is not allowed.
- Fixed by using base64 for svg during `layout=intrinsic` to avoid angle brackets
- Error: Element img is missing required attribute src.
- Fixed by using base64 transparent gif for `loading=lazy` placeholder
Fixes#18850
This pull request fixes `<Image />` not updating when new props are passed by removing external DOM mutations and relying on React to do it instead.
As an added bonus, I've extracted the intersection observer from both the `<Image />` and `<Link />` component, as their instance can be shared!
The increase in size is minor (+3B), and actually a decrease for apps using both `<Image />` and `<Link />`.
---
Fixes#18698Fixes#18369
While we were fixing how Next.js handled CSS, we added a complex prefetch, preload, fetch sequence to acquire the CSS asset.
This unnecessarily overcomplicated what could've been only a `fetch()` from the very start!
---
Fixes#16932
This pull request speeds up Next.js' rendering pipeline by fetching data, parsing it, and loading it into memory instead of only doing the network request.
This will mainly result in improved Firefox/Safari performance since they handled prefetch incorrectly—only Chrome did it right. This also gets us closer to being able to use `no-store` in our caching headers!
---
Fixes#18639
x-ref #18802
This adds ncc inlining optimizations for the following dependencies:
* cacache
* schema-utils
* find-cache-dir
* mkdirp
* neo-async
* web-vitals
The slight increase in output in the reports here is due to the variation of the bundled version of web-vitals.
In addition, this moves ast-types to be a devDependencies entry instead of in dependencies as it was before https://github.com/vercel/next.js/pull/14746 as I could not see any production usage (ping @prateekbh). Happy to separate that out into a separate PR if preferred too.
This PR prints a pretty error when the Image `src` property is a [protocol-relative URL](https://www.paulirish.com/2010/the-protocol-relative-url/).
> Update 2014.12.17:
> Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.
Fixes#18536
Next.js would try to "recover" if its CSS assets went missing (i.e. a deployment occured) **while the page was initially loading**.
This handled a rare case where we'd try to let the Next.js complete hydrating even though a deployment occured.
However, in practice, this never worked: if the `fetch()` failed, that means the original assets never downloaded themselves (because the `fetch()` should be coming from disk cache).
Instead of letting Next.js get itself into a weird state, let's just stop hydration so that the page doesn't accidentally delete its styles.
The handle-no-styles behavior is already tested in `test/integration/css/test/index.test.js`. There was never a branch for it using its cached styles, so nothing else needs updated.
---
Fixes#17930
When visiting a non-locale prefixed path (`/hello` instead of `/fr/hello`) we don't trigger locale redirects currently so if another locale is matched we need to ensure this is reset to the `defaultLocale` for rendering to prevent a mis-match on the client and the server.
This also fixes hydration errors from occurring with `asPath` for `getServerSideProps` pages due to `normalizeLocalePath` expecting only a pathname and `asPath` containing `hash` and `query values also.
Fixes: https://github.com/vercel/next.js/issues/18337
Fixes: https://github.com/vercel/next.js/issues/18510
This PR deprecates the `unsized` property from NextImage because the property did not accomplish the desired effect.
Users should rely on one of the new layouts instead:
- `<Image layout="fixed" />`
- `<Image layout="intrinsic" />`
- `<Image layout="responsive" />`
- `<Image layout="fill" />`
The `unsized` property will continue to work as-is in production but is deprecated and will throw in dev.
---
### TODO:
- [x] test `layout=fill` in typescript types
- [x] test `layout=fill` render behavior
- [x] test that `unsized` switches to `layout=fill`
- [x] test `next dev` erroring on `unsized`
- [ ] layout docs (tracked in issue #18554)
- [ ] both `layout=fill` and `layout=responsive` use all deviceWidths in the srcset
---
Fixes#18541
Co-authored-by: Steven <steven@ceriously.com>
This PR introduces a new `layout` property.
This allows 3 possible values (`fixed`, `intrinsic`, or `responsive`) which solve many use cases we have seen since 10.0.0 and will hopefully avoid usage of `unsized`.
Fixes#18351
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Add err.sh for missing images domain
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* Update test
Co-authored-by: Steven <steven@ceriously.com>
This does two things:
- Rename `iconSizes` to `imageSizes`.
- Give priority to `imageSizes` regardless of `deviceSizes` as a means to opt-out of the srcset behavior.
This separates the `next.config.js` property `images.sizes` into to properties: `images.deviceSizes` and `images.iconSizes`.
The purpose is for images that are not intended to take up the majority of the viewport.
Related to #18122
There was a bug when the user defines a width on the Image component, but a larger size image is requested.
This is because the browser uses the `srcset` to decide which image size to request and we had the srcset basically hardcoded.
This PR fixes the behavior so that the `srcset` will never be larger than the `width` defined on the component.
It also fixes a bug where the preload srcset did not match the img srcset.
- Related to #18147
- Related to #18122
For many users refactoring from `<img>` to `<Image>`, we can often support their properties as-is.
The exception was width/height.
This PR allows the `<Image>` component to accept strings for `width` and `height` just like `<img>`.
Related to #18122
This PR updates the `<Image>` component to follow the same property naming as native `<img>`.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-loading
This currently allows two values,`loading=lazy` and `loading=eager`, but there might be new values added in a future spec.
cc @atcastle
This makes sure that we detect the correct default locale for domain specific locales since a domain can have a different default locale residing at the root and we need to check this on the client for prerendered/auto-static pages. This also makes sure we disable the built-in redirect handling when on Vercel since it's handled already.
Tests for this are tricky since we need to load the browser with a custom domain which requires editing the host file. Existing tests should ensure this doesn't break non-domain specific locale behavior though. This was also tested manually while testing https://github.com/vercel/vercel/pull/5298
x-ref: https://github.com/vercel/next.js/pull/17370
This PR adjust the Web Vitals reporting to be called *after* rendering occurs. It used to work like this, but React's render method is no longer synchronous—so we have to do it in an effect.
Existing tests should cover this code path, and IMO it's unfeasible to test that it's invoked _after_ hydration.
Also removed the `&& ST` condition which is not relevant to Web Vitals.
This adds the `locale` prop for `next/link` to allow transitioning between locales client-side and also allows passing the locale to `router.push/replace` via the transition options similar to `shallow` e.g. `router.push('/another', '/another, { locale: 'nl' })`
x-ref: https://github.com/vercel/next.js/pull/17370
While working on https://github.com/vercel/next.js/pull/17755 noticed a couple of cases that needed fixing and broke them out to this PR to make that one easier to review. One fix is for `ssgCacheKey` where it wasn't having the `locale` prefix stripped correctly due to the locales no longer being populated under the server instances `renderOpts` and the second fix is for the `asPath` not being set to `/` when the `locale` is the only part in the URL e.g. `/en` became an empty string `""`
x-ref: https://github.com/vercel/next.js/pull/17370
Follow-up to https://github.com/vercel/next.js/pull/17370 this adds mapping of locales to domains and handles default locales for specific domains also allowing specifying which locales can be visited for each domain.
This PR also updates to output all statically generated pages under the locale prefix to make it easier to locate/lookup and to not redirect to the default locale prefixed path when no `accept-language` header is provided.
Follow-up PR to https://github.com/vercel/next.js/pull/17370 when the path is not prefixed with a locale and the default locale is the detected locale it doesn't redirect to locale prefixed variant. If the default locale path is visited and the default locale is visited this also redirects to the root removing the un-necessary locale in the URL.
This also exposes the `defaultLocale` on the router since the RFC mentions `Setting a defaultLocale is required in every i18n library so it'd be useful for Next.js to provide it to the application.` although doesn't explicitly spec where we want to expose it. If we want to expose it differently this can be updated.
This adds the initial changes outlined in the [i18n routing RFC](https://github.com/vercel/next.js/discussions/17078). This currently treats the locale prefix on routes similar to how the basePath is treated in that the config doesn't require any changes to your pages directory and is automatically stripped/added based on the detected locale that should be used.
Currently redirecting occurs on the `/` route if a locale is detected regardless of if an optional catch-all route would match the `/` route or not we may want to investigate whether we want to disable this redirection automatically if an `/index.js` file isn't present at root of the pages directory.
TODO:
- [x] ensure locale detection/populating works in serverless mode correctly
- [x] add tests for locale handling in different modes, fallback/getStaticProps/getServerSideProps
To be continued in fall-up PRs
- [ ] add tests for revalidate, auto-export, basePath + i18n
- [ ] add mapping of domains with locales
- [ ] investigate detecting locale against non-index routes and populating the locale in a cookie
x-ref: https://github.com/vercel/next.js/issues/17110
Removes `next-head-count`, improving support for 3rd party libraries that insert or append new elements to `<head>`.
---
This is more or less what a solution with a `data-` attribute would look like, except that instead of directly searching for elements with that attribute, we serialize the elements expected in `<head>` and then find them/assume ownership of them during initialization (in a manner similar to React's reconciliation) based on their properties.
There are two main assumptions here:
1. Content is served with compression, so duplicate serialization of e.g. inline script or style tags doesn't have a meaningful impact. Storing a hash would be a potential optimization.
2. 3rd party libraries primarily only insert new, unique elements to head. Libraries trying to actively manage elements that overlap with those that Next.js claims ownership of will still be unsupported.
The reason for this roundabout approach is that I'd really like to avoid `data-` if possible, for maximum compatibility. Implicitly adding an attribute could be a breaking change for some class of tools or crawlers and makes it otherwise impossible to insert raw HTML into `<head>`. Adding an unexpected attribute is why the original `class="next-head"` approach was problematic in the first place!
That said, while I don't expect this to be more problematic than `next-head-count` (anything that would break in this new model also should have broken in the old model), if that does end up being the case, it might make sense to just bite the bullet.
Fixes#11012Closes#16707
---
cc @Timer @timneutkens
This adds initial support for reloading the page when `getStaticProps`, `getStaticPaths`, or `getServerSideProps` were changed for a page by triggering a reload when the server output for a page has changed but the client output has not since these methods aren't included in the client output.
Closes: https://github.com/vercel/next.js/issues/13949
This pull request replaces our client-side style transitions with `<style>` tags over async `<link rel=stylesheet>` tags. This should fix some edge cases users see with Chrome accidentally causing a FOUC.
This also removes the need to perform an async operation before starting the render, which should remove any perceivable navigation delay.
---
Fixes#16289
This pull request reuses existing `<link rel=stylesheet>` tags if their `href` matches instead of recreating it. This is in effort to fix an edge case where the browser will FOUC on the tag swap.
This behavior should be sufficiently covered by all the existing CSS cases, as misbehavior would result in the resulting CSS styles being incorrect.
This pull request correctly tracks render cancelation behavior. Prior to this PR, we'd have an unhandled rejection that left the app in a bad state and no routeChangeError event was fired.
---
Closes#16424Fixes#16445
Prior to this PR, `loadPage` would call `loadScript` which would then report if the script failed to load.
This was problematic because `loadScript` notified a failure to load via `pageRegisterEvents`, which would not set the `pageCache` value for future requests.
This means a one-off promise rejection would happen, [in lieu of being] typically consumed within the client-side router, causing a server-side reload.
However, when `loadPage` was used independently (i.e. to preload pages), this promise rejection would be ignored as a preload failure.
When the real routing request comes in, the `loadPage` function skips its attempt to load the `<script>` because it was already in the DOM, and the router would stop functioning.
---
To fix this behavior, I've removed erroneous emits on `pageRegisterEvents` to only happen during the page registration lifecycle (its intended use).
The new behavior is that `loadScript` returns a `Promise` that `loadPage` can track, and if any of the page(s) scripts fail to load, we mark the entire page as errored in `pageCache`. This ensures future requests to `loadPage` will always immediately reject with a `PAGE_LOAD_ERROR`, which causes the server-side redirect at the appropriate point.
---
Fixes#16333
This fixes an edge case where every dozen or so transitions you'll see a flash depending on what's happening on the main thread at the time.
I'm not sure it's possible to test for this case, so we'll just have to do more field testing with this.
This PR replaces `prop-types-exact` (only used in this location) with manual property checking.
Right now, malformed properties sent to `<Link>` are silently handled and only emit a warning in the console.
This leads to confusing/unexpected errors because we try to read a value that is undefined.
To fix this, we'll now throw a proper error when `<Link>` is misused. **This still isn't optimal, however, because we don't have a component stack trace we can give the user**.
We're not going to be able to give the user actionable instructions until React 16.14 at a minimum.
---
Fixes#13951Fixes#16107Closes#13962
This pull request adds a test case for the reproduction provided in #12445. This bug is specifically caused when loading the next page before navigation has actually occurred.
---
Fixes#12445
In most browsers, clicking links with the Alt key has a special behavior, for example, Chrome downloads the target resource. As with other modifier keys, the router should stop the original navigation to avoid preventing the browser’s default behavior.
When users click a link while holding the Alt key together, the browsers behave as follows.
Windows 10:
| Browser | Behavior |
|:-----------|:--------------------------------------------|
| Chrome 84 | Download the target resource |
| Firefox 79 | Prevent navigation and therefore do nothing |
| Edge 84 | Download the target resource |
| IE 11 | No impact |
macOS Catalina:
| Browser | Behavior |
|:-----------|:--------------------------------------------|
| Chrome 84 | Download the target resource |
| Firefox 79 | Prevent navigation and therefore do nothing |
| Safari 13 | Download the target resource |
In terms of url rewriting, `trailingSlash` supports everything `exportTrailingSlash` does. We can just share all other code paths and deprecate `exportTrailingSlash`.
This PR shows a deprecation warning when `exportTrailingSlash` is used.
Also fixes https://github.com/vercel/next.js/issues/15774
We can update the tests now or later. (I kept them the same to prove it's non-breaking)
To do:
- [x] Do we want to keep this? => nope 841d4efc51/packages/next/next-server/lib/router/router.ts (L329)
- [x] I kept `exportTrailingSlash` here. Do we want to rename that as well? => nope 2d9d649d49/packages/next/build/index.ts (L959)
`pageProps` should always be defined to ensure everything is working as expected although to prevent a breaking change this adds an additional check before attempting to access `pageProps` before hydration. It also adds tests to prevent regressing on this
Closes: https://github.com/vercel/next.js/issues/15647
Replace `url.parse` and `url.resolve` logic with whatwg `URL`, Bring in a customized `format` function to handle the node url objects that can be passed to router methods. This eliminates the need for `url` (and thus `native-url`) in core. Looks like it shaves off about 2.5Kb, according to the `size-limits` integration tests.
Currently following links are broken when using `basePath`:
```jsx
// pages/hello.js
<Link href="#hashlink">
<a id="hashlink">Hash Link</a>
</Link>
```
with `basePath: '/docs'`, this will navigate to `/docs/docs/hello#hashlink` instead of `/docs/hello#hashlink`
I have a further optimization that builds on this branch that removes `url.parse` and `url.resolve` in favor for `new URL()` in router and link. Will PR when this gets merged.
Convert `Link` to a function component. Prefetch logic and memoized url formatting now meshes nicely with React hooks. Class methods were hoisted to module scope to preserve performance characteristics.
* avoid pulling code in the bundle for `trailingSlash` logic when it's not enabled
* avoid cloning the url an extra time if normalizing the path doesn't change it
This updates `fetchNextData` to re-use the `getDataHref` function from `page-loader` which has more verbose handling to ensure the correct `/_next/data` URL is built. Re-using this logic ensures the `/_next/data` URL can still be built even when a mismatching `href` and `as` value is provided to `next/link`.
This also fixes a case in `getDataHref` where optional values that weren't provided would fail to build the data href since the check requiring the param be present while interpolating the route values hasn't been updated to allow missing params for optional values.
An additional test case has been added to the prerender suite to ensure the `/_next/data` URL is built correctly when mismatching `href` and `as` values are provided
x-ref: https://github.com/vercel/next.js/discussions/14536
x-ref: https://github.com/vercel/next.js/discussions/9081#discussioncomment-31160
Closes: https://github.com/vercel/next.js/issues/14668
* Avoid adding basePath when it's not needed
When using the `basePath` setting, on pages with params it will fire a router change. This will pass the url pathname in the `as` param using the `getUrl()` function. This means the `as` path will be sent through already including the `basePath`, leading to `/basePath/basePath/path` which will cause the router to throw an error.
* lint
* Add test case and ensure removal
* Make sure to re-add before changeState
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Initial PR to make `next build` work with webpack 5, still needs more work to make sure runtimeChunk and such are shared between pages.
- No longer needs the custom ChunkNamesPlugin as the default behavior was changed
- Dropping AMP First client page bundles is now compatible
Noticed this while reviewing https://github.com/vercel/next.js/pull/14376. After having done https://github.com/vercel/next.js/pull/13699, this code didn't feel right to me:
```js
function prepareRoute(path: string) {
path = delBasePath(path || '')
// this /index rewrite is problematic, it makes pages/index.js
// and pages/index/index.js point to the same thing:
return toRoute(!path || path === '/' ? '/index' : path)
}
```
Added a nested index page to the prerender tests and found it was rendering the `/` route on navigation. This uncovered 2 more places around the dataroute where the index path was not translated correctly.
**edit:**
Just to note that there was nothing wrong with https://github.com/vercel/next.js/pull/14376, the issue was already there, I just noticed it while reading that PR
Saw in the client bootstrap script that the error message was printed alongside the stacktrace. This is unnecessary since the stacktrace already includes the error message. In fact, it seems like browsers already do a good job of printing an error with its stacktrace when you just print them using `console.error`. It's a bit minor, but this should shave off a few bytes of the bundle.
We previously used to remove our FOUC helper inside of the style injection to ensure content was shown as fast as possible.
This behavior, however, was problematic for a few reasons:
1. Large JavaScript chunks would take longer than an animation frame to parse, causing FOUC
1. Rendering would sometimes complete before an animation frame, causing improper effects
To fix the latter, we started removing the no FOUC helper **before** rendering, however, we never fixed the former by removing the dead code.
There's not a great way to test this because the FOUC is so fast and flaky, however, this code really shouldn't exist and isn't likely to be re-added (regress).
Also, we already have FOUC tests that occasionally flake, probably due to this.
Fixes#12448Fixes#13058Fixes#11195Fixes#10404
Updates the way filenames are generated for browser compilation.
Notably:
- All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path)
- The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals)
- All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals)
- In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals)
- Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals)
Follow up of these PRs:
https://github.com/vercel/next.js/pull/13759https://github.com/vercel/next.js/pull/13870https://github.com/vercel/next.js/pull/13937https://github.com/vercel/next.js/pull/14130https://github.com/vercel/next.js/pull/14176https://github.com/vercel/next.js/pull/14268Fixes#6303Fixes#12087Fixes#1948Fixes#4368Fixes#4255Fixes#2548
Initial work to use chunkhashes instead of buildid for the page files in production. This does not change the calculation of the filename itself initially.
As discussed, this streamlines the handling for `basePath` to not automatically strip and add the `basePath` when provided to `next/link` or `router.push/replace` and only automatically adds the `basePath` and when it is manually provided it will cause a 404 which ensures `href` still matches to the pages directory 1-to-1.
This also adds additional test cases that we discussed to ensure this behavior is working as intended
---
Fixes#13902
Disambiguate between pages/index.js and pages/index/index.js so that they resolve differently.
It all started with a bug in pagesmanifest that propagated throughout the codebase. After fixing pagesmanifest I was able to remove a few hacks here and there and more logic is shared now. especially the logic that resolves an entrypoint back into a route path. To sum up what happened:
- `getRouteFromEntrypoint` is the inverse operation of `getPageFile` that's under `pages/_document.tsx`
- `denormalizePagePath` is the inverse operation of `normalizePagePath`.
Everything is refactored in terms of these operations, that makes their behavior uniform and easier to update/patch in a central place. Before there were subtle differences between those that made `index/index.js` hard to handle.
Some potential follow up on this PR:
- [`hot-reloader`](https://github.com/vercel/next.js/pull/13699/files#diff-6161346d2c5f4b7abc87059d8768c44bR207) still has one place that does very similar behavior to `getRouteFromEntrypoint`. It can probably be rewritten in terms of `getRouteFromEntrypoint`.
- There are a few places where `denormalizePagePath(normalizePagePath(...))` is happening. This is a sign that `normalizePagePath` is doing some validation that is independent of its rewriting logic. That should probably be factored out in its own function. after that I should probably investigate whether `normalizePagePath` is even still needed at all.
- a lot of code is doing `.replace(/\\/g, '')`. If wanted, that could be replaced with `normalizePathSep`.
- It looks to me like some logic that's spread across the project can be centralized in 4 functions
- `getRouteFromEntrypoint` (part of this PR)
- its inverse `getEntrypointFromRoute` (already exists in `_document.tsx` as `getPageFile`)
- `getRouteFromPageFile`
- its inverse `getPageFileFromRoute` (already exists as `findPageFile ` in `server/lib/find-page-file.ts`)
It could be beneficial to structure the code to keep these fuctionalities close together and name them similarly.
- revise `index.amp` handling in pagesmanifest. I left it alone in this PR to keep it scoped, but it may be broken wrt nested index files as well. It might even make sense to reshape the pagesmanifest altogether to handle html/json/amp/... better
This removes remaining references to `granularChunks` in configs, error messages, and comments.
Also removed the `process.env.__NEXT_GRANULAR_CHUNKS` value.
---
Follow up to: https://github.com/vercel/next.js/pull/13663
Was going through _document and noticed some variable shadowing going on. Added a rule for it to our eslint configuration and went through all warnings with @Timer.
Next is currently removing useful information from the PnP error messages.
Before:
```
Module not found: Something that got detected as your top-level application (because it doesn't seem to belong to any package) tried to access a package that is not declared in your dependencies
```
After:
```
Module not found: Something that got detected as your top-level application (because it doesn't seem to belong to any package) tried to access a package that is not declared in your dependencies
Required package: foo (via "foo/components/Avatar")
Required by: /home/arcanis/foo/bar.tsx
```
This waits for the render to be committed to DOM before we render the route change complete event (no longer sync in new React).
We have tests that ensure this resolves.
---
Closes#12938
* Update HMR Client Runtime
* Increment event when building or different state
* Dismiss Old Type-Only Overlay
* Update packages/next/client/dev/error-overlay/hot-dev-client.js
* Add basePath in link component and add/remove it consistently
* Update to not use regex for delBasePath
* Expose addBasePath as router method
* Revert "Expose addBasePath as router method"
This reverts commit 40fed596195c6affabf837e42d472452768e13a3.
* Expose basePath as router field
* Apply suggestion
* Expose basePath as router field
* remove un-used vars
* Update externals
* Apply lint fix
* Update size-limit test
* Update prefetch
* add new types of performance monitoring
* adding LCP
* adding cls to perf relayer
* add test for cls and lcp
* nit fixes
* re-organizing code
* fixing tests for lcp
* updating size limits in test
* Remove ts-ignore where possible
And replace by typecasts
* More accurate types
* bend cliententries in a correct shape earlier on
* comment becomes unnecessary
* add webpack overload to allow for the next.js use case
* Avoid changing public interface
Co-authored-by: Joe Haddad <timer150@gmail.com>
This adds a `isFallback` property to detect if the page is being rendered in "fallback" mode or normal mode.
Accessed via the `useRouter()` hook.
---
Closes#10527
* Adjust SSG Loading Behavior
* Update expected preview behavior
* Rename two corrections
* Only use skeleton in production for now
* Fix "should SSR SPR page correctly" test
* fix tests
* fix trailing comment letter
* disable test for now
* Add initial SSG fallback handling
* Remove extra changes and update fallback handling
* Remove extra timeout for testing
* Update SSG tests in dynamic-routing suite
* Add racing to decide between rendering fallback and data
* Update size-limit test
* Update comment
* Make sure to follow correct route change order
* Make comment more verbose for racing
* Revert getStaticData to only return Promise
* Make sure to update URL on fallback
* Add retrying for data, de-dupe initial fallback request, and merge fallback replace
* Update to add preload for fallback pages data
* Add test for data preload link
* Use pre-built fallback in production mode
* Remove preload link for fallback from _document
* Update to make sure fallback is rendered correctly for serverless
* Fix#8655, skip rendering meta tags with undefined props
* Filter all tags, not just meta
* Only render defined props
* Remove filtering of undefined strings
Co-Authored-By: Tim Neutkens <tim@timneutkens.nl>
* Replace Object.entries
* Remove filtering code
* Simplify code
* Add test
* Add tests for undefined head prop value and tweak check
* Update to strip undefined prop values to match react
* Update head.js
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Joe Haddad <timer150@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Disable core-js on Next.js core files as it's not transforming anything important
* Move babel options to taskr plugin
* Disable transform-runtime for pages dir
* Disable correctly
* Disable corejs for core files
* Temporarily check if this fixes the error
* Use builtIns and exclude async-to-generator
* Update index.test.js
* Disable core-js on Next.js core files as it's not transforming anything important
* Move babel options to taskr plugin
* Disable transform-runtime for pages dir
* Disable correctly
* Disable corejs for core files
* Temporarily check if this fixes the error
* Fix error when reading Component.__NEXT_SPR in packages/next/client/index.js
* Use the .? optional chaining operator
Co-Authored-By: Tim Neutkens <tim@timneutkens.nl>
* Update index.js
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Fix missing quotes around `in` operator check for PerformanceObserver
* Always call `getEntriesByType()` even if performance observer is supported.
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Enable New CSS Support by Default
* Adjust configs
* Fix invisible AMP body
* Fix AMP validation warning
* test fix
* Use expression that won't be eliminated by babel
* Add assetPrefix when fetching script and style dependencies for granularChunks
* Lint
* Fix assetPrefix usage with granularChunks
* Add tests for granularChunks with assetPrefix
* Cleanup
* Use smaller name as it's not shortened
* Remove export as it's not used and it'll be shortened
* Update size
Co-authored-by: Joe Haddad <timer150@gmail.com>
* Optimize Prefetching
* fix css client nav test
* fix preload viewport test
* fix production test
* patch tests more
* Make page loader wait on prefetch
* no unhandled rejection
* Save some bytes
* CSS Module Support
* Fix Server-Side Render of CSS Modules
* Fix Jest Snapshots
https://github.com/facebook/jest/pull/8492
* Fix snapshots
* Add test for CSS module edit without remounting
* Add tests for dev and production style being applied
* Add missing TODOs
* Include/exclude should only be applied to issuer, not the CSS file itself
* Add CSS modules + node_modules tests
* Test that content is correct
* Create Multi Module Suite
* Add client-side navigation support for CSS
* Add tests for client-side nav
* Add some delays
* Try another fix
* Increase timeout to 3 minutes
* Fix test
* Give all unique directories
* Adding native-url package
* Bumping native-url version
* Upgrading native-url
* Logging stats object for debugging
* Logging stats object for debugging
* Adding try catch to the error lines
* Experimenting with regex
* Experimenting with regex
* Experimenting with regex
* Testing regex changes
* Fixing defer-script test case to not include polyfill.js
* Meging changes with existing polyfill work
* Bumping version
* adjust webpack config
* Reduce size in size test
* Remove 1kb from legacy
* Convert wrapper class to function component
* Remove unneeded export
* Check versions of chrome and chromedriver
* Update to chromedriver 76
* Revert config.yml
* Update with-router.tsx
