feat: use slim shiki build and pre-compiled languages

[nperez0111]

This significantly cuts down on the bundle size of the package by leveraging shiki's new slim builds and precompiled languages

Fixes #1487 #1213

This could probably be reduced further by completely separating the default languages, but for this would require a breaking change to the API for code blocks to properly work.

The ideal would be for the user to specifically pick which languages and themes for the code block feature, rather than us providing any defaults for this.

Perhaps we can have defaults built into a separate package? To make it easier for those already using us?

Either way, this would require some thought, while the current change would still be compatible with the current API

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
blocknote	❌ Failed (Inspect)		Mar 16, 2025 1:18pm
blocknote-website	❌ Failed (Inspect)		Mar 16, 2025 1:18pm

[YousefED]

This is great!

If I understand it correctly; this mostly makes sure unused languages that are not in our "defaultSupportedLanguages" don't appear in the app output. However, languages that are, of course still appear in the app output. correct?

The ideal would be for the user to specifically pick which languages and themes for the code block feature, rather than us providing any defaults for this.

Perhaps we can have defaults built into a separate package? To make it easier for those already using us?

I think it's worthwhile to tackle the issue completely and invest a bit more to also address this.

• I think it's ok to make this a breaking changes as long as it's clearly documented
• if it's not too much overhead (in code / docs / maintenance) I think having some sensible defaults easily available makes sense indeed
• we should decide whether by default we don't want any syntax highlighting at all, or only support 1-3 langs
• while we're at it, maybe we should also make it easy for consumers to load other themes

[flipvh]

Great news. My biased opinion would be to not add any and let the consumers decide to include one or multiple somehow. I would see the code block as a more 'advanced functionality' that will be used by consumers that should be fine with doing some config. If you throw in an example of that on your site, the first round of beers in de Biergarten are on me 🍻 😸.

[nperez0111]

Alright, I've exposed the codeBlock configuration on the editor instance, and so this would let you configure the languages & themes that are supported by your app. By default, no languages or themes are bundled, to configure syntax highlighting, you can install the new package @blocknote/code-block which provides a decent set of languages and light & dark themes to use.

If you want more control than this, I'll write a guide on how easy it will be to integrate your list of languages, using the shiki-codegen tool.

This isn't completely ready yet, as I'll need to:

• made a PR into prosemirror-highlight: feat(shiki): support shiki v3 ocavue/prosemirror-highlight#79
• add an example
• write a guide on how to configure with shiki-codegen
• make sure the new package is being bundled appropriately & TS works within the repo