importing next/server inside of a library results in webpack cache warnings

[rayzr522]

Verify canary release

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

Provide environment information

Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
    Binaries:
      Node: 18.16.0
      npm: 9.5.1
      Yarn: 1.22.19
      pnpm: 8.3.1
    Relevant packages:
      next: 13.3.4
      eslint-config-next: 13.3.4
      react: 18.2.0
      react-dom: 18.2.0

Link to the code that reproduces this issue

https://github.com/rayzr522/next-server-webpack-cache-repro

To Reproduce

1. import NextResponse from next/server in a library
2. build the library
3. import and consume the library from your next.js app

if you're using the repo I linked above, simply clone, pnpm install, and then pnpm test -- the test script cleans up build files each time to ensure you get a clean build (as it only happens the first time the lib is built)

Describe the Bug

it appears that, when importing anything from next/server in a library and then using the library in a next.js app, it doesn't actually use the precompiled versions of next/server but rather attempts to process it thru webpack. this results in both a warning about using a node.js API in an edge runtime (process.turbopack is referenced somewhere in there) and about serialization performance issues by webpack's PackFileCache system.

it doesn't appear to actually include next/server in the bundle, as the final bundle sizes all look small enough to imply it was omitted:

Route (pages)                              Size     First Load JS
┌ ○ /                                      296 B          73.3 kB
├ ○ /404                                   182 B          73.2 kB
└ ℇ /api/hello                             0 B              73 kB
+ First Load JS shared by all              73 kB
  ├ chunks/framework-ffffd4e8198d9762.js   45.2 kB
  ├ chunks/main-7dd7374b80895cb0.js        26.8 kB
  ├ chunks/pages/_app-1b282c83ed55c5d8.js  194 B
  └ chunks/webpack-4e7214a60fad8e88.js     712 B

however, it's clearly still being processed by webpack in some way because I get this warning when building (either production or dev mode):

[webpack.cache.PackFileCacheStrategy] Serializing big strings (659kiB) impacts deserialization performance (consider using Buffer instead and decode when needed)

the size is always exactly the same so I'm assuming it's the sum total size of the import graph of next/server. i saw some issues in the next.js repo mentioning a warning similar to this, but it had to do with vanilla-extract using the full body of a CSS file when determining chunk names, and I'm pretty sure that doesn't translate to this other than maybe the entirety of next/server is somehow being used as the hash for a chunk name?

as of right now I don't think this is critical, as it doesn't appear to affect bundle sizes or build times in any meaningful way, but it's probably a sign that something is wrong in the default next.js webpack config so I wanted to bring it to light

Expected Behavior

there should be no webpack warning when external libraries import next/server and webpack shouldn't even have to touch next/server since it's precompiled

[huozhi]

Hi, the issue was caused by large module of og image being bundled first and then tree-shaked. in Next.js 14, we moved the og image to a separate exports next/og. If you upgrade you'll see there's no more webpack cache warnings showing up.

[github-actions]

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