Description
🐛 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
pointless prose for background
Granted, this is a somewhat odd setup, but I have quite a bit of shared code between the server and client bundles, and while it naturally doesn't make much sense to split the code on the server, code-splitting on the client is rather useful. If I make use of parcel-specific features (such as transformers for non-js files), `isLibrary: true` for the server target stops being a useful option without making the toolchain more complicated again. Similarly, I do need to compile the server for a `node` context because the non-shared code in that target relies on node dependencies. I could probably work around this by moving the shared code out to a library, but that also makes code-splitting more tedious.
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
🌍 Your Environment
| Software | Version(s) |
|---|---|
| Parcel | 2.12.0 |
| Node | 18.16.0 |
| npm | 9.5.1 |
| Operating System | MacOS 14.4.1 |