🐛 bug report

Because supportData['dynamic-import'] doesn't have an entry for node, dynamic imports for node targets with esm output cause the import()-polyfill check to trigger.

🎛 Configuration (package.json, cli command)

As per the repro repo:

package.json:

{
  "name": "@vad-systems/parcel-bug-repro",
  "version": "1.0.0",
  "type": "module",
  "private": true,
  "targets": {
    "server": {
      "context": "node",
      "outputFormat": "esmodule",
      "distDir": "build/server",
      "source": "src/server/index.ts",
      "engines": {
        "node": ">= 21"
      }
    }
  },
  "devDependencies": {
    "parcel": "2.12.0"
  },
  "scripts": {
    "build": "npx parcel build"
  }
}

cli command:

npm run build
> npx parcel build
>> parcel build

🤔 Expected Behavior

parcel bundles the target with node context correctly (forced for demonstration by injecting node: "1"):

$ npm run build
> @vad-systems/[email protected] build
> npx parcel build

✨ Built in 292ms

build/server/index.js           149 B    46ms
build/server/foo.1d7c16ab.js    233 B    53ms

with generated build/server/index.js:

var a={};a=import("./foo.1d7c16ab.js").then(()=>parcelRequire("7e5iT"));const{default:e}=await a;
//# sourceMappingURL=index.js.map

😯 Current Behavior

parcel errors out with the import()-polyfill check:

$ npm run build
> @vad-systems/[email protected] build
> npx parcel build

🚨 Build failed.

@parcel/runtime-js: No import() polyfill available for context 'node'

  Error: No import() polyfill available for context 'node'

💁 Possible Solution

Add node entry to supportData['dynamic-import'] as appropriate. I would argue this is 15.3 (the esm module was stabilized for 15.3.0, with backport to 14.17.0 and 12.22.0 - while it would be more accurate, I don't think it's necessary to include the backport versions at this point), and am about to provide a pull request to that effect.

🔦 Context

I haven't populated the repro repo with these additional constraints, as the bug itself seems to just be the missing supportData entry. This is further supported by the fact that matchesEngine does have a branch for node which just returns false for lack of an entry, and the reference to caniuse-api can't be the source for the existing node entries for arrow-functions and global-this.

💻 Code Sample

minimal repro repo

🌍 Your Environment