Co-authored-by: Nkodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>

fixes #23125

fixes https://github.com/tailwindlabs/tailwindcss-jit/issues/54

## 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 pull request add typescript to the current redux-toolkit example on next.js. @markerikson suggested this nice idea to add a ts example: https://twitter.com/acemarke/status/1370877104527712259?s=20

This example is with the previous redux-toolkit example which was more complex. An example with the current example is available here: https://github.com/vercel/next.js/pull/23249

## 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

Under the Single-Page App (SPA) heading, there is a code snipped which has a missing import:
import { useState } from 'react'
to
import { useState, useEffect } from 'react'

Also added apostrophe to description:
your old application entry point
to
your old application's entry point



## 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

- [X] Make sure the linting passes

Currently Next.js exposes internal code in the error overlay if certain errors were created from the user code. Some examples were attached in #20776.

We can clearly see that the path is wrong (`../next-server`), it should be `./node_modules/next/dist/next-server`:

![CleanShot 2021-03-19 at 01 33 04](https://user-images.githubusercontent.com/3676859/111670728-1ae7e400-8853-11eb-9213-3b359798900e.png)

The root cause is the `__nextjs_original-stack-frame` middleware resolves the file path with the following code:

```js
path.resolve(
  rootDirectory,
  getSourcePath(sourcePosition.source)
)
```

where `rootDirectory` is the **app root**, but `sourcePosition.source` comes from the module path, which is relative to the path of the `next` binary, not the app root. 

That explains why we see `../next-server` from the error above, because it's relative to `./node_modules/next/bin/next`.

Because of that, the resolved result will never have `node_modules` in its path and it won't be filtered by the error overlay in the UI. Here's a screenshot of the frame object in the UI:

![CleanShot 2021-03-18 at 23 01 29@2x](https://user-images.githubusercontent.com/3676859/111670062-65b52c00-8852-11eb-9293-3a6e5b7c4b9b.png)

And the filter we use to determine if a frame is expanded or not only depends on `body.originalStackFrame`:

```js
expanded: !Boolean(
  body.originalStackFrame?.file?.includes('node_modules') ?? true
)
```

So this PR also adds `source.file` check to ensure they will be ignored (not necessary because we fixed the path resolving).

Fixes #20776.

## 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.
- [ ] 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

Fixes #23240

VERCEL_GIT_COMMIT_SHA is now available by default across all integrations

This PR attempts to provide an option to allow importing TS/TSX from outside of the current Next.js project root directory. Although this goes against the design decision that no source code should be imported from outside of root and [might bring tons of issues](https://github.com/vercel/next.js/issues/19928#issuecomment-741596557), it will still be helpful in some monorepo use cases.

This PR assumes that the external files are following the same language syntax rules and under the same tooling versions as the source code inside your project root. And it's also not allowed to enable the `baseUrl` feature in the external directory (as the project should only have 1 import base URL).

X-ref: #9474, #15569, #19928, #20374.

Following commit https://github.com/vercel/next.js/commit/1f5c2c851333b5601cc1e9463253fdad0f0d8883

Adding documentation links to example.

## Feature

- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [X ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.

## Documentation / Examples

- [x ] Make sure the linting passes

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 https://github.com/vercel/next.js/commit/e27b7e996d6e7e6772272f3d189ce93dac25fc3d

This updates our production test with an open timer to ensure it doesn't block the process from completing. 

The packages referenced here were removed.

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.

as vercel doesn't allow env vars starting with _

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

And an improved design 😄 

https://roadmap-redis.vercel.app/

It's currently misleading and I chose to freeze to a particular version since pointing to canary every time is likely to break (as is happening prior to this PR).

The link will now go to: https://github.com/vercel/next.js/blob/v10.0.8/packages/next/next-server/server/config-shared.ts#L33

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.

update webpack, fix runtime location, fix undeclared variable, omit env vars from cache version (#23113)

* 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.

Supersedes https://github.com/vercel/next.js/pull/23115 for more clarity and a better recommendation.

I similarly [couldn't find this info](https://github.com/vercel/next.js/issues/19711#issuecomment-750414110) in the docs about configuring the image path when using an app `basePath`, so thought I'd add it.

  - `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