Co-authored-by: NLuis Alvarez D <luis@vercel.com>

The statement is not true, we provide mocks for `req` and `res`.

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

Closes #15330

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

Co-authored-by: NJoe Haddad <joe.haddad@zeit.co>

Low hanging fruit 🍎 
Resolves: #15321

`https://react-md.mlaursen.com/` -> `https://react-md.dev/`

This particular variable was not being read correctly. Added a test for the behavior.

Fixes #15261

Fixes https://github.com/vercel/next.js/issues/12046
Fixes https://github.com/vercel/next.js/issues/11992
Closes https://github.com/vercel/next.js/pull/13456

* Do not duplicate compilation errors

* Add tests

* Attempt to fix test

* Fix test

For reference: https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines

Fixes https://github.com/vercel/next.js/issues/15188

`parseRelativeUrl` was used on urls that weren't always relative. It was used to generate a cache key, but we actually don't need these cache keys to be relative if the urls aren't relative.

Also took a look at the overall static data fetching logic and found a few things:

- [x] cache key is unnecessarily transformed through `prepareRoute`, we can just cache by resolved `dataHref` and remove that function. Pretty sure that `prepareRoute` was also introducing edge cases with `assetPath` and `delBasePath`
- [x] there is [a bug in the caching logic](https://github.com/vercel/next.js/blob/ebdfa2e7a3f8e22e03b94dfb5f00481bf06254b6/packages/next/next-server/lib/router/router.ts#L898) that made it fail on the second visit: it should be `Promise.resolve(this.sdc[pathname])` instead of `Promise.resolve(this.sdc[dataHref])`. Also added a test for this
- [x] ~converted to async await to improve stacktraces and readability.~ I assumed this was fine since I saw some async/awaits in that file already but it seems to just blow up the size of the non-modern bundle.
- [x] extracted nested `getResponse` function and define it top level. this should improve runtime performance
- [x] convert `_getStaticData` and `_getServerData` to class methods instead of properties. Not sure why they were defined as properties but I think they belong on the prototype instead.
- [x] remove `cb` property from `fetchNextData`, it's unnecessary and makes the async flow hard to understand.  The exact same logic can go in the `.then` instead.
- [ ] data fetching logic [retries on 5xx errors](https://github.com/vercel/next.js/blob/ebdfa2e7a3f8e22e03b94dfb5f00481bf06254b6/packages/next/next-server/lib/router/router.ts#L157), but not on network level errors. It should also retry on those. It should also not retry on every 5xx, probably only makes sense on 502, 503 and 504. (e.g. 500 is a server error that I wouldn't expect to succeed on a retry)

The overall result also is a few bytes smaller in size

- Introduces a lint rule which points towards the unwanted polyfill.io features.
- Aim here is to make the user aware that which of the requested features are actually required vs which are already covered under `next-polyfills`

Next step: If the remaining required polyfills amounts to a only a few KBs then its better to include them in 1P javascript and remove the third party render blocking script tag.

Makes the difference between optional catch all routes and catch all routes clearer.

Closes #15229

Fixes a broken link on https://nextjs.org/docs/routing/dynamic-routes

This path was updated from `pages/docs/[...slug].js` to `pages/docs/[[...slug]].js`, so I've updated the link and moved that example down to the "Optional catch all routes" section.

Next.js forcibly setting `module: 'esnext'` in `tsconfig.json` is necessary to prevent TypeScript from erroring on the following code:

```tsx
import dynamic from 'next/dynamic';

const A = dynamic(() => import('../A'));
```

```
ERROR in /Users/joe/Desktop/scratch/test-cjs/pages/index.tsx(5,25):
5:25 Dynamic imports are only supported when the '--module' flag is set to 'es2020', 'esnext', 'commonjs', 'amd', 'system', or 'umd'.
  > 5 | const A = dynamic(() => import("../test"));
```

However, users may want to use one of the many other targets for better interoperability with projects that co-exist with their Next.js project (like `commonjs`).

When cross referenced with:
```
Option '--resolveJsonModule' can only be specified when module code generation is 'commonjs', 'amd', 'es2015' or 'esNext'.ts
```

That means we can permit any of these values:

```json5
      parsedValues: [
        ts.ModuleKind.ES2020,
        ts.ModuleKind.ESNext,
        ts.ModuleKind.CommonJS,
        ts.ModuleKind.AMD,
      ],
```

This PR updates Next.js to allow those!

---

Fixes #15275

Fixes one of the cases of https://github.com/vercel/next.js/pull/15185#issuecomment-660128647

This PR updates Prismic libraries to their latest version. 

Since the `previewSession` method was deprecated on version 3.0.1 we need to use `getPreviewResolver`. 

[Docs for in-Website Preview in Javascript
](https://prismic.io/docs/javascript/beyond-the-api/in-website-preview#17_0-processing-the-preview-token-with-getpreviewresolver-method)

ps: I have tested it and it works correctly. 

This matches Next.js engines https://github.com/vercel/next.js/blob/canary/packages/next/package.json#L212-L214

1. Switched from class components to functional components with hooks (https://reactjs.org/docs/hooks-effect.html)
2. Removed inject pattern (which is obsolete) in favor of hooks (https://mobx-react.js.org/recipes-migration)
3. Switched to mobx-react-lite

Fixes https://github.com/vercel/next.js/issues/15219

This is better than replacing the demo as having a demo could allow users to post any kind of comments that we can't control.

Co-authored-by: NLuis Alvarez <luis@vercel.com>