This ensures we exit the build process after the build completes even if timers/connections are left open since this can cause the process to hang indefinitely. This was the previous behavior although got changed un-intentionally in e27b7e996d
This updates our production test with an open timer to ensure it doesn't block the process from completing.
I've been this confusion quite a few times.
> So with my requirements, how big of a sin is it to use Next only for the frontend and get all its data, JWT tokens, etc. from my NodeJS backend by calling its respective APIs to said backend?
> Even the docs mention that running a custom server is not a great idea...
I thought that the current wording was not accurate both for next-iron-session and next-auth.
- next-auth is a full-featured authentication system like passport
- next-iron-session is a session utility
The previous copy was less clear about that and, for example, said you should go for next-iron-session for user/password and next-auth for everything else. Which is not the case. I use next-iron-session with only a Slack login, and you can implement email/password with next-auth.
Hope you like it!
PS: I have no preference between the two, I think they serve a different purpose. I used the two (and authored one).
I used next-auth on https://sourcekarma.vercel.app/
This Pull Request makes [`@tailwindcss/jit`](https://github.com/tailwindlabs/tailwindcss-jit) the default engine for Tailwind CSS.
It has the following advantages:
- Lightning-fast build times because the CSS is generated on demand.
- Every variant is enabled out of the box.
- Generate arbitrary styles without writing custom CSS.
- Better performance in browser dev-tools.
As stated in #23157, this PR merges all the operations into 1 worker thread (`processBuffer` in `impl.ts`) and only pass a list of operation names and args into the worker. This should improve the speed and memory usage of next/image.
Fixes#23157. X-ref: #22925.
This allows to use `__NEXT_WEBPACK_LOGGING` to enable verbose webpack logging output to investigate into performance and cache problems.
`__NEXT_WEBPACK_LOGGING=1` enables some basic logging
`__NEXT_WEBPACK_LOGGING=infrastructure` enables only infrastructure logging
`__NEXT_WEBPACK_LOGGING=profile-client` enables deep profile output of the client build
`__NEXT_WEBPACK_LOGGING=profile-server` same for the server
`__NEXT_WEBPACK_LOGGING=profile-client,infrastructure` combines multiple things
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
