Fix MDX stack trace location with frontmatter #11717
Conversation
🦋 Changeset detectedLatest commit: b2d30eb The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
github-actions
bot
added
the
pkg: integration
|
|
||
| const vfile = new VFile({ value: pageContent, path: id }); | ||
| const vfile = new VFile({ value: frontmatterLines + pageContent, path: id }); |
There was a problem hiding this comment.
Is there any risk of this being breaking?
There was a problem hiding this comment.
I don't think so, it's only prepending new lines. Do you have something in mind that could break?
There was a problem hiding this comment.
I figured that perhaps a remark/hype plugin could be relying on certain positions, but I guess that's unlikely
There was a problem hiding this comment.
Hmm I guess you're right since the mdast/hast nodes do have offset information, but since they only work upon the vfile.value, it should still be fine. Just that if they return any offset values then it'd be incorrect, but I don't think you'd do so in practice, except in the linked issue where the returned error uses line/col instead of offsets.
We could replace the frontmatter with spaces and new lines, but I think maybe for now new lines could be enough and we can monitor it again.
Fix MDX stack trace location with frontmatter (withastro#11717)
Changes
fix #11707
When we extract the frontmatter with
gray-matterand it returns thecontent, it doesn't include the new lines from the stripped frontmatter, causing the MDX parser to incorrectly pinpoint the location of the error.This PR manually adds the new lines to preserve the location.
Testing
Tested manually. The location is now correct:
Docs
n/a. bug fix.