Eliminate `createRequire`/`require` from `EXPORT_ES6` output by vogel76 · Pull Request #26384 · emscripten-core/emscripten

vogel76 · 2026-03-03T22:57:43Z

When building with -sEXPORT_ES6, the generated JavaScript currently uses createRequire(import.meta.url) to polyfill require(), then calls require() for Node.js built-in modules. This breaks bundlers (webpack, Rollup, esbuild, Vite) and Electron's renderer process, forcing users to post-process emscripten output with sed or custom plugins to strip out the offending calls.

This PR replaces all require() calls with await import() when EXPORT_ES6 is enabled, eliminating the need for createRequire entirely.

Why this is safe

EXPORT_ES6 requires MODULARIZE (enforced in tools/link.py). MODULARIZE wraps the module body in an async function, so await is valid at the top level of the generated code.
The preprocessor already supports this pattern. await import(...) is transformed to an EMSCRIPTEN$AWAIT$IMPORT placeholder during preprocessing (parseTools.mjs:83) and restored during linking (link.py:2136). This mechanism is already used elsewhere in the codebase.
Node.js built-in modules expose identical ESM interfaces. (await import('node:fs')).readFileSync works identically to require('node:fs').readFileSync. For CJS npm packages like ws, .default gives the module.exports value.
No behavioral change for non-ES6 builds. All changes are guarded by #if EXPORT_ES6 / #else preprocessor conditionals. The existing require() code path is untouched.

Approach

The changes split naturally into two categories:

Shell and runtime files (top-level async context where await works directly):

src/shell.js — Remove the createRequire block. Use await import() for worker_threads, fs, path, url, util.
src/shell_minimal.js — Same pattern for worker_threads and fs. Replace __dirname with new URL(..., import.meta.url) for wasm file loading.
src/runtime_debug.js — Skip local require() for fs/util when EXPORT_ES6; reuse outer-scope variables from shell.js.
src/runtime_common.js — Guard perf_hooks require() with EXPORT_ES6 alternative.
src/preamble.js — Hoist await import('node:v8') above instantiateSync() for NODE_CODE_CACHING (can't use await inside a sync function).

Library files (synchronous function bodies where await is unavailable):

Library functions execute in synchronous context, so await import() cannot be called inline. Instead, we define library symbols initialized at module top level (async context) and reference them via __deps:

Symbol	Module	Used by
`$nodeOs`	`node:os`	`libatomic.js`, `libwasm_worker.js`
`$nodeCrypto`	`node:crypto`	`libwasi.js` (`$initRandomFill`)
`$nodeChildProcess`	`node:child_process`	`libcore.js` (`_emscripten_system`)
`$nodeWs`	`ws` (`.default`)	`libsockfs.js` (WebSocket connect + listen)
`$nodePath`	`node:path`	`libnodepath.js` (NODERAWFS)

Shared symbols live in a new src/lib/libnode_imports.js, registered in src/modules.mjs when EXPORT_ES6 is enabled.

Intentionally skipped

src/lib/libembind_gen.js — Build-time code running in Node.js directly, not in emitted runtime JS.
src/closure-externs/closure-externs.js — createRequire extern kept; still needed for the non-ES6 path.

What changes in the output

Before (EXPORT_ES6):

import { createRequire } from 'node:module';
var require = createRequire(import.meta.url);
var fs = require('node:fs');

After (EXPORT_ES6):

var fs = await import('node:fs');

The non-ES6 path remains unchanged:

var fs = require('node:fs');

Files modified

13 files modified, 1 new file — 123 insertions, 12 deletions (source files only).

Testing

All existing ESM tests pass:

Test	Result
`test_esm` (default, node, pthreads variants)	PASS
`test_esm_worker` (default, node variants)	PASS
`test_esm_worker_single_file`	PASS
`test_esm_closure`	PASS
`test_esm_implies_modularize`	PASS
`test_esm_requires_modularize`	PASS
`test_pthread_export_es6` (default, trusted variants)	PASS

Additionally verified:

emcc -sEXPORT_ES6 -sMODULARIZE output contains zero createRequire or require( occurrences
emcc -sEXPORT_ES6 -sMODULARIZE -pthread output contains zero createRequire or require( occurrences
Non-ES6 builds still use require() as before (no regression)

Related issues

Node + Electron environment is getting more difficult to use #24789 — EXPORT_ES6 output contains require() which breaks bundlers
Shouldn't EXPORT_ES6 use only ES6 semantics? #20503 — createRequire breaks Electron renderer
[Feature Request] Support building for both UMD/ESM #21899 — ES module output not compatible with bundlers
Eliminate the circular dependency between the main loader and the worker #20580 — webpack fails on emscripten ES6 output
Build mysteriously fails with {"type":"module"} package.json in the parent directory #17431 — Feature request: native ESM support without require()
Add a new ESM option for ES6 module support #15060 — require() in ESM output breaks Rollup

Related PRs

Prefix node built-in module imports with node:. #18235 — Earlier attempt to address this (partial)
Support ES6 module syntax in Acorn, Babel and Closure #23730 — Related ESM improvements

sbc100

Wow, thanks for working on this! Nice work.

sbc100 · 2026-03-03T23:34:21Z

+  Module['wasm'] = fs.readFileSync(new URL('{{{ TARGET_BASENAME }}}.wasm', import.meta.url));
+#endif
+#endif
+#else


This seems like a lot of extra complexity/duplication. Is there some way to avoid it maybe?

vogel76 · 2026-03-04T23:20:04Z

@sbc100 I hope your remarks have been addressed in added fixup commits. Once you accept it, I will do autosquash rebase to leave only actual commits in clean history.

sbc100 · 2026-03-05T00:06:01Z

Is it possible to write a test for this?

When you say "This breaks bundlers", do you know why our current bundler tests in test_browser.py are working? (see test_rollup and test_vite). Would you be able to write a failing test for this breakage?

sbc100 · 2026-03-05T00:07:43Z

Re-commiting, we always squash all changes in the emscripten repo.

If you think this change can be split into to commits then please send a two separate PRs. This is just how we do things in emscripten. It helps keep the tests passing on every commit (for the benefit of bisectors).

sbc100 · 2026-03-05T00:16:56Z

-  var fs = require('node:fs');
+  var fs = {{{ makeNodeImport('node:fs') }}};
 #if WASM == 2
-  if (globalThis.WebAssembly) Module['wasm'] = fs.readFileSync(__dirname + '/{{{ TARGET_BASENAME }}}.wasm');


Does this code (which uses __dirname) simply not work with EXPORT_EST today?

If not, this seems like maybe a separate fix that we could land in isolation. e.g. Fix for EXPORT_ES6 + MINIMAL_RUNTIME + ???

The __dirname usage in shell_minimal.js indeed doesn't work with EXPORT_ES6 today — it's the same class of issue as require() not being available in ESM.

The fix uses makeNodeFilePath() which switches between:

ESM: new URL('file.wasm', import.meta.url)

CJS: __dirname + '/file.wasm'

I kept it in this PR because the changes are on the same lines as the require() → makeNodeImport() replacements — splitting them would create merge conflicts between the two PRs for no benefit. But happy to separate if you prefer.

If shell_minimal.js already doesn't work it seems fine to leave it out of this change. shell_minimal.js is not ever used by default, and compatibility with all settings is not important here IMHO.

vogel76 · 2026-03-05T08:17:29Z

Is it possible to write a test for this?

When you say "This breaks bundlers", do you know why our current bundler tests in test_browser.py are working? (see test_rollup and test_vite). Would you be able to write a failing test for this breakage?

Sure - will add such tests. The sake of such work are maintenance problems of our Hive blockchain interfacing library: wax which compiles blockchain protocol C++ code into wasm and uses it at TS/JS level. We have set of tests related to bundlers and different frameworks where we got problems while loading wasm etc.

https://gitlab.syncad.com/hive/wax/-/tree/develop/examples/ts?ref_type=heads

vogel76 · 2026-03-09T07:39:23Z

Is it possible to write a test for this?

When you say "This breaks bundlers", do you know why our current bundler tests in test_browser.py are working? (see test_rollup and test_vite). Would you be able to write a failing test for this breakage?

Deeper analysis gave conclusions why Existing tests don't catch the require() problem.
The browser bundler tests all use -sENVIRONMENT=web, which means the Node.js code paths (containing require('node:fs') etc.) are compiled out entirely. The node-side test_rollup in test_other.py does trigger those paths, but rollup marks node builtins as external by default — so it silently passes them through without error.

The real breakage happens when:

No -sENVIRONMENT=web — output includes both web and node code paths
Bundler targets web — it tries to resolve require('node:fs') and fails
Framework SSR — Next.js/Nuxt process ESM server-side, require() in ESM is a syntax error in strict ESM mode

I extended test to cover more usecases altough adding tests covering whole frameworks seems to heavy for your project. Our wax library covers that...

sbc100 · 2026-03-09T15:44:28Z

The node-side test_rollup in test_other.py does trigger those paths, but rollup marks node builtins as external by default — so it silently passes them through without error.

I'm curious about this case. I'd love to add a test to test_other.py that fails on main due to the "This breaks bundlers" issue you mention.

Are you saying that rollup doesn't actually break (since it marks node builtins as external by default)? If so, is rollup just not effected by this bug?

Is vite effected? Could we add a test to test_other.py alongside test_rollup? We already have a dependency on both vite and rollup for running these tests.

vogel76 · 2026-03-09T20:35:09Z

The node-side test_rollup in test_other.py does trigger those paths, but rollup marks node builtins as external by default — so it silently passes them through without error.

I'm curious about this case. I'd love to add a test to test_other.py that fails on main due to the "This breaks bundlers" issue you mention.

Are you saying that rollup doesn't actually break (since it marks node builtins as external by default)? If so, is rollup just not effected by this bug?

Is vite effected? Could we add a test to test_other.py alongside test_rollup? We already have a dependency on both vite and rollup for running these tests.

Here are new tests targeted to main where they are expected to fail:
#26419

They shall pass here ofc. Once you accept it, I will cherry-pick them to this PR

sbc100 · 2026-03-09T20:44:58Z

Those tests look great thanks!

sbc100

(sorry I forgot the send my pending comment)

vogel76 · 2026-03-19T23:14:40Z

Changes in this update:

Fixed ws module eager loading regression in libsockfs.js
- The original $nodeWs library symbol caused ws to load eagerly at module init time whenever SOCKFS was included, breaking builds where ws isn't installed (Cannot find module 'ws').
- Replaced with $nodeRequire — a createRequire-based polyfill that's only pulled in when SOCKFS is linked. Socket code uses nodeRequire('ws') for lazy synchronous loading. Non-socket ESM builds remain completely require()-free.
Folded ENVIRONMENT_IS_NODE guard into makeNodeImport (per sbc100's review)
- makeNodeImport(module, guard=true) now wraps the result in ENVIRONMENT_IS_NODE ? ... : undefined by default, eliminating the repetitive pattern in library symbol definitions.
- makeNodeImport(module, false) returns the raw expression for callers already inside if (ENVIRONMENT_IS_NODE) blocks.
- Added assert(ENVIRONMENT_MAY_BE_NODE) to catch misuse.
Rebased onto latest main (includes Binaryen 127 update, fixing ~95% of previous CI failures caused by version mismatch).

Known remaining issues:

Closure Compiler + ESM: Closure runs before the MODULARIZE async wrapper, so it sees await import() at the top level and fails with Parse error. await must be inside asynchronous function. Needs a separate fix (placeholder approach or running MODULARIZE before Closure).
Audio worklet ES6 tests (test_audio_worklet_es6, test_audio_worklet_pthreads_es6): runtime failures — investigating whether top-level await in the module affects AudioWorklet.addModule().

vogel76 · 2026-03-20T12:05:52Z

@sbc100 could you take a look for test-bun and test-deno failures? Probably I will need some help in getting local env. to reproduce problems. Please point me some doc or scripts how to setup it. Best if you have some docker image to run them in...

sbc100 · 2026-03-23T18:41:30Z

+#if ENVIRONMENT_MAY_BE_NODE && EXPORT_ES6
+  // In ESM mode, require() is not natively available. When SOCKFS is used,
+  // we need require() to lazily load the 'ws' npm package for WebSocket
+  // support on Node.js. Set up a createRequire-based polyfill.


Why do we still need createRequire in this case?

sync context requires createRequire, can't use await import()

Can you explain more here? How/why does libsocksf require "sync context" whereas other places in the codebase don't?

Do we need to update how we use the ws package maybe?

The sync context at connect()/listen() is real (sync syscall callbacks across the JS↔Wasm boundary — no await without ASYNCIFY). More importantly, ws is a user-installed peer-dep: many programs link libsockets transitively without ever calling WebSocket ops, so loading ws at init would regress those programs vs. the CJS build. createRequire gives us a sync require() scoped to import.meta.url; the inner await import('node:module') is a cheap Node builtin that can't fail. The actual ws load stays lazy — same behavior as the CJS build. A bigger refactor (async-friendly WS library, or asyncify the socket syscall layer) could remove createRequire, but that's out of scope here.

You can analyze failures by change addressing your request:
2642a5d

When EXPORT_ES6 is enabled, the generated JS used createRequire() to polyfill require(), which breaks bundlers (webpack, Rollup, esbuild) and Electron's renderer process. Since EXPORT_ES6 requires MODULARIZE, the module body is wrapped in an async function where await is valid. - shell.js: Remove createRequire block entirely. Use await import() for worker_threads, fs, path, url, util. Replace __dirname with import.meta.url for path resolution. - shell_minimal.js: Same pattern for worker_threads and fs. Replace __dirname with new URL(..., import.meta.url) for wasm file loading. - runtime_debug.js: Skip local require() for fs/util when EXPORT_ES6, reuse outer-scope variables from shell.js instead. - runtime_common.js: Guard perf_hooks require() with EXPORT_ES6 alternative. - preamble.js: Hoist await import('node:v8') above instantiateSync() for NODE_CODE_CACHING since await can't be used inside sync functions.

Library functions run in synchronous context where await is unavailable. Define top-level library symbols that use await import() at module init time, then reference them via __deps from synchronous functions. - Add libnode_imports.js with shared $nodeOs symbol, register in modules.mjs when EXPORT_ES6 is enabled. - libatomic.js, libwasm_worker.js: Use $nodeOs for os.cpus().length instead of require('node:os'). - libwasi.js: Define $nodeCrypto for crypto.randomFillSync in $initRandomFill. Combine conditional __deps to avoid override. - libcore.js: Define $nodeChildProcess for _emscripten_system. - libnodepath.js: Switch $nodePath initializer to await import(). - libsockfs.js: Define $nodeWs ((await import('ws')).default) for WebSocket constructor in connect() and Server in listen().

Bundlers (webpack, rollup, vite, esbuild) and frameworks (Next.js, Nuxt) cannot resolve CommonJS require() calls inside ES modules. This test statically verifies that EXPORT_ES6 output uses `await import()` instead of `require()` for Node.js built-in modules, and that the `createRequire` polyfill pattern is not present. Parameterized for default, node-only, and pthreads configurations to cover the various code paths that import Node.js built-ins (fs, path, url, util, worker_threads).

…ire() Add two tests that verify EXPORT_ES6 output is valid ESM and works with bundlers: - test_webpack_esm_output_clean: Compiles with EXPORT_ES6 and default environment (web+node), then builds with webpack. On main, webpack hard-fails because it cannot resolve 'node:module' (used by emscripten's createRequire polyfill). This breaks any webpack/Next.js/Nuxt project. - test_vite_esm_output_clean: Compiles with EXPORT_ES6 and default environment, then builds with vite. On main, vite externalizes 'node:module' for browser compatibility, emitting a warning. The resulting bundle contains code referencing unavailable node modules. These tests are expected to fail on main and pass after eliminating require() from EXPORT_ES6 output.

The previous fix moved await import() for node:fs and node:util outside dbg() to module scope. This broke test_dbg because dbg() can be called from --pre-js before those module-scope imports execute. Use lazy initialization instead: declare dbg_node_fs/dbg_node_utils early but leave them undefined. Initialize them in shell.js after fs and utils are loaded (reusing the same imports). dbg() checks if the modules are available and falls back to console.warn if not. This handles all cases: - dbg() from --pre-js (before init): uses console.warn - dbg() after init on Node.js with pthreads: uses fs.writeSync - dbg() in browser/non-node: uses console.warn

In ESM mode (WASM_ESM_INTEGRATION), the runtime uses dynamic import() instead of require() for node modules. Update the test_environment assertion to check for 'import(' when in ESM mode, rather than always expecting 'require('.

The test was using require('path') which doesn't work in ESM mode. Since ESM output (.mjs) wraps the module in an async context, we can use top-level await with dynamic import. Changed from: require('path')['isAbsolute'](scriptDirectory) To: var nodePath = await import('node:path'); nodePath.isAbsolute(scriptDirectory) This properly tests the Node.js path.isAbsolute() function while being compatible with ESM module format. The CJS variant (test_locate_file_abspath) continues to use require() as appropriate for CommonJS.

Closure compiler runs before the MODULARIZE async wrapper is applied, so it sees `await import('node:xyz')` outside an async function and fails to parse it. Work around this by: 1. Before Closure: Replace `await import('node:xyz')` with placeholder variables like `__EMSCRIPTEN_PRIVATE_AWAIT_IMPORT_xyz__` 2. Generate externs for the placeholders so Closure doesn't error on undeclared variables 3. After Closure: Restore placeholders to `(await import('node:xyz'))` with parentheses to handle cases where Closure inlines the variable into expressions like `placeholder.method()` This follows the same pattern as the existing `__EMSCRIPTEN_PRIVATE_MODULE_EXPORT_NAME_SUBSTITUTION__` mechanism.

Instead of skipping EM_ASM tests that use CJS require() in ESM modes, add a createRequire-based polyfill (available since Node 12.2.0) that makes require() available in ESM output. The polyfill is only included when the build targets ESM (EXPORT_ES6, MODULARIZE=instance, or WASM_ESM_INTEGRATION). - Add test/require_polyfill.js using createRequire from 'module' - Add is_esm() and add_require_polyfill() helpers to test/common.py - Remove @no_modularize_instance skips from test_fs_nodefs_rw and test_fs_nodefs_home, enabling them in ESM test modes

When EXPORT_ES6 is enabled, makeNodeImport() generates top-level await import() expressions. Babel's transpile step was configured with sourceType 'script', which cannot parse top-level await. This caused test_node_prefix_transpile to fail at compilation. Use sourceType 'module' when EXPORT_ES6 is active so Babel can correctly parse and transpile the ESM output.

runtime_debug.js references dbg_node_fs and dbg_node_utils when ENVIRONMENT_MAY_BE_NODE with PTHREADS or WASM_WORKERS, but these variables were only declared in shell.js, not in shell_minimal.js. This caused Closure compiler to fail with JSC_UNDEFINED_VARIABLE for MINIMAL_RUNTIME builds with threading and --closure=1. Add the declarations for both paths: - PTHREADS: inside the existing if(ENVIRONMENT_IS_NODE) block that already imports fs - WASM_WORKERS without PTHREADS: in a new conditional block

NODERAWFS postset used require('node:tty') directly, which breaks in ESM output (.mjs) where require is not available. Extract it into a $nodeTTY library symbol using makeNodeImport, matching the pattern used by $nodePath and other node module imports. This fixes all _rawfs test failures in test-esm-integration and test-modularize-instance.

…terns conflict The name $child_process collides with Closure compiler's node externs (third_party/closure-compiler/node-externs/child_process.js) which declares `var child_process = {};`, causing JSC_VAR_MULTIPLY_DECLARED_ERROR when INCLUDE_FULL_LIBRARY is used with --closure=1.

vogel76 · 2026-04-13T19:47:21Z

@sbc100 what prevents this PR from merge? I suppose all your remarks have been addressed and I fixed them to match your needs or explained used solution. I'd like to have this problem solved soon as our software can be also simplified after this fix.
All tests are passing. We can squash commit at the end if you want - I just left them for better view of done changes.

sbc100 · 2026-04-13T20:58:31Z

@sbc100 what prevents this PR from merge?

Thanks! I do want to land this PR, but there might be a couple more things to address. For example, I'd like to look into #23730 and see if landing that first makes sense.

I'll give this PR another read over now.

We can squash commit at the end if you want - I just left them for better view of done changes.

Thanks. We always squash commit all PRs anyway when land them.

sbc100 · 2026-04-13T21:04:40Z

 }

+function makeNodeImport(module, guard = true) {
+  assert(ENVIRONMENT_MAY_BE_NODE, 'makeNodeImport called when environment can never be node');


Should we have this assert in makeNodeFilePath too maybe?

sbc100 · 2026-04-13T21:16:07Z

+      # MODULARIZE=instance implies EXPORT_ES6 which triggers ESM output.
+      is_esm = self.get_setting('EXPORT_ES6') or self.get_setting('WASM_ESM_INTEGRATION') or self.get_setting('MODULARIZE') == 'instance'
+      if is_esm:
+        has_node_imports = 'import(' in js


This seems like its testing for more than just node imports, but any ES6 import (which might not be a node import I guess.. even though we don't use any today).

How about this:

if 'node' not self.get_setting('ENVIRONMENT'): has_external_imports = 'require(' in js or 'import(' in js self.assertFalse(has_external_import, 'we should not have external imports unless targeting node')

fixup! Add Closure compiler support for ESM dynamic imports Route makeNodeImport through the existing EMSCRIPTEN$AWAIT$IMPORT placeholder mechanism (added by parseTools.preprocess() and reversed by fix_js_mangling()) instead of running a separate regex-based pre/post-Closure pass over the entire JS output. The placeholder identifier is already in src/closure-externs/closure-externs.js, so no extra externs need to be generated. Addresses review comment: emscripten-core#26384 (comment)

fixup! Add require() polyfill for EM_ASM tests in ESM modes Replace the require() polyfill (used to keep EM_ASM blocks calling require('fs')/require('path') working in ESM mode) with direct references to library symbols via EM_JS_DEPS, as suggested by the maintainer. - Add new $nodeFs library symbol in libcore.js (alongside $nodeOs, $nodeChildProcess) so EM_ASM can reference 'nodeFs' directly. - Update test_nodefs_home.c and test_nodefs_rw.c to declare their dependency via EM_JS_DEPS(deps, ...) and use nodePath/nodeFs in place of require(). - Link -lnodepath.js into test_fs_nodefs_home so $nodePath is resolvable (libnodepath.js is otherwise only auto-included for NODERAWFS). - Drop test/require_polyfill.js and the add_require_polyfill helper. - Reuse the existing is_esm() helper in test_no_node_imports. Addresses review comment: emscripten-core#26384 (comment)

…iles fixup! Replace require() with library symbols in EXPORT_ES6 library files Drop the createRequire-based \$nodeRequire polyfill in libsockfs.js and load the 'ws' package directly with await import() at module-init time, as the commit message of c85c69e originally described. Reviewer question (r3075800765): "How/why does libsockfs require 'sync context' whereas other places in the codebase don't? Do we need to update how we use the 'ws' package maybe?" Answer: the call sites at lines 230 (createPeer) and 540 (listen) run as synchronous callbacks from socket syscalls across the JS<->Wasm boundary, so 'await import()' cannot be used at those sites. The createRequire polyfill sidesteps that by exposing a synchronous require() inside an ESM module. But synchronous use is only needed at the call site, not at the point of loading. We can resolve the module asynchronously once at module-init time (where top-level await is available in the MODULARIZE=instance wrapper) and cache it, then reference the cached value synchronously later. 'ws' is a CJS package so the WebSocket class is on the .default export; we bind that to \$nodeWs. This removes the only remaining use of createRequire() and import('node:module') from the PR, and uses the same pattern as \$nodeFs / \$nodePath / \$nodeOs for every other node import. Trade-off: if SOCKFS is linked but the 'ws' package is not installed, the failure now surfaces at module init instead of at first socket use. In practice SOCKFS implies a hard dependency on 'ws', so failing fast is preferable.

…iles fixup! Replace require() with library symbols in EXPORT_ES6 library files Revert the eager $nodeWs((await import('ws')).default) approach from the prior fixup (2642a5d) and restore the createRequire-based $nodeRequire polyfill. Why reverting: the eager approach resolved 'ws' at module-init time, which breaks any program that links SOCKFS but never calls socket ops. The test runner hit this on instance.test_dlfcn_handle_alloc and 18 other tests that pull in SOCKFS transitively: Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'ws' imported from /tmp/emtest_.../main.mjs The createRequire pattern preserves the original CJS-build semantics: require() is wrapped but not invoked until the first socket connect() or listen() call, at which point the user has opted in to actually using WebSockets. Proper reply to the review question (r3075800765) -- "do we need to update how we use the 'ws' package?": The sync context in libsockfs is real -- connect()/listen() are synchronous callbacks invoked from socket syscalls across the JS<->Wasm boundary. We cannot 'await import' at those sites without ASYNCIFY, which is out of scope for this PR. And we cannot pre-load 'ws' at module init either, because 'ws' is a user-installed npm peer-dep; many emscripten programs link libsockets (it is pulled in by socket()/dlfcn/etc.) without ever calling WebSocket ops. Failing the whole program at init just because 'ws' is not installed would be a regression over the CJS build, which only fails if WebSocket ops are actually invoked. createRequire is the minimal viable primitive for this: it gives us a synchronous require() function in an ESM module, scoped via import.meta.url. The 'await import(node:module)' that produces it is on a Node builtin, so it is cheap and cannot fail. The actual ws load stays lazy at the call site, matching CJS behavior. A larger refactor that replaces 'ws' with an async-friendly WebSocket library (or that asyncifies the socket syscall layer) could remove createRequire, but that is a separate change and out of scope here.

…ime files fixup! Replace require() with await import() in EXPORT_ES6 shell/runtime files Drop the per-call `/* webpackIgnore: true */ /* @vite-ignore */` directives from makeNodeImport's generated `await import(...)` expression. Reviewer question (r3075818347): "I won't love having this vender/bundler-specific comments in the code like this. Didn't you say that these bundlers should automatically ignore things with the 'node:' prefix?" Modern webpack 5, vite, and rollup auto-externalize `node:`-prefixed dynamic imports for browser targets. The hints only suppress a "externalized for browser compatibility" warning, which test/vite/vite.config.js already whitelists explicitly for node:* modules. Correctness is unchanged whether the hints are present or not. Verified locally: - other.test_esm_no_require (3 variants) passes. - emcc -sEXPORT_ES6 -sMODULARIZE produces clean `await import('node:fs')` / `node:path` / `node:url` calls with no bundler-specific comment blocks in the output.

…ime files fixup! Replace require() with await import() in EXPORT_ES6 shell/runtime files Revert the bundler-hint removal from 548e32d. It was based on a mistaken assumption that webpack auto-handles `node:`-prefixed dynamic imports -- it does not. CI run on 548e32d hit: test_webpack_esm_output_clean: ERROR in node:fs Module build failed: UnhandledSchemeError: Reading from "node:fs" is not handled by plugins (Unhandled scheme). Webpack supports "data:" and "file:" URIs by default. You may need an additional plugin to handle "node:" URIs. Same error for node:path, node:url. All three show up because without `/* webpackIgnore: true */`, webpack attempts to resolve the dynamic import as a module and fails on the unknown scheme. Vite (per test/vite/vite.config.js) does auto-externalize `node:*` for browser -- emitting a warning that the config already whitelists -- so strictly speaking `/* @vite-ignore */` is optional. But we keep both for symmetry and to also silence vite's dynamic-import analysis noise. Updates the inline comment to explain the requirement so a future reader does not attempt the same simplification again. Addresses and supersedes the response to r3075818347 -- the hints cannot be removed unless we add a webpack plugin or drop support for webpack consumers of EXPORT_ES6 output.

vogel76 changed the title ~~eliminate require~~ Eliminate createRequire/require() from EXPORT_ES6 output Mar 3, 2026

sbc100 reviewed Mar 3, 2026

View reviewed changes

sbc100 requested a review from RReverser March 3, 2026 23:34

sbc100 changed the title ~~Eliminate createRequire/require() from EXPORT_ES6 output~~ Eliminate createRequire/require from EXPORT_ES6 output Mar 4, 2026

vogel76 force-pushed the bw_eliminate_require branch from 0ec991e to 6b74d2a Compare March 4, 2026 23:17

vogel76 force-pushed the bw_eliminate_require branch from 6b74d2a to 8f585b7 Compare March 4, 2026 23:31

sbc100 approved these changes Mar 5, 2026

View reviewed changes

vogel76 force-pushed the bw_eliminate_require branch from 8f585b7 to 6c822be Compare March 5, 2026 22:57

vogel76 mentioned this pull request Mar 9, 2026

Add bundler integration tests verifying EXPORT_ES6 output has no requ… #26419

Closed

vogel76 force-pushed the bw_eliminate_require branch from 2270aac to d068717 Compare March 19, 2026 21:31

sbc100 reviewed Mar 19, 2026

View reviewed changes

Comment thread src/lib/libwasi.js Outdated

vogel76 force-pushed the bw_eliminate_require branch from d068717 to 8b2fb1c Compare March 19, 2026 22:25

sbc100 reviewed Mar 19, 2026

View reviewed changes

Comment thread test/test_other.py Outdated

vogel76 force-pushed the bw_eliminate_require branch from 8b2fb1c to 23863c1 Compare March 19, 2026 23:14

vogel76 force-pushed the bw_eliminate_require branch 2 times, most recently from 30c1f96 to 14fdc3b Compare March 20, 2026 10:48

vogel76 force-pushed the bw_eliminate_require branch from 4528d9a to c4a3967 Compare March 23, 2026 09:35

sbc100 reviewed Mar 23, 2026

View reviewed changes

vogel76 force-pushed the bw_eliminate_require branch 2 times, most recently from 904f790 to c1332e0 Compare March 23, 2026 22:07

Bartek Wrona added 13 commits April 8, 2026 16:04

Rename nodeChildProcess to child_process per reviewer feedback

23d0a46

vogel76 force-pushed the bw_eliminate_require branch from 1236377 to 23d0a46 Compare April 8, 2026 16:56

Bartek Wrona and others added 4 commits April 8, 2026 17:56

Merge branch 'main' into bw_eliminate_require

44f7423

Merge branch 'main' into bw_eliminate_require

b9075a4

Merge branch 'main' into bw_eliminate_require

2c7e271

sbc100 reviewed Apr 13, 2026

View reviewed changes

Comment thread src/lib/libsockfs.js

sbc100 reviewed Apr 13, 2026

View reviewed changes

Comment thread src/parseTools.mjs Outdated

sbc100 reviewed Apr 13, 2026

View reviewed changes

Bartek Wrona added 6 commits April 15, 2026 22:39

Conversation

vogel76 commented Mar 3, 2026 • edited by sbc100 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why this is safe

Approach

Intentionally skipped

What changes in the output

Files modified

Testing

Related issues

Related PRs

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vogel76 commented Mar 4, 2026

Uh oh!

sbc100 commented Mar 5, 2026

Uh oh!

sbc100 commented Mar 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vogel76 commented Mar 5, 2026

Uh oh!

vogel76 commented Mar 9, 2026

Uh oh!

sbc100 commented Mar 9, 2026

Uh oh!

vogel76 commented Mar 9, 2026

Uh oh!

sbc100 commented Mar 9, 2026

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vogel76 commented Mar 19, 2026

Uh oh!

vogel76 commented Mar 20, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vogel76 commented Apr 13, 2026

Uh oh!

sbc100 commented Apr 13, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sbc100 Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

vogel76 commented Mar 3, 2026 •

edited by sbc100

Loading

sbc100 Apr 13, 2026 •

edited

Loading