Expose RawDocumentData on vFile data field for Markdown/MDX Files
#192
Milestone
Comments
Saeris
added a commit
to Saeris/contentlayer
that referenced
this issue
Apr 26, 2022
Implementation for the request in contentlayerdev#192 that also partially solves for contentlayerdev#11. In `@contentlayer/core` I added a new `data` field to the options argument of `markdownToHtml` and `bundleMDX` which can be used to pass arbitrary data to the resulting document's `vFile` `data` property. Not knowing how you want to structure utility functions for this library, in the initial implementation I've inlined the `addRawDocumentMeta` remark plugin used to append the vFile inside of both `markdownToHtml` and `bundleMDX`. Please advise me if you'd like this extracted out to somewhere else instead. In this PR I've only updated the `mapping.ts` file for the `source-files` package, as I'm unsure whether other sources like `source-contentful` expose the same `RawDocumentData` that the filesystem source does. Other sources can pass whatever document metadata is pertinent to them to the markdown processors using this addition to their APIs.
|
This should be addressed with the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be useful to expose metadata about the raw source files in the vFile
datafield so that it can be accessed inside of Remark/Rehype plugins. The data that came to mind is the from the document_rawproperty specified here, which includes the source file name and directory, which currently gets lost in processing.Taking a look at the vFile data we get now, all we have is the content string, the current working directory, and the filepath given in the
historyfield appears to be a combination of thecwd, thecontentDirPath, and a generated filename (ex:_mdx_bundler_entry_point-<hash>.mdx). This isn't very useful to us since some important data is lost, namely the full file path and name.For my specific case, I'd like to transform relative image URLs using
@jsdevtools/rehype-url-inspectorto absolute file paths, then withrehype-img-sizeI can extract image width + height data. This would help me usenext/imageto further process raw images. Given the source file's location, I can construct the correct relative path for the linked images myself.How this could be done is with a default unified plugin, such as:
And add it to the plugins lists here and here.
As for how the
_rawmetadata gets injected, I'm unsure how that can be done since I'm having difficulty understanding the codebase. Otherwise I'd open a PR to implement this myself.Seems like this could help with #11
The text was updated successfully, but these errors were encountered: