Repository navigation
No source info available for syntax error caused during dynamic import #45862
Description
Activity
@nodejs/modules
- addedesmIssues and PRs related to the ECMAScript Modules implementation.Issues and PRs related to the ECMAScript Modules implementation.
on Dec 14, 2022 If you host those two files locally and open one in Chrome, what does the browser version of this error look like?
If you host those two files locally and open one in Chrome, what does the browser version of this error look like?
The browser seems to figure out the source position info. This is what I see in the console:
########## Error! SyntaxError: Unexpected identifier 'boop' (at other.mjs:4:6)The source position is clickable in the Chrome UI and indeed links to the expected line/column. Strangely to me (though I suspect not to you all), the source position info does not seem to be present at all in the actual
Errorobject (based on what is reported byObject.getOwnPropertyDescriptors()).I'm also getting this error, can't find the cause due to no info:
SyntaxError: Unexpected token '.' at ESMLoader.moduleStrategy (node:internal/modules/esm/translators:119:18) at ESMLoader.moduleProvider (node:internal/modules/esm/loader:468:14) at async link (node:internal/modules/esm/module_job:68:21)node 18.x. Can't open execute this in Chrome, since it's a server-side nodejs app with fastify.
@mariusa ICYI, I imperfectly work around this problem in my project right now like this:
If I see a
SyntaxErrorfrom a loaded file, Ifork()a Node subprocess just to try to load the failed file as a main script, capturing that subprocess's output to relay back as error output from the main process.@mariusa you need babel config
refer my sample poc on it https://github.com/JSDUNIYA/server-side-render-react-app/blob/main/babel.config.js
With node 24 no improvement. I have no idea how to locate this error in a large project:
SyntaxError: Unexpected token ':' at compileSourceTextModule (node:internal/modules/esm/utils:357:16) at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:109:18) at #translate (node:internal/modules/esm/loader:562:20) at afterLoad (node:internal/modules/esm/loader:612:29) at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:617:12) at #createModuleJob (node:internal/modules/esm/loader:641:36) at #getJobFromResolveResult (node:internal/modules/esm/loader:353:34) at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:318:41)github-actions commented
on Jun 23, 2026 on Jun 23, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jun 23, 2026 github-actions commented
on Jul 24, 2026 on Jul 24, 2026 – with GitHub ActionsContributorMore actionsThis issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Version
v19.2.0
Platform
Darwin chug.lan 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:29 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T8101 arm64
Subsystem
ESM (presumably)
What steps will reproduce the bug?
Make a fresh directory with the two files shown here,
main.mjsandother.mjs, and then runmain.mjs. Here's a convenient script to make the files and then run Node:How often does it reproduce? Is there a required condition?
Consistently reproducible. No conditions required AFAIK.
What is the expected behavior?
Error thrown which contains the usual text that allows for easy identification. The output from this example would be something like this:
or, arguably nicer, something like this:
What do you see instead?
Additional information
I did notice apparently-related issue #17277 and PR #17281, which I would have thought addressed this issue, but I guess not.