grammyjs
add preliminary support for shiki-twoslash
We are having the formatting problem again. Could you run deno fmt here?
CI fails due to OOM. We cannot build and publish the site like that. Do you have any idea how to fix this?
CI fails due to OOM. We cannot build and publish the site like that. Do you have any idea how to fix this?
I was hoping you would know 😅
But I'll take a look later today
🚀 Deployed on https://631d3964734bf1378e3a8ee9--grammy.netlify.app
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
It appears the vite build is indeed very memory hungry, and adding shiki-twoslash to that mix increased the memory consumption even more. I've tried every solution pointed in https://github.com/vitejs/vite/issues/2433, but the only thing that really worked was to increase the heap size limit It's ugly, but does get the job done
- That's no Markdown rendering in the code tooltips. I assume this isn't easily possible?
I haven't found an option to enable this with shiki, but it should be possible somehow. We could, for example, get the highlighted shiki code, extract the tooltips (they most likely have a class name) and pass it manually through markdown-it.
- I would prefer to update the entire website and all code examples at the same time, rather than migrating slowly and being in an inconsistent state for a long time. It may be better to open a new PQ for that. Therefore I'd merge the config only from here.
I have one concern about this, which is build time. While working on getting things to work, I implemented this in a way that enabled twoslash for every code block, unless opted out. When I did that, tho, the vuepress build process just froze. I didn't wait to see how much time it'd take to finish, but it is enough to raise the concern. Though, like we talked about in the telegram group, not every code block will actually benefit from this, so maybe we enable it only when it makes sense?
We'll have to try this. Usually, the process should never freeze completely, as there's always logging output.
We could, for example, get the highlighted shiki code, extract the tooltips (they most likely have a class name) and pass it manually through markdown-it.
This sounds like too much work. I'd just leave it for now.
I don't really see this happening anytime soon, and I also don't think that a few type annotation are worth the complexity that it would take to get this through. Closing.
If you ever feel like picking it up again, feel free to reopen.