Commit graph

7 commits

Author SHA1 Message Date
JJ Kasper
30f84e31b4
Update dev logs to include request timings (#49191)
This updates our dev logs to include request timings and also includes
fetch timings in app directory to including info on whether the cache
was leveraged or not allowing easier debugging of contributing factors
to render times. In the future we can expand to include middleware
timings separate as well to single that out along with timings for
`getStaticProps` potentially as well.


<details>

<summary>Screenshot</summary>

![CleanShot 2023-05-04 at 00 13
19@2x](https://user-images.githubusercontent.com/22380829/236135624-da1d873b-5abf-42d0-9708-8e20d1c56cef.png)

</details>

<details>

<summary>Screenshot</summary>

![CleanShot 2023-05-04 at 00 13
32@2x](https://user-images.githubusercontent.com/22380829/236135642-bc974b82-13e0-47f0-8be5-581d92077fc1.png)

</details>

<details>

<summary>Screenshot</summary>

![CleanShot 2023-05-04 at 00 13
47@2x](https://user-images.githubusercontent.com/22380829/236135664-5b2975ce-fa78-40d5-b320-d42d35b17541.png)

</details>

x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1681418590738249)
2023-05-04 12:33:03 -07:00
JJ Kasper
557084a331
Fix fetch cache body handling and update edge-runtime deps (#48365)
This ensures we don't fail to return the full body when storing to
fetch-cache in edge-runtime. Also ensures the fetch cache tests are
running for Node.js v16 correctly.

Fetch handling was also failing on Node.js v16 due to react's use of
`res.clone()` being broken with undici which is fixed in the latest
version of edge-runtime so this bumps that.

x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1681310566927429)
2023-04-13 22:00:20 -07:00
JJ Kasper
fdacca8abc
Add initial separated route resolving (#47208)
This updates to have a separate routing process and separate rendering
processes for `pages` and `app` so that we can properly isolate the two
since they rely on different react versions.

Besides allowing the above mentioned isolation this also helps us
control recovering from process crashes easier as pieces are more
isolated from one another e.g. an infinite loop during rendering will no
longer block the compiler and can be stopped/restarted as needed.

In follow-up PRs we will continue to separate out the routing logic from
the rendering logic so that each process only loads what is relevant to
it helping simplify the flow for requests regardless of type.

---------

Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
2023-04-02 15:17:15 +02:00
Tim Neutkens
d40ecb7f3f
Resolve RSC / HTML rendering errors in error overlay (#43332) 2022-11-25 13:06:42 +01:00
Damien Simonin Feugas
90bbac44db
fix(edge): error handling for edge route and middleware is inconsistent (#38401)
## What’s in there?

This PR brings more consistency in how errors and warnings are reported when running code in the Edge Runtime:

- Dynamic code evaluation (`eval()`, `new Function()`, `WebAssembly.instantiate()`, `WebAssembly.compile()`…)
- Usage of Node.js global APIs (`BroadcastChannel`, `Buffer`, `TextDecoderStream`, `setImmediate()`...)
- Usage of Node.js modules (`fs`, `path`, `child_process`…)

The new error messages should mention *Edge Runtime* instead of *Middleware*, so they are valid in both cases.

It also fixes a bug where the process polyfill would issue a warning for  `process.cwd` (which is `undefined` but legit). Now, one has to invoke the function `process.cwd()` to trigger the error.

It finally fixes the react-dev-overlay, where links from middleware and Edge API route files could not be opened because of the `(middleware)/` prefix in their name.

About the later, please note that we can’t easily remove the prefix or change it for Edge API routes. It comes from the Webpack layer, which is the same for both. We may consider renaming it to *edge* instead in the future.

## How to test?

These changes are almost fully covered with tests:

```bash
pnpm testheadless --testPathPattern runtime-dynamic
pnpm testheadless --testPathPattern runtime-with-node
pnpm testheadless --testPathPattern runtime-module
pnpm testheadless --testPathPattern middleware-dev-errors
```

To try them out manually, you can write a middleware and Edge route files like these:

```jsx
// middleware.js
import { NextResponse } from 'next/server'
import { basename } from 'path'

export default async function middleware() {
  eval('2+2')
  setImmediate(() => {})
  basename()
  return NextResponse.next()
}

export const config = { matcher: '/' }
```

```jsx
// pages/api/route.js
import { basename } from 'path'

export default async function handle() {
  eval('2+2')
  setImmediate(() => {})
  basename()
  return Response.json({ ok: true })
}

export const config = { runtime: 'experimental-edge' }
```

The expected behaviours are:

- [x] dev, middleware/edge route is using a node.js module: error at runtime (logs + read-dev-overlay):

```bash
error - (middleware)/pages/api/route.js (1:0) @ Object.handle [as handler]
error - The edge runtime does not support Node.js 'path' module.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
> 1 | import { basename } from "path";
  2 | export default async function handle() {
```

- [x] build, middleware/edge route is using a node.js module: warning but succeeds

```bash
warn  - Compiled with warnings

./middleware.js
A Node.js module is loaded ('path' at line 4) which is not supported in the Edge Runtime.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime

./pages/api/route.js
A Node.js module is loaded ('path' at line 1) which is not supported in the Edge Runtime.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
```

- [x] production, middleware/edge route is using a node.js module: error at runtime (logs + 500 error)

```bash
Error: The edge runtime does not support Node.js 'path' module.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
    at <unknown> (file:///Users/damien/dev/next.js/packages/next/server/web/sandbox/context.ts:149)
```

- [x] dev, middleware/edge route is using a node.js global API: error at runtime (logs + read-dev-overlay):

```bash
error - (middleware)/pages/api/route.js (4:2) @ Object.handle [as handler]
error - A Node.js API is used (setImmediate) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
  2 |
  3 | export default async function handle() {
> 4 |   setImmediate(() => {})
    |  ^
```

- [x] build, middleware/edge route is using a node.js global API: warning but succeeds

```bash
warn  - Compiled with warnings

./middleware.js
A Node.js API is used (setImmediate at line: 6) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime

./pages/api/route.js
A Node.js API is used (setImmediate at line: 3) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
```

- [x] production, middleware/edge route is using a node.js module: error at runtime (logs + 500 error)

```bash
Error: A Node.js API is used (setImmediate) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
    at <unknown> (file:///Users/damien/dev/next.js/packages/next/server/web/sandbox/context.ts:330)
```

- [x] dev, middleware/edge route is loading dynamic code: warning at runtime (logs + read-dev-overlay) and request succeeds (we allow dynamic code in dev only):

```bash
warn  - (middleware)/middleware.js (7:2) @ Object.middleware [as handler]
warn  - Dynamic Code Evaluation (e. g. 'eval', 'new Function') not allowed in Edge Runtime
   5 |
   6 | export default async function middleware() {
>  7 |   eval('2+2')
```

- [x] build, middleware/edge route is loading dynamic code: build fails with error:

```bash
Failed to compile.

./middleware.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Edge Runtime
Used by default

./pages/api/route.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Edge Runtime
Used by default
```

## Notes to reviewers

Edge-related errors are either issued from `next/server/web/sandbox/context.ts` file (runtime errors) or from `next/build/webpack/plugins/middleware-plugin.ts` (webpack compilation).

The previous implementation (I’m pleading guilty here) was way too verbose: some errors (Node.js global APIs like using `process.cwd()`) could be reported several times, and the previous mechanism to dedupe them (in middleware-plugin) wasn’t really effective.

Changes in tests are due to renaming existing tests such as `test/integration/middleware-with-node.js-apis` into `test/integration/edge-runtime-with-node.js-apis`. I extended them to cover Edge API route.

@hanneslund I’ve pushed the improvement you did in https://github.com/vercel/next.js/pull/38289/ one step further to avoid duplication.
2022-07-21 14:53:23 +00:00
Javi Velasco
a8757135e2
Fixes for middleware compilation errors (#37984)
* Refactor `runDependingOnPageType`

* Throw specific error when the compiled middleware cannot be found

* Do not render `MiddlewareNotFoundError` on dev

* Allow to invalidate compilers by type

* Show compile errors when middleware fails to build

* Add tests
2022-06-24 13:50:49 -05:00
Javi Velasco
de7b316446
Improve Middleware errors (#37695)
* Improve stack traces in dev mode

* Refactor `react-dev-overlay` to support the Edge Compiler

* Serialize errors including the compiler `source`

* Adopt the new `react-dev-overlay` displaying it for middleware errors

* Improve tests

* fix rsc cases

* update test

* use check for dev test

* handle different error from node version

Co-authored-by: feugy <damien@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
2022-06-14 19:58:13 -05:00