Closes https://github.com/vercel/next.js/issues/23299 to fix issues with NPM 7.

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 #19223
Fixes #21214

Hello this PR is in order to update xstate to the lastest version and use the `createMachine` method instead of `Machine`.
I also added the inspect mode in order to show how we could use into a next.js app.

## Documentation / Examples

- [x] Make sure the linting passes

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

## Examples

- [x] Make sure the linting passes

This PR updates the `with-stitches` example to use the Beta `0.1.0` release. 

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

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.