Dynamic import does not show location of SyntaxError

[coreyfarrell]

// syntax-error.mjs
console.log([
  'str1'
  'str2'
]);

Perform a dynamic import with node -e "import('./syntax-error.mjs').catch(console.error)", the output does not help identify the error and could be seen by users as if node.js itself had a SyntaxError:

SyntaxError: Unexpected string
    at Loader.moduleStrategy (internal/modules/esm/translators.js:83:18)
    at async link (internal/modules/esm/module_job.js:37:21)

Now create and run a loader.mjs script:

import './syntax.mjs';

Running loader.mjs produces useful output:

file:///usr/src/npm/failures/syntax-error.mjs:3
	'str2'
	^^^^^^

SyntaxError: Unexpected string
    at Loader.moduleStrategy (internal/modules/esm/translators.js:83:18)

I was not able to find a way to catch the error of a dynamic import and show the complete SyntaxError. Interestingly node --unhandled-rejections=strict -e "import('./syntax-error.mjs')" or running await import('./syntax-error.mjs') from node --experimental-repl-await both display the location of the SyntaxError.

I stumbled upon a scenario where one of my package would dynamically import files and run whatever methods was exported as you can guess I would be having a hard time figuring out where the error comes from when this:

SyntaxError: Unexpected reserved word
    at Loader.moduleStrategy (node:internal/modules/esm/translators:143:18)
    at async link (node:internal/modules/esm/module_job:42:21)

is the only info I am getting.

[egasimus]

This is still the case. Any workarounds for v14.16.0, or is this fixed in v15?

[FossPrime]

This is still the case. Any workarounds for v14.16.0, or is this fixed in v15?

If its just a syntax error... running eslint will catch the issue clearly. Most of this issue is gone... the remaining issue is with Dynamic Imports... which packages like Mocha use. But they worked around it a barely, they only tell you what test doesn't load, not what file caused the error. ESLint really helps, and found the issue with accuracy.

[egasimus]

So, still broken.

[FossPrime]

Or rather, working as intended... which is much faster, but if you are doing dynamic imports... much less clear. Oof, I just realized I should handle my new dynamic imports a bit more clearly. Thanks for the reminder.

[egasimus]

So, still broken.

Or rather, working as intended...

So, NOTABUG WONTFIX then?

[benbucksch]

(For those who missed the sarcasm, I presume that egasimus' last comment was ironic.)

@rayfoss I'm glad that you found a workaround that works for you. However, this is a serious problem for some of us. Your workaround doesn't work for everybody, for various reasons. Diminishing the importance of a bug, after others have expressed that this is a serious problem for them, is generally not a good idea and not productive, and it only serves to create a useless debate without any helpful result. Please refrain from comments like your last comment.

[FossPrime]

Places where this is still a problem:

• If you are using an old version of Mocha, it uses Dynamic imports, but in the latest stable it catches the error and explains what was trying to do.
• If you pipe code into the Node REPL. Currently the best workaround is to import in a loop and explain the error yourself.
• Any other place where you would use dynamic imports

[egasimus]

@rayfoss I started using Mocha today. Here's what 8.4.0 does:

[giltayar]

@egasimus this is because we added coded in Mocha specifically to overcome this error. It's an ugly hack, and we put it there because people were complaining about this, so this is not a theoretical problem. It is out there.

Hack: https://github.com/mochajs/mocha/blob/master/lib/esm-utils.js#L14

[egasimus]

@giltayar I'm fairly certain the syntax error is not in ██████.spec.js at all, but in one of its dependencies. So this workaround does point to the file that triggered the error, but not to the file that actually contains the error. (Not to mention it does not include essential info such as line and column.)

Trying to load the module from the REPL with require says I must use import; therefore, the Node.js runtime gives me no way to find SyntaxError in my code. This is a fairly significant regression and I'm surprised it hasn't gotten more attention.

[giltayar]

@egasimus Totally agree! We did what we could to alleviate the pain, but the pain is there even after our workaround.

[vieiramanda11]

Still facing this issue with Mocha:

> mocha


SyntaxError[ @/Users/amandavieira/Documents/personal-projects/inbox-eth/test/Inbox.test.js ]: Unexpected reserved word
    at Loader.moduleStrategy (internal/modules/esm/translators.js:140:18)
    at async link (internal/modules/esm/module_job.js:42:21)

Any idea how can I solve this?

[forivall]

#49441 - file was moved, link is now
https://github.com/mochajs/mocha/blob/master/lib/nodejs/esm-utils.js

[Turbine1991]

Yikes, how is this still not resolved. This is of paramount importance in the node world.

[egasimus]

Yikes, how is this still not resolved. This is of paramount importance in the node world.

✔️

This comment was marked as abuse.

🤦

There's a vast difference between "emotionally highlighting the importance of something that is frustrating" and "abuse".

Please take a moment to consider this distinction.

@Turbine1991's comment is clearly the former; marking it as "abuse" actually borders on the latter (gaslighting).

I understand that nobody is entitled to maintainers' time, and impacted users are always free to solve the issue themselves and submit a pull request.

However, contributing to a large and critical project such as Node.js is outside most downstream developers' comfort zone; the least the Node.js team could do is acknowledge this and not dismiss honest reactions as "abuse".

[benbucksch]

This is of paramount importance in the node world.

This bug is so bad that I have to warn third party developers in our documentation about it. (See end of page https://docs.parula.app/develop/app/create-the-stub-files )

[GeoffreyBooth]

This bug is so bad that I have to warn third party developers in our documentation about it.

You could also submit a pull request to fix it!

[adrian-balan-mindit]

any status on this bug ?

[rdev06]

any update on this bug?

[nicolo-ribaudo]

If there was an update, there would either be a comment here containing the update or a linked PR. That's how GitHub works, and asking if there is any update is just annoying to people that have notification for the issue enabled.

[github-actions]

This 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.

[EricMCornelius]

Still relevant.

[github-actions]

This issue has been marked as stale due to 90 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.

[EricMCornelius]

Still relevant.