Dynamic import does not show location of SyntaxError #49441

coreyfarrell · 2020-01-16T11:13:59Z

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

The text was updated successfully, but these errors were encountered:

jkrems · 2020-01-16T16:18:34Z

This is something we unfortunately inherited from Chrome/V8. You can try the following in the browser devtools:

await import('data:text/javascript,<not valid syntax>')

We may be able to patch the stack even further. The main issue is that import() actually makes these errors easily observable. So the fact that err.stack is "weird" and doesn't properly start with the usual prefix would leak.

ljharb · 2020-01-16T16:51:38Z

That leak will pose a problem as the error stacks proposal attempts to advance; it would be exceedingly ideal to avoid creating new observable stack trace formats/contents.

jkrems · 2020-01-16T17:04:41Z

One thing I'd love to see is to have syntax errors from module executions include the parsed module as the top frame. But I can understand why that may be awkward (there's no actual stack frame running that code).

ljharb · 2020-01-16T17:05:44Z

My primary concern is avoiding new kinds of traces; id rather see no error than a new kind of error. A very close second is seeing useful ones :-)

jkrems · 2020-01-16T17:10:59Z

Somewhat OT: The above stack traces are a great reason to invest into moving even more of the loader into C++. None of these frames are remotely helpful to understand what's going on:

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

Compared with the - theoretical - error showing the syntax error location as the top frame and without any JS frames from loader internals:

SyntaxError: Unexpected string
    at file:///path/to/project/syntax-error.mjs:4:2

addaleax · 2020-01-16T17:16:00Z

@jkrems If the issue is that there are C++ frames in the middle of a stack, cutting it off at some point, I’d prefer to come up with a solution that provides the full stack trace rather than moving more code into C++…

jkrems · 2020-01-16T17:31:47Z

I think to me it's related to a direct comparison with browser stacks which is "suddenly" a thing for modules. With most other APIs (from setTimeout() to require()), there's user code calling JavaScript functions. So seeing JS frames of node's implementation doesn't feel too weird to me.

But module execution feels different. I didn't create a module job, I ran a file. In the browser, it wouldn't show me stack frames from network requests and other kinds of orchestration needed to run the file. So seeing that in node appears inconsistent.

addaleax · 2020-01-16T17:40:33Z

@jkrems Right, but I feel like “move code to a different language” is ultimately not a good solution to stack traces not being pretty enough – I’d rather find a way to provide better stack traces. In my opinion, we already have far too much module-related C++ code that would be more accessible when written in JS.

GeoffreyBooth · 2020-01-16T17:52:57Z

It’s always annoyed me that Node internals appear in stack traces. I wish we could just filter them out, or blackbox them, maybe by default which could be changed via a flag.

jkrems · 2020-01-16T17:56:29Z

@addaleax That's definitely fair. Maybe what's missing is some API that allows us to start module execution with a "fresh stack" even when there's technically active JS frames. Feels like something that'd need V8 support if they would also appear "properly" within the module execution itself (try/catch)..?

It’s always annoyed me that Node internals appear in stack traces. I wish we could just filter them out, or blackbox them, maybe by default which could be changed via a flag.

@GeoffreyBooth I generally disagree. Seeing frames for the express subclass of http.Server but not for the parts that happen to be from the base class feels super confusing. In most cases having node's own code appear is pretty valuable imo.

ljharb · 2020-01-16T18:01:18Z

The function implementation hiding proposal, which allows functions to opt out of stack frames, may provide a JS-native solution to this problem.

jkrems · 2020-01-16T18:05:28Z

The function implementation hiding proposal, which allows functions to opt out of stack frames, may provide a JS-native solution to this problem.

Maybe. Though it feels a bit brittle. I assume it would mean that we'd have to manually hide each individual function that makes up our implementation and be careful that we never have Array.forEach & friends on the stack. Possible but a bit too easy to break by accident for my taste.

coreyfarrell · 2020-01-20T17:45:46Z

I can understand arguments for and against node.js internals appearing in the stack, but that's not why I opened this issue. My concern is not so much the extra information, it's the lack of necessary information. Filtering out node.js internals will not tell me where the syntax error occurred. Normally I use a linter but in some cases when testing a specific issue I might run the tests manually and bypass the lint step (that's how I found this issue).

I know @jkrems suggested that this could be a v8 issue but I find it interesting that REPL top-level await and strict unhandled rejections both display the necessary information. This tells me that the information exists as part of the error object at some point. Seems like that information can only be displayed by the default uncaughtException handler?

function example() {
  throw new Error('example');
}

if (process.env.CATCH_ERROR) {
  try {
    example();
  } catch (error) {
    console.error(error);
  }
} else {
  example();
}

Running this with CATCH_ERROR=1 removes the source output though in this example it's less of an issue as the stack trace contains a line referencing the location of throw in example().

jkrems · 2020-01-20T18:03:25Z

Yes, it can “always” appear on crashes and that’s definitely a good improvement. The issue is that it won’t appear on things that don’t crash or where errors are sent to reporting tools (e.g. log files). Making it part of the default unhandled rejection logging is a good quick fix though!

benbucksch · 2020-05-23T13:08:59Z

This bug is a big obstacle for me during development. I need to load apps dynamically, so any syntax error in any of my code will now not show anymore. It's very difficult to find errors without knowing where exactly the error is. This is completely unworkable.

My workaround is to manually add hardcoded import statements to the files that I develop on at a given time. But that's cumbersome, tedious, and I need to do it manually every time. All the time. And this is only after I found the cause of why the stack is wrong. Many other developers would not even know why the stack is mis-attributing and would just tear their hairs without ever knowing why it failed.

As @coreyfarrell said, because stacks are so important, even async/await processing impl found some way to preserve the stack, so I assume there must be some kind of workaround possible for this problem as well.

This bug here is a serious problem for any usage of import().

ghost · 2020-10-25T21:47:24Z

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 · 2021-03-23T10:59:06Z

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

FossPrime · 2021-05-07T20:04:40Z

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 · 2021-05-10T08:10:23Z

So, still broken.

FossPrime · 2021-05-10T21:09:32Z

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 · 2021-05-11T11:41:48Z

So, still broken.

Or rather, working as intended...

So, NOTABUG WONTFIX then?

benbucksch · 2021-05-11T13:59:45Z

(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 · 2021-05-11T16:32:20Z

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 · 2021-06-02T05:06:14Z

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

giltayar · 2021-06-02T05:47:56Z

@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 · 2021-06-02T05:58:02Z

@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 · 2021-06-02T06:23:52Z

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

vieiramanda11 · 2021-10-29T16:29:55Z

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 · 2021-11-01T18:39:53Z

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

- it gives this weird error: SyntaxError: Unexpected reserved word at Loader.moduleStrategy (internal/modules/esm/translators.js:140:18) at async link (internal/modules/esm/module_job.js:42:21) - found these issues; should debug further: - nodejs/node#32177 - https://github.com/nodejs/modules/issues/471

egasimus · 2023-06-28T13:44:04Z

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 · 2023-06-29T01:13:16Z

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 · 2023-06-29T01:37:20Z

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 · 2024-08-13T11:00:35Z

any status on this bug ?

coreyfarrell mentioned this issue Mar 10, 2020

No stack trace with missing async keyword and dynamic imports #32177

Open

joeduffy mentioned this issue Aug 21, 2020

Support top-level await in Node.js pulumi/pulumi#5161

Closed

This was referenced Jan 19, 2021

If one among multiple ESM tests has a syntax error, then Mocha doesn’t report which one mochajs/mocha#4551

Closed

Show where syntax error from with ESM mochajs/mocha#4558

Closed

PyvesB mentioned this issue Jun 20, 2021

Migrate from CommonJS to ESM badges/shields#6651

Merged

jric mentioned this issue Mar 17, 2022

unhelpful error messages while using asynch in before() mochajs/mocha#4850

Closed

4 tasks

fisker mentioned this issue Apr 26, 2022

Show details when error occurred during loading test files nicolo-ribaudo/jest-light-runner#27

Open

SimenB mentioned this issue Apr 27, 2022

[Bug]: regression in v28 jestjs/jest#12759

Closed

This comment was marked as abuse.

Sign in to view

GeoffreyBooth transferred this issue from nodejs/modules Sep 1, 2023

GeoffreyBooth added promises Issues and PRs related to ECMAScript promises. errors Issues and PRs related to JavaScript errors originated in Node.js core. esm Issues and PRs related to the ECMAScript Modules implementation. labels Sep 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Dynamic import does not show location of SyntaxError #49441

Dynamic import does not show location of SyntaxError #49441

coreyfarrell commented Jan 16, 2020

jkrems commented Jan 16, 2020 •

edited

Loading

ljharb commented Jan 16, 2020

jkrems commented Jan 16, 2020 •

edited

Loading

ljharb commented Jan 16, 2020

jkrems commented Jan 16, 2020 •

edited

Loading

addaleax commented Jan 16, 2020

jkrems commented Jan 16, 2020 •

edited

Loading

addaleax commented Jan 16, 2020

GeoffreyBooth commented Jan 16, 2020

jkrems commented Jan 16, 2020

ljharb commented Jan 16, 2020

jkrems commented Jan 16, 2020

coreyfarrell commented Jan 20, 2020

jkrems commented Jan 20, 2020

benbucksch commented May 23, 2020 •

edited

Loading

ghost commented Oct 25, 2020 •

edited by ghost

Loading

egasimus commented Mar 23, 2021

FossPrime commented May 7, 2021

egasimus commented May 10, 2021

FossPrime commented May 10, 2021

egasimus commented May 11, 2021 •

edited

Loading

benbucksch commented May 11, 2021 •

edited

Loading

FossPrime commented May 11, 2021

egasimus commented Jun 2, 2021 •

edited

Loading

giltayar commented Jun 2, 2021

egasimus commented Jun 2, 2021

giltayar commented Jun 2, 2021

vieiramanda11 commented Oct 29, 2021

forivall commented Nov 1, 2021 •

edited

Loading

This comment was marked as abuse.

egasimus commented Jun 28, 2023 •

edited

Loading

benbucksch commented Jun 29, 2023

GeoffreyBooth commented Jun 29, 2023

adrian-balan-mindit commented Aug 13, 2024

Dynamic import does not show location of SyntaxError #49441

Dynamic import does not show location of SyntaxError #49441

Comments

coreyfarrell commented Jan 16, 2020

jkrems commented Jan 16, 2020 • edited Loading

ljharb commented Jan 16, 2020

jkrems commented Jan 16, 2020 • edited Loading

ljharb commented Jan 16, 2020

jkrems commented Jan 16, 2020 • edited Loading

addaleax commented Jan 16, 2020

jkrems commented Jan 16, 2020 • edited Loading

addaleax commented Jan 16, 2020

GeoffreyBooth commented Jan 16, 2020

jkrems commented Jan 16, 2020

ljharb commented Jan 16, 2020

jkrems commented Jan 16, 2020

coreyfarrell commented Jan 20, 2020

jkrems commented Jan 20, 2020

benbucksch commented May 23, 2020 • edited Loading

ghost commented Oct 25, 2020 • edited by ghost Loading

egasimus commented Mar 23, 2021

FossPrime commented May 7, 2021

egasimus commented May 10, 2021

FossPrime commented May 10, 2021

egasimus commented May 11, 2021 • edited Loading

benbucksch commented May 11, 2021 • edited Loading

FossPrime commented May 11, 2021

egasimus commented Jun 2, 2021 • edited Loading

giltayar commented Jun 2, 2021

egasimus commented Jun 2, 2021

giltayar commented Jun 2, 2021

vieiramanda11 commented Oct 29, 2021

forivall commented Nov 1, 2021 • edited Loading

This comment was marked as abuse.

egasimus commented Jun 28, 2023 • edited Loading

benbucksch commented Jun 29, 2023

GeoffreyBooth commented Jun 29, 2023

adrian-balan-mindit commented Aug 13, 2024

jkrems commented Jan 16, 2020 •

edited

Loading

jkrems commented Jan 16, 2020 •

edited

Loading

jkrems commented Jan 16, 2020 •

edited

Loading

jkrems commented Jan 16, 2020 •

edited

Loading

benbucksch commented May 23, 2020 •

edited

Loading

ghost commented Oct 25, 2020 •

edited by ghost

Loading

egasimus commented May 11, 2021 •

edited

Loading

benbucksch commented May 11, 2021 •

edited

Loading

egasimus commented Jun 2, 2021 •

edited

Loading

forivall commented Nov 1, 2021 •

edited

Loading

egasimus commented Jun 28, 2023 •

edited

Loading