You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is being worked on for v1, but I wrote it here so we could possibly address it for v1.
Currently, there are "two issues" preventing shiki from being used indiscriminately on NextJS (or any other modern framework that uses webpack) on the client, build, or server (CSR, SSR, SSG, ISR) as pointed out in #138 (comment). The "plug and play" way without any modification is forcing the Highlighter to be run on "build-time, on server" (aka SSG as seen in this example https://github.com/shikijs/next-shiki/blob/main/pages/index.tsx), but this heavily restricts ISR and dynamic content.
The "two issues":
1. async components
is not compatible (as of React 18.2) on client; through the use of suspense and useEffect, we could get around it and create a component such as <ShikiHighlighter lang="html"> but this hurts SEO since the initial state would be empty. If a react component would be designed, it should cater to run indiscriminately on build, server, and client.
Essentially, DX would be optimal if we have a method called getHighlighterSync. However, this opens up another issue: _fetchAssets.
2. untraceable _fetchAssets
to deterministically bundle required assets with webpack or included with https://github.com/vercel/nft. This prevents the necessary theme and lang from being loaded due to missing files via fs.promise.readFile or unbundled import bundled. We cannot load the Highlighter without customizing the loader architect (setCDN, paths: {}) to load seamlessly on the server or client.
Some ideas: Maybe we could convert _fetchAssets to a non-promise and allow the assets to be bundled or traceable by
including 1 default theme and top 10 languages for the default bundled Highlighter (using require() or import instead of node:fs). This would result in at least 1 MB of assets with a default bundled shiki
or upstream to pick the theme and language they will need and import them import { CssVariable } from 'shiki/themes' and tree shaking away the rest in production
The text was updated successfully, but these errors were encountered:
Hey, I think this would also improve esbuild/Vite bundling since dynamic imports aren't working in pre-bundling here. See also Iconicons issue: ionic-team/ionicons#1032 which now requires addIcons to manually inject them
Currently, there are "two issues" preventing
shiki
from being used indiscriminately on NextJS (or any other modern framework that uses webpack) on the client, build, or server (CSR, SSR, SSG, ISR) as pointed out in #138 (comment). The "plug and play" way without any modification is forcing the Highlighter to be run on "build-time, on server" (aka SSG as seen in this example https://github.com/shikijs/next-shiki/blob/main/pages/index.tsx), but this heavily restricts ISR and dynamic content.The "two issues":
1.
async
componentsis not compatible (as of React 18.2) on client; through the use of
suspense
anduseEffect
, we could get around it and create a component such as<ShikiHighlighter lang="html">
but this hurts SEO since the initial state would be empty. If a react component would be designed, it should cater to run indiscriminately on build, server, and client.Essentially, DX would be optimal if we have a method called
getHighlighterSync
. However, this opens up another issue:_fetchAssets
.2. untraceable
_fetchAssets
to deterministically bundle required assets with webpack or included with https://github.com/vercel/nft. This prevents the necessary theme and lang from being loaded due to missing files via
fs.promise.readFile
or unbundledimport bundled
. We cannot load the Highlighter without customizing the loader architect (setCDN
,paths: {}
) to load seamlessly on the server or client.By injecting the known Grammar and Theme for my PR fuxingloh/crypto-frontmatter#39, I could get around the bundling issue:
Some ideas: Maybe we could convert
_fetchAssets
to a non-promise and allow the assets to be bundled or traceable byrequire()
orimport
instead ofnode:fs
). This would result in at least1 MB
of assets with a default bundledshiki
import { CssVariable } from 'shiki/themes'
and tree shaking away the rest in productionThe text was updated successfully, but these errors were encountered: