Esm: Syntax Error when using spread operator inside of exports

[djmadeira]

On node 8.1.4, when I use a spread operator inside of a default export, I get a SyntaxError: Unexpected Token without a useful stacktrace.

Minimal test case can be found in this gist.

[jdalton]

Ah nice @djmadeira!

The object-rest-spread is stage 3 but Node 8 seems to support it. I'll get it added ASAP.

Update:

This is an acorn limitation at the moment. The existing plugin for it is super out-of-date, so not suitable. I've kicked around an acorn plugin implementation but hitting errors so won't get it working tonight.

[boneskull]

I'm also getting some SyntaxErrors which are pretty opaque. Here's an example:

// index.js
require('@std/esm');
require('./main.mjs');

// main.mjs
import {foo} from './bar'; // error

// bar.mjs
export const bar = 'bar';
// (no "foo" export)

The result:

SyntaxError: Module 'bar.mjs' does not provide an export named 'foo'
    at Object.<anonymous> (/path/to/main.mjs)
    at Object.<anonymous> (/path/to/main.mjs)
    at Module._compile (module.js:573:30)

This is more problematic when importing from third-party Node modules, where e.g. index.js is only mentioned, but not which index.js!

[djmadeira]

Agreed, stack traces output by this lib are virtually useless, I had to resort to binary searching which import was breaking things by moving a known broken file up and down in the import order until the error changed 😀.

[jdalton]

@boneskull

SyntaxError: Module 'bar.mjs' does not provide an export named 'foo'

Ah cool I can have it produce the whole file path. That's actually more than the built-in ESM error from v8 at the moment which states

SyntaxError: The requested module does not provide an export named 'foo'

@djmadeira

The stack traces should mimic native. You'll not find the internals of the loader in the trace though as that's not helpful for most. The error like...

/path/to/file.js:4
a = { ... b}
      ^

SyntaxError: Unexpected token
    at Module.load (module.js:507:32)
    at tryModuleLoad (module.js:470:12)
    at Function.Module._load (module.js:462:3)
    at Module.require (module.js:517:17)

..is on par with the built-in experience. However, if you want to unmask the stack traces you can use the "debug":true esm option.

[boneskull]

Ah cool I can have it produce the whole file path.

that'd probably be sufficient. either:

• knowing which line has the bad import, or
• the complete filepath to the requested module

would give developers enough information to debug. doesn't need to be both, though it couldn't hurt!

[jdalton]

I'm going to punt this because it's really an acorn issue.
Take it up with them over at https://github.com/ternjs/acorn/issues/388#issuecomment-322691328.

[jdalton]

@std/esm v0.7.0+ should no longer bork on object rest/spread syntax.