refactor: separate packages for Vue, React and Nuxt

[farnabaz]

Works in production: https://comark-sample-g9zr41pys-farnabazs-projects.vercel.app/

dependencies are:

  "dependencies": {
    "@comark/nuxt": "https://pkg.pr.new/comarkdown/comark/@comark/nuxt@34",
    "nuxt": "^4.3.1",
    "vue": "^3.5.29",
    "vue-router": "^4.6.4"
  }

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
comark	Error		Mar 6, 2026 3:16pm

[pkg-pr-new]

Open in StackBlitz

comark

npm i https://pkg.pr.new/comarkdown/comark@34

@comark/nuxt

npm i https://pkg.pr.new/comarkdown/comark/@comark/nuxt@34

@comark/react

npm i https://pkg.pr.new/comarkdown/comark/@comark/react@34

@comark/vue

npm i https://pkg.pr.new/comarkdown/comark/@comark/vue@34

@comark/plugin-cjk

npm i https://pkg.pr.new/comarkdown/comark/@comark/plugin-cjk@34

@comark/plugin-math

npm i https://pkg.pr.new/comarkdown/comark/@comark/plugin-math@34

@comark/plugin-mermaid

npm i https://pkg.pr.new/comarkdown/comark/@comark/plugin-mermaid@34

commit: 4e194a2

[atinux]

Last refactor 🤞
Good for me @farnabaz 🚀

[elliott-with-the-longest-name-on-github]

This seems wrong, as the defineComarkComponent fn is still used below

[elliott-with-the-longest-name-on-github]

I'm noticing now that the plugins also have the same problem where they export multiple frameworks' components / are bundled (meaning lots of potential issues with package deduplication in end user apps) -- I wonder if the plugins should only export the actual Comark plugin (for example, comarkMermaid), and the framework packages (@comark/svelte, @comark/vue, etc) should re-export them:

// `@comark/svelte/plugin-mermaid`
import { comarkMermaid } from '@comark/plugin-mermaid';
import { Mermaid } from './Mermaid.svelte';

export { Mermaid, comarkMermaid }

That way the vast majority of users still only have one package to install, and treeshaking will still work great...

[elliott-with-the-longest-name-on-github]

I think comark needs to be external as well, otherwise users who have both @comark/nuxt and comark installed will end up with two copies of comark, right?

[elliott-with-the-longest-name-on-github]

some additional questions about bundling / config that are confusing me as I work with the svelte lib

[elliott-with-the-longest-name-on-github]

Should have scule as well, right?

[elliott-with-the-longest-name-on-github]

I'm still unclear on why this package needs to be bundled at all, but if it does need to be bundled, shouldn't it externalize its dependencies?

[elliott-with-the-longest-name-on-github]

Same question here re: externalizing dependencies and being confused as to why we need a bundler in the first place

[elliott-with-the-longest-name-on-github]

Having thought about it for most of the day, this is what's currently floating around in my head:

• It's confusing that we're using a bundler for what appear to be js-only packages. At best this should just be a tsc step to generate the output ESM and, if necessary, an export map. This reduces the library's complexity and avoids a whole category of headaches around making sure we're externalizing the correct dependencies. (In the case of a library like this, really all of the dependencies should be externalized, which... kind of defeats the purpose of bundling in the first place.)
• For the standalone plugins, I think we should pare them down to only the actual plugin code, and move the framework-specific implementations into the framework packages as subpath exports. Users of frameworks are going to be using a bundler and therefore will trivially be able to treeshake away plugins they're not using, and it means we can keep the framework-specific stuff in the "leaves" of the library and maintain a single package installation / import for the vast majority of cases.
• Incidentally, this'll also give us better indications of usage / growth by framework, as all "things to do with a given framework" will be handled under their own packages with their own download statistics