Skip to content

Use static imports in JS compiler tools - #28117

Open
sbc100 wants to merge 1 commit into
emscripten-core:mainfrom
sbc100:static_imports
Open

sbc100 wants to merge 1 commit into
emscripten-core:mainfrom
sbc100:static_imports

Conversation

@sbc100

@sbc100 sbc100 commented Oct 30, 2026

Copy link
Copy Markdown
Collaborator

Move top-level setting evaluations in src/modules.mjs, src/parseTools.mjs, and src/parseTools_legacy.mjs into explicit initModules(), initParseTools(), and initLegacyParseTools() functions called after applySettings().

This allows tools/compiler.mjs and tools/preprocessor.mjs to use normal top-level import statements instead of dynamic await import() calls.

Avoids a second round of dynamic module resolution at runtime (reducing compiler.mjs's startup phase from ~19 ms to ~5 ms under EMPROFILE=2) and makes the module graph completely static so the tools can be cleanly bundled into single-file outputs without code-splitting boundaries or top-level evaluation order issues.

@sbc100 sbc100 changed the title [JS] Use static imports in JS compiler tools Use static imports in JS compiler tools Oct 30, 2026
@sbc100
sbc100 requested a review from kripken October 30, 2026 23:41

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the initialization logic of several compiler modules (modules.mjs, parseTools.mjs, and parseTools_legacy.mjs) by wrapping top-level side effects into explicit initialization functions (initModules, initParseTools, and initLegacyParseTools). This allows the tools (compiler.mjs and preprocessor.mjs) to use static imports instead of dynamic imports, which were previously used to delay execution until global settings were configured. Regarding the feedback, it is recommended to initialize POINTER_SIZE and POINTER_TYPE to sensible default values (such as wasm32 defaults) in parseTools.mjs to prevent potential undefined errors or test failures in scripts that import the module without explicitly calling initParseTools().

Comment thread src/parseTools.mjs Resolved
…ssor.mjs`

Move top-level setting evaluations in `src/modules.mjs`,
`src/parseTools.mjs`, and `src/parseTools_legacy.mjs` into explicit
`initModules()`, `initParseTools()`, and `initLegacyParseTools()`
functions called after `applySettings()`.

This allows `tools/compiler.mjs` and `tools/preprocessor.mjs` to use
normal top-level `import` statements instead of dynamic `await import()`
calls.

Avoids a second round of dynamic module resolution at runtime (reducing
`compiler.mjs`'s `startup` phase from ~19 ms to ~5 ms under
`EMPROFILE=2`) and makes the module graph completely static so the tools
can be cleanly bundled into single-file outputs without code-splitting
boundaries or top-level evaluation order issues.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant