I have added a new section to the `with-redux-toolkit` example on setting up Typescript with Redux Toolkit and React-Redux.
It links the redux toolkit documentation and Next.js documentation on adding Typescript to a Next.js project.
* this will fix problems with serverless target which doesn't use a runtime chunk
* It also omit env vars from contributing to cache version as webpack will handle that now
* It moves the webpack-runtime chunk from ./chunks back to ./
This PR upgrades `jest-worker` and `jest-cli` to the latest pre-release version, also removed `jest-circus` which is included in Jest by default. `jest-worker@next` includes a fix for memory leak that we need (https://github.com/facebook/jest/pull/11187).
Fixes#22925. This will also improve the OOM issue for `next dev` #15855.
I have simplified the `with-redux-toolkit` example and changed the directory structure to "feature folders". I have removed the `notes` page and API route as it wasn't directly related to the redux toolkit. This example is also identical to the official [cra redux template](https://github.com/reduxjs/cra-template-redux). All the dependencies have also been updated.
- `scroll` - Optional boolean, controls scrolling to the top of the page after navigation. Defaults to `true` and
- `scroll`: Scroll to the top of the page after a navigation. Defaults to `true`
as options for router.push
# 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
This makes sure we don't trigger the export step if we aren't exporting any static pages during a build. This also adds an invariant to ensure we don't attempt creating a progress with 0 items.
Fixes: https://github.com/vercel/next.js/issues/22994
A number of changes here. I recommend viewing the diff with the <a href="?w=1">whitespace flag enabled</a>.
- OpenTelemetry is replaced with a custom and lightweight tracing solution.
- Three trace targets are currently supported: console, Zipkin, and NextJS.
- Tracing is now governed by environment variables rather than `--require instrument.js`.
+ `TRACE_TARGET`: one of `CONSOLE`, `ZIPKIN`, or `TELEMETRY`; defaults to `TELEMETRY` if unset or invalid.
+ `TRACE_ID`: an 8-byte hex-encoded value used as the Zipkin trace ID; if not provided, this value will be randomly generated and passed down to subprocesses.
Other sundry:
- I'm missing something, probably a setup step, with the Zipkin target. Traces are captured successfully, but you have to manually enter the Trace ID in order to view the trace - it doesn't show up in queries.
- I'm generally unhappy with [this commit](235cedcb3e). It is... untidy to provide a telemetry object via `setGlobal`, but I don't have a ready alternative. Is `distDir` strictly required when creating a new Telemetry object? I didn't dig too deep here.
As noted, there are a lot of changes, so it'd be great if a reviewer could:
- [ ] pull down the branch and try to break it
- [ ] check the Zipkin traces and identify possible regressions in the functionality
Closes#22570Fixes#22574
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.
This updates to not automatically export `/500` from `_error` if a custom `getInitialProps` is used since logic may be used inside of this method that causes the export to fail. Users can still opt-in to the static `/500` by adding a `pages/500.js` file.
This also refactors checking `_app` for custom `getInitialProps` to outside of the static check loop to prevent a potential race condition where we could run this check multiple times un-necessarily.
Fixes: https://github.com/vercel/next.js/issues/22815
Hiya! I was asked to add an example of how to use [Compiled](https://compiledcssinjs.com/) with Next.js, figured I might as well at it to the source 😄. Let me know if there's any changes needed.
This ensures we load all env values before loading `next.config.js` since these values can be used in there. This also updates to ensure we're testing these values are available while loading `next.config.js` so we don't regress on this.
Fixes: https://github.com/vercel/next.js/issues/22811
This ensures we don't export `/404` during the automatic static optimization during build when the `/404` isn't static and won't be used/copied to the final output.
x-ref: https://github.com/vercel/next.js/issues/22815
