Add file, positional info to crashes in webpack loader

[Twipped]

The error output from webpack when there's a flaw in a file was basically unusable:

Error: Module build failed (from ./node_modules/@mdx-js/loader/index.cjs):
Could not parse expression with acorn: Unexpected token
Module build failed (from ./node_modules/@mdx-js/loader/index.cjs):
Could not parse expression with acorn: Unexpected token

This PR adds a bit to the error message so that you can tell what actually caused the error:

Error: Module build failed (from ./node_modules/@mdx-js/loader/index.cjs):
Could not parse expression with acorn: Unexpected token while parsing /path/to/file1.mdx:19:1
Module build failed (from ./node_modules/@mdx-js/loader/index.cjs):
Could not parse expression with acorn: Unexpected token while parsing /path/to/file2.mdx:22:3
Module build failed (from ./node_modules/@mdx-js/loader/index.cjs):
Could not parse expression with acorn: Unexpected token while parsing /path/to/file3.mdx:14:5

Apologies that I didn't update any tests for this, I couldn't find a type definition for the error anywhere and couldn't figure out how to make type-coverage stop failing so that I could actually run the tests.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
mdx	✅ Ready (Inspect)	Visit Preview	Sep 6, 2022 at 11:30PM (UTC)

[wooorm]

couldn't find a type definition for the error anywhere

That’s the thing with errors: they can be anything. Any user, plugin, engine, could throw anything.
In this case, it’s a vfile-message. I believe a VFileMessage is exposed from vfile.

I could actually run the tests.

That’s the beauty of TS through JSDoc: the code still runs even if TypeScript doesn’t understand the code. npm run test-api runs just unit tests.

[wooorm]

Btw, you should be able to take error.name? That should equal your 3:4 (line:column) format.
Should also be possible to take error.file to get the file path?

I think I’d prefer the format: path/to/file.mdx:3:4: Some problem: that particularly helps reading error reasons that are very long.

Most runtimes as far as I remember show these fields in front of errors, I dunno why webpack doesn’t do that? Are they preventing that somehow? 🤷‍♂️

[Twipped]

@wooorm Thank you, it was actually in the vfile-message module. Tests and types are now updated. I went ahead and added assertions for the other webpack runs, since webpack doesn't actually provide an error on the callback, so the promise never rejects.

error.file was an empty string, and error.name only had the line numbers, so I used a relative path from the webpack context.

Most runtimes as far as I remember show these fields in front of errors, I dunno why webpack doesn’t do that? Are they preventing that somehow?

Webpack only outputs the error message property, everything else gets lost.

[wooorm]

I went ahead and added assertions for the other webpack runs, since webpack doesn't actually provide an error on the callback, so the promise never rejects.

Thanks for that!

---

Looks great!

[wooorm]

Released in 2.1.4! https://github.com/mdx-js/mdx/releases/tag/2.1.4