experimental-edge runtime should not use the browser version of dependencies

[ocavue]

Verify canary release

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

Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:07 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8110
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.19
      pnpm: 7.5.2
    Relevant packages:
      next: 12.3.2-canary.21
      eslint-config-next: 12.3.1
      react: 18.2.0
      react-dom: 18.2.0

What browser are you using? (if relevant)

Chrome 105

How are you deploying your application? (if relevant)

N/A

Describe the Bug

We are using turndown in our project. When we try to use the experimental-edge runtime, it throws ReferenceError: window is not defined.

turndown provides two builds: one for server (node_modules/turndown/lib/turndown.es.js) and one for the browser (node_modules/turndown/lib/turndown.browser.es.js).

// node_modules/turndown/package.json
{
  "name": "turndown",
  "description": "A library that converts HTML to Markdown",
  "version": "7.1.1",
  "author": "Dom Christie",
  "main": "lib/turndown.cjs.js",
  "module": "lib/turndown.es.js",
  "jsnext:main": "lib/turndown.es.js",
  "browser": {
    "domino": false,
    "./lib/turndown.cjs.js": "./lib/turndown.browser.cjs.js",
    "./lib/turndown.es.js": "./lib/turndown.browser.es.js",
    "./lib/turndown.umd.js": "./lib/turndown.browser.umd.js"
  },

It seems that Next.js is using the browser build on the server side, and since the server don't have window, it crashes.

Expected Behavior

Next.js experimental-edge runtime should use the server build from turndown.

Link to reproduction

https://github.com/issueset/nextjs-experimental-edge-turndown

To Reproduce

$ git clone https://github.com/issueset/nextjs-experimental-edge-turndown
$ cd nextjs-experimental-edge-turndown 
$ yarn install
$ yarn dev 

Use browser to open http://localhost:3000/api/hello, you should see the following error:

Uncaught ReferenceError: window is not defined
    at <unknown> (webpack-internal:///(middleware)/./node_modules/turndown/lib/turndown.browser.es.js:613)
    at shouldUseActiveX (webpack-internal:///(middleware)/./node_modules/turndown/lib/turndown.browser.es.js:613:5)
    at createHTMLParser (webpack-internal:///(middleware)/./node_modules/turndown/lib/turndown.browser.es.js:586:9)
    at eval (webpack-internal:///(middleware)/./node_modules/turndown/lib/turndown.browser.es.js:618:60)
    at Module.(middleware)/./node_modules/turndown/lib/turndown.browser.es.js (evalmachine.<anonymous>:323:1)
    at __webpack_require__ (evalmachine.<anonymous>:37:33)
    at fn (evalmachine.<anonymous>:269:21)
    at eval (webpack-internal:///(middleware)/./pages/api/hello.ts:8:66)
    at Module.(middleware)/./pages/api/hello.ts (evalmachine.<anonymous>:172:1)
    at __webpack_require__ (evalmachine.<anonymous>:37:33)
    at fn (evalmachine.<anonymous>:269:21)

Turn off the dev sever. Edit node_modules/turndown/package.json and remove the browser field from it, so that Next.js won't know the existence of turndown.browser.es.js.

{
  "name": "turndown",
  "description": "A library that converts HTML to Markdown",
  "version": "7.1.1",
  "author": "Dom Christie",
  "main": "lib/turndown.cjs.js",
  "module": "lib/turndown.es.js",
  "jsnext:main": "lib/turndown.es.js",
- "browser": {
-   "domino": false,
-   "./lib/turndown.cjs.js": "./lib/turndown.browser.cjs.js",
-   "./lib/turndown.es.js": "./lib/turndown.browser.es.js",
-   "./lib/turndown.umd.js": "./lib/turndown.browser.umd.js"
- },
  "dependencies": {
    "domino": "^2.1.6"
  },

Then run the follow shell command

$ rm -rf .next
$ yarn dev

Open http://localhost:3000/api/hello again, now it should work fine and shown the following content:

{"name":"Hello, from http://localhost:3000/api/hello I'm now an Edge Function! Turndown: function TurndownService (options) {\n  if (!(this instanceof TurndownService)) return new TurndownService(options)\n\n  var defaults = {\n    rules: rules,\n    headingStyle: 'setext',\n    hr: '* * *',\n    bulletListMarker: '*',\n    codeBlockStyle: 'indented',\n    fence: '```',\n    emDelimiter: '_',\n    strongDelimiter: '**',\n    linkStyle: 'inlined',\n    linkReferenceStyle: 'full',\n    br: '  ',\n    preformattedCode: false,\n    blankReplacement: function (content, node) {\n      return node.isBlock ? '\\n\\n' : ''\n    },\n    keepReplacement: function (content, node) {\n      return node.isBlock ? '\\n\\n' + node.outerHTML + '\\n\\n' : node.outerHTML\n    },\n    defaultReplacement: function (content, node) {\n      return node.isBlock ? '\\n\\n' + content + '\\n\\n' : content\n    }\n  };\n  this.options = extend({}, defaults, options);\n  this.rules = new Rules(this.options);\n}"}

[balazsorban44]

Hi, thanks for opening, and I'm sorry for moving this to discussions without more context.

So you are correct in that we decided to pick the browser field for the edge runtime, as we felt it was closer to what the runtime was capable of than Node.js (since you cannot use Node.js APIs in Edge, and browsers are usually fully spec-compliant also, compared to polyfills/packages.)

However, it seems like there is no one-size-fits-all solution here, as some packages (like turndown) have better edge compatibility via a different bundle than browser.

We have started working with the Web-interoperable Runtimes Community Group (WinterCG) to standardize new options, that would let package authors distribute a bundle in the future that is specific for Edge and similar runtimes: wintercg/admin#36

[ocavue]

Thanks for your explanation