Open remcohaszing opened 6 months ago
Sure, PR welcome!
I was also looking for the meta information from the code fence (the fileName="hello.js"
part), and I found that there is code that already handles the node.data.meta
to some degree:
But it only parses the meta string and passes the props if a custom parseMetaString
is specified, as shown in the tests:
eg. I was able to get pre.props.fileName
to appear by configuring like this:
next.config.js
export default withMDX({
options: {
remarkPlugins: [],
rehypePlugins: [
[
rehypeShiki,
{
theme: 'dark-plus',
addLanguageClass: true,
parseMetaString: (str) => {
return Object.fromEntries(
str.split(' ').reduce((prev, curr) => {
const [key, value] = curr.split('=');
const isNormalKey = /^[A-Z0-9]+$/i.test(key);
if (isNormalKey) prev = [...prev, [key, value || true]];
return prev;
}, []),
);
},
},
],
],
},
})(config);
Would it be an acceptable smaller change to set parseMetaString()
to this function from the tests by default, if it's not specified in the config?
I don't mean to invalidate the idea of keeping .data
and .properties
around for interop - I think that should be done as a separate change too.
Clear and concise description of the problem
With
remark-rehype
/ MDX, the following markdown:Given this has, Shiki replaces the
pre
element with a newly generatedpre
element. In this process the node’sdata
andproperties
are lost. It would be nice if Shiki keeps this information, so that other rehype plugins, such asrehype-mdx-code-props
can use it. Likewise it could even be useful to preserve positional information, which is used for example by React devtools.Suggested solution
It looks like some logic is needed in https://github.com/shikijs/shiki/blob/main/packages/core/src/code-to-hast.ts to be able to handle an existing
pre
andcode
element.Alternative
No response
Additional context
No response
Validations
Contributes