๐ BUG: Slots are always processed inside markdown files and `is:raw` doesn't work
What version of astro are you using?
v1.0.0-beta.42
Are you using an SSR adapter? If so, which one?
None
What package manager are you using?
npm
What operating system are you using?
Linux
Describe the Bug
In a markdown file, i'm trying to pass text slot to a component and it's all time processed by markdown processor!
<Code>
# this should not be converted!
</Code>
Slot returns:
<h1 id="this-should-not-be-converted">this should not be converted!</h1>

is:raw doesn't work inside markdown components (<Code is:raw>). I think it should! It is ignored and sometimes even make the other markdown parts crash, which is really weird.
I think is really important to have a directive or a way to pass slot text without transformations
Link to Minimal Reproducible Example
https://codesandbox.io/s/bold-austin-xbqrn7?file=/src/post.md
Participation
- [ ] I am willing to submit a pull request for this issue.
A terrible workaround is to disable syntaxHighlight in astro.config.ts and then use code fences like:
<Code>
ยดยดยด <-- using opposite ticks because of GitHub comments parser
# this should not be converted!
ยดยดยด
</Code>
so it produces...
<pre><code is:raw># this should not be converted!
</code></pre>
And then you need: const pureTextSlot = (await Astro.slots.render('default')).slice(18, -14):
# this should not be converted!
My eyes hurt xD
@hippotastic might be able to tackle this pretty quickly?
MDX will always process the contents of components as Markdown as per the MDX spec. The only way to avoid this currently is to enclose the contents in an MDX expression like so:
<Code>
{`
# This is pure text, not markdown
No *inline formatting* either.
`}
</Code>
Please note that in this workaround, the newlines before and after the outer Card tags are important. If you remove them, you will most likely get a parser error.
Regarding the initial idea of the is:raw directive, I agree that this would be a great thing to have in Markdown!
I'm currently working on a preprocessing step to support HTML comments, and as soon as I get this working, I could also add support for a directive like is:raw. Setting it on a container would then cause its contents to be treated as plain text without any Markdown processing (so, just like HTML comments). Great idea!
I'll keep you updated when I could add this feature! It won't be happening "quickly" though, as the preprocessing is a really complex endeavor and needs to be well tested.
I'll keep you updated when I could add this feature! It won't be happening "quickly" though, as the preprocessing is a really complex endeavor and needs to be well tested.
Just an idea: In this case, maybe Astro can internally just add the {ยด .... ยด} thing when is:raw is present? Or maybe it's preferred another solution
Just an idea: In this case, maybe Astro can internally just add the
{ยด .... ยด}thing whenis:rawis present? Or maybe it's preferred another solution
I wish it were always that easy! Unfortunately we'd also need to add the newlines around the container tags, and depending on the current Markdown flow state (lists, blockquotes, other tags), this can cause MDX parsing errors. I've prepared a huge array of test cases and this has made clear that we need to understand the document structure first before being able to apply autofixes/changes like that.
Just an idea: In this case, maybe Astro can internally just add the
{ยด .... ยด}thing whenis:rawis present? Or maybe it's preferred another solutionI wish it were always that easy! Unfortunately we'd also need to add the newlines around the container tags, and depending on the current Markdown flow state (lists, blockquotes, other tags), this can cause MDX parsing errors. I've prepared a huge array of test cases and this has made clear that we need to understand the document structure first before being able to apply autofixes/changes like that.
Ups. This thing {ยด .... ยด} causes an issue. What if you want to showcase an example about JSX? Code example probably contains that, and you now need to escape it every time!
<Code>
{`
example={\`foo\`}
`}
</Code>
This scales quickly xD
Yep. Just another problematic case and already one of my test cases. ๐
Unfortunately you will have to live with one of the possible workarounds until we could add the preprocessing. This is just how MDX works. Sorry about that!
Thanks for weighing in @hippotastic! Excited to see this added to the test cases. Let me know how I can help.
Closing since this is a legacy markdown issue. Try using the Code component in MDX for this use case!