Middleware builds are using the package.json browser field

[tatethurston]

Verify canary release

• I verified that the issue exists in Next.js canary release

Provide environment information

(not relevant)

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 20.6.0: Wed Jan 12 22:22:42 PST 2022; root:xnu-7195.141.19~2/RELEASE_X86_64
Binaries:
  Node: 16.14.0
  npm: 8.3.1
  Yarn: 1.22.17
  pnpm: N/A
Relevant packages:
  next: 12.1.0
  react: 17.0.2
  react-dom: 17.0.2

What browser are you using? (if relevant)

N/A

How are you deploying your application? (if relevant)

N/A

Describe the Bug

Middleware webpack builds are using the "browser" field from package.json, which is surprising because middleware only run s in a server context.

With the following in your package.json:

  "browser": {
    "some-package": false,
  }

some-package will not be defined in middleware handlers.

Expected Behavior

The "browser" field from package.json is not used when building middleware code paths.

To Reproduce

1. Add a package entry within the browser field in the project package.json, setting it's value to false
2. Import the package into middleware
3. Observe the package is undefined in the middleware runtime

[tatethurston]

Sandbox example: https://codesandbox.io/s/keen-cray-33iz09?file=/pages/_middleware.js

[balazsorban44]

This is expected, as Middleware uses the Edge Runtime (which builds on the same web standard APIs as browsers), not Node.js. https://nextjs.org/docs/api-reference/edge-runtime#unsupported-apis.

[balazsorban44]

Update, this behavior might change in the next canary release when this is published: #35335

[tatethurston]

@balazsorban44 The linked article cites middleware runtime constraints, but nothing about how dependencies are built. As a user this overloading of the browser field is surprising -- I would not expect to have the browser field applied to a build that is not executed on the client's browser. User's may want to consume a different library entry point or ensure it doesn't end up in client builds irrespective of any runtime constraints.

[balazsorban44]

I forwarded your feedback, thank you!

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.