Commit graph

4 commits

Author SHA1 Message Date
JJ Kasper
7d93808c43
Remove render workers in favor of esm loader (#54813)
Currently we create separate workers to isolate `pages` and `app`
routers due to differing react versions being used between the two. This
adds overhead and complexity in the rendering process which we can avoid
by leveraging an `esm-loader` similar to our `require-hook` to properly
alias `pages` router to the bundled react version to match `app` router
when both are leveraged together.

This aims to seamlessly inject the `esm-loader` by restarting the
process with the loader arg added whenever `next` is imported so that
this also works with custom-servers and fixes the issue with custom
req/res fields not working after upgrading.


x-ref: https://github.com/vercel/next.js/issues/53883
x-ref: https://github.com/vercel/next.js/issues/54288
x-ref: https://github.com/vercel/next.js/issues/54129
x-ref: https://github.com/vercel/next.js/issues/54435
closes: https://github.com/vercel/next.js/issues/54440
closes: https://github.com/vercel/next.js/issues/52702
x-ref: [slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1693348443932499?thread_ts=1693275196.347509&cid=C03KAR5DCKC)

---------

Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
2023-09-11 22:17:52 +02: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
Damien Simonin Feugas
6e2c3821cf
feat: build edge functions with node.js modules and fail at runtime (#38234)
## What's in there?

The Edge runtime [does not support Node.js modules](https://edge-runtime.vercel.app/features/available-apis#unsupported-apis).
When building Next.js application, we currently fail the build when detecting node.js module imported from middleware.

This is an blocker for using code that is conditionally loading node.js modules (based on platform/env detection), as @cramforce reported.

This PR implements a new strategy where:
- we can build such middleware/Edge API route code **with a warning**
- we fail at run time, with graceful errors in dev (console & react-dev-overlay error)
- we fail at run time, with console errors in production

## How to test?

All cases are covered with integration tests.
To try them live, create a simple app with a page, a `middleware.js` file and a `pages/api/route.js`file.
Here are iconic examples:

### node.js modules
```js
// middleware.js
import { NextResponse } from 'next/server'
// static
import { basename } from 'path'

export default async function middleware() {
  // dynamic
  const { basename } = await import('path')
  basename()
  return NextResponse.next()
}

export const config = { matcher: '/' }
```
```js
// pags/api/route.js
// static
import { isAbsolute } from 'path'

export default async function handle() {
  // dynamic
  const { isAbsolute } = await import('path')
  return Response.json({ useNodeModule: isAbsolute('/test') })
}

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

Desired error (+ source code highlight in dev):

> The edge runtime does not support Node.js 'path' module
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime

Desired warning at build time:

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

- [x]  in dev middleware, static, shows desired error on stderr
- [x]  in dev route, static, shows desired error on stderr
- [x]  in dev middleware, dynamic, shows desired error on stderr
- [x]  in dev route, dynamic, shows desired error on stderr
- [x]  in dev middleware, static, shows desired error on react error overlay
- [x]  in dev route, static, shows desired error on react error overlay
- [x]  in dev middleware, dynamic, shows desired error on react error overlay
- [x]  in dev route, dynamic, shows desired error on react error overlay
- [x]  builds middleware successfully, shows build warning, shows desired error on stderr on call
- [x]  builds route successfully, shows build warning, shows desired error on stderr on call

### 3rd party modules not found

```js
// middleware.js
import { NextResponse } from 'next/server'
// static
import Unknown from 'unknown'

export default async function middleware() {
  // dynamic
  const Unknown = await import('unknown')
  new Unknown()
  return NextResponse.next()
}
```
export const config = { matcher: '/' }
```
```js
// pags/api/route.js
// static
import Unknown from 'unknown'

export default async function handle() {
  // dynamic
  const Unknown = await import('unknown')
  return Response.json({ use3rdPartyModule: Unknown() })
}

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

Desired error (+ source code highlight in dev):

> Module not found: Can't resolve 'does-not-exist'
Learn More: https://nextjs.org/docs/messages/module-not-found

- [x]  in dev middleware, static, shows desired error on stderr
- [x]  in dev route, static, shows desired error on stderr
- [x]  in dev middleware, dynamic, shows desired error on stderr
- [x]  in dev route, dynamic, shows desired error on stderr
- [x]  in dev middleware, static, shows desired error on react error overlay
- [x]  in dev route, static, shows desired error on react error overlay
- [x]  in dev middleware, dynamic, shows desired error on react error overlay
- [x]  in dev route, dynamic, shows desired error on react error overlay
- [x]  fails to build middleware, with desired error on stderr
- [x]  fails to build route, with desired error on stderr

### unused node.js modules
```js
// middleware.js
import { NextResponse } from 'next/server'

export default async function middleware() {
  if (process.exit) {
    const { basename } = await import('path')
    basename()
  }
  return NextResponse.next()
}
```
```js
// pags/api/route.js
export default async function handle() {
  if (process.exit) {
    const { basename } = await import('path')
    basename()
  }
  return Response.json({ useNodeModule: false })
}

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

Desired warning at build time:

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

- [x]  invoke middleware in dev with no error
- [x]  invoke route in dev with no error
- [x]  builds successfully, shows build warning, invoke middleware with no error
- [x]  builds successfully, shows build warning, invoke api-route with no error

## Notes to reviewers

The strategy to implement this feature is to leverages webpack [externals](https://webpack.js.org/configuration/externals/#externals) and run a global `__unsupported_module()` function when using a node.js module from edge function's code.
For the record, I tried using [webpack resolve.fallback](https://webpack.js.org/configuration/resolve/#resolvefallback) and [Webpack.IgnorePlugin](https://webpack.js.org/plugins/ignore-plugin/) but they do not allow throwing proper errors at runtime that would contain the loaded module name for reporting.

`__unsupported_module()` is defined in `EdgeRuntime`, and returns a proxy that's throw on use (whether it's property access, function call, new operator... synchronous & promise-based styles).

However there's an issue with error reporting: webpack does not includes the import lines in the generated sourcemaps, preventing from displaying useful errors.
I extended our middleware-plugin to supplement the sourcemaps (when analyzing edge function code, it saves which module is imported from which file, together with line/column/source)

The react-dev-overlay was adapted to look for this additional information when the caught error relates to modules, instead of looking at sourcemaps.

I removed the previous mechanism (built by @nkzawa ) which caught webpack errors at built time to change the displayed error message (files `next/build/index.js`, `next/build/utils.ts` and `wellknown-errors-plugin`)
2022-07-06 20:54:44 +00:00
Damien Simonin Feugas
4e6b6a5b86
feat(middleware): issues warnings when using node.js global APIs in middleware (#36980) 2022-05-23 11:07:26 +02:00