-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mdsvex.compile(content, options)
adds extra {@html
and }
wrapper for no reason
#392
Comments
alright this works: compile(`
\`\`\`js
let foo = 123
\`\`\`
`).then(x => console.log(x.code
.replace(/>{@html `<code class="language-/g, '><code class="language-')
.replace(/<\/code>`}<\/pre>/g, '</code></pre>');
)) but its ugly af of course |
Another way to work around this would be to use a custom highlight function, it may be possible to expose the internal highlight function that produces the correct markup without the Or maybe I could expose a |
ah i see. if compile returns a Svelte component its not very obvious to me how to consume it from within a svelte app. do i use hmm.. when i try |
Yeah this is trickier. It also returns an uncompiled svelte component so needs to be compiled by svelte too (and any imports would need to be resolved), you'd also need some and SSR versions of the component. I think using vites glob imports might work in this case, as I think you get both the SSR and dom mode components that way. But not sure how nicely that would play with kit routes. And the final option would be to just generate an SSR version of the component (if it is all static markdown) and then you could inject the html that is returned from |
Of course this all far too complicated for a pretty common use case, so I need to improve this story a bit here. There are some technical details that can't be avoided but I'm certain there are DX improvements that can be made. I just haven't had time to explore this thoroughly enough so far. |
ok gotcha thank you for understanding. i think i should be able to compile it with svelte serverside. will try another day agree that this is a common enough usecase that it should be addressed first class eventually |
@felixsanz see my solution in swyxkit |
Thanks @sw-yx for the temporary solution, feels dirty though. Any edge cases where this might not work? |
Useful but ugly. Thanks @sw-yx |
@williamviktorsson you tell me haha |
So far so good lol 😂 |
Adding this as a comment as I've tried to use When I use @swyxio's solution then render the generated code (I'm trying to do this while using custom components) I get a whole The use case is I'm writing a blog that has accompanying code snippets which are used to
My approach to this has been to dynamically // +page.ts
// in load
sketch = await import(`../sketches/${params.slug}.ts`);
description = await import(`../sketches/${params.slug}.md`);
return {
sketch: sketch.default,
Description: description.default,
}; Which I then render in my page as // +page.server.ts
// in load
const formattedSource = await prettier.format(fs.readFileSync(filePath, "utf-8"));
// Transpile to JS so it's easier for readers to paste into p5.js web editor and run it.
const jsSource = await esbuild.transform(strippedSource, {
loader: 'ts',
});
const mdx = await compile('```js\n' + jsSource.code + '\n```', mdsvexConfig); // imported from mdsvex.config.js.
return mdx.code // @swyxio's workaround.
.replace(/>{@html `<code class="language-/g, '><code class="language-')
.replace(/<\/code>`}<\/pre>/g, '</code></pre>'); Any idea if there's a simpler solution to this or how to further compile it into a proper Svelte component? I tried |
in here: https://github.com/sw-yx/swyxkit
this section https://swyxkit.netlify.app/welcome#setup
this {@html seems to be injected by mdsvex. i presume its how mdsvex injects itself in normal operation, but the usecase for
.compile
users seems to be overlooked.right now i'm thinking of just using regex to take it out but ofc would be nice to fix at source
simple repro
run
inside the node env, do:
the result is
'<pre class="language-js">{@html
let foo = 123
}</pre>\n'
which has the extra {@html stuff
The text was updated successfully, but these errors were encountered: