markstream-vue : rendre du Markdown qui n'est pas encore fini
Multi-framework streaming Markdown renderers for AI apps: Vue/Nuxt, React/Next.js, Svelte, and Angular, with Mermaid, KaTeX, stream-diffs code blocks, safe HTML, and low-jitter updates.
En bref
- De quoi s’agit-il ?
- markstream-vue est un composant Vue 3, Nuxt et VitePress qui affiche du Markdown en cours de génération, jeton par jeton. Sa promesse est précise, son périmètre aussi : il ne remplace pas marked ou markdown-it sur un document figé.
- À qui s’adresse-t-il ?
- Adoptez markstream-vue si votre interface Vue 3, Nuxt ou VitePress affiche du Markdown qui change encore pendant que l'utilisateur le lit, et si vous acceptez la rupture de la 2.x. Passez votre chemin pour un blog, une documentation statique ou un rendu unique en fin de réponse : marked ou markdown-it suffisent et coûtent moins cher.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 3 jours.
- En quel langage est-il écrit ?
- Principalement Vue, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème n'est pas le Markdown, c'est son état intermédiaire
Un moteur Markdown classique suppose une entrée complète. On lui passe une chaîne, il renvoie un arbre, on affiche. Avec une sortie de LLM en SSE ou en WebSocket, cette hypothèse tombe : à l'instant t, le texte reçu contient un bloc de code ouvert, un tableau à moitié rempli, une formule KaTeX coupée avant son délimiteur de fermeture. Le README de markstream-vue pose la frontière sans détour : marked, markdown-it et react-markdown servent pour du Markdown fini, Markstream pour du Markdown qui change pendant que l'utilisateur le lit. Le public visé est donc étroit et identifiable : les équipes qui construisent une interface de chat avec un LLM et qui veulent éviter le clignotement d'un rendu re-parsé à chaque jeton. Le paquet principal, markstream-vue, cible Vue 3, Nuxt et VitePress, y compris les WebView mobiles d'après la description du dépôt. Les autres frameworks passent par des paquets frères : markstream-react, markstream-svelte, markstream-angular, markstream-octane et markstream-vue2 pour Vue 2.6 et 2.7.
Deux paquets sous le composant : un parseur et un contrôleur
La famille ne se limite pas aux adaptateurs de framework. Le tableau des paquets du README distingue stream-markdown-parser, présenté comme utilisable depuis n'importe quelle application JS ou TS pour du parsing seul, et markstream-core, décrit comme un ensemble d'utilitaires de contrôle de flux, framework-agnostique. C'est l'indice architectural le plus concret dont on dispose : l'analyse du Markdown incomplet et la gestion du flux sont séparées de la couche de rendu propre à chaque framework. Le composant expose aussi deux modes de consommation, puisque la surface stable mentionnée dans le README inclut le rendu de contenu en streaming et le rendu de nœuds pré-parsés. Autrement dit, on peut laisser markstream-vue parser à la volée, ou lui fournir un arbre déjà construit quand le pipeline de parsing est géré ailleurs. Le README ne détaille pas la structure de cet arbre ni le protocole exact entre le parseur et le rendu. Ce point reste à vérifier dans le guide du parseur avant de bâtir une architecture autour de lui.
Installation et props : le strict minimum
L'installation tient en une commande, pnpm add markstream-vue, et l'exemple du README montre l'usage complet : on importe MarkdownRender depuis markstream-vue, on importe aussi markstream-vue/index.css, puis on rend le composant avec mode="chat", :content et :final. La prop final, liée à un booléen isDone, signale que le flux est terminé. C'est l'interface publique minimale, et elle est lisible. Un détail mérite attention : la feuille de style est un import séparé, pas un effet de bord du composant. Si vous l'oubliez, rien dans le README ne laisse penser que le rendu sera correct. Le peer optionnel stream-diffs n'est requis que pour les blocs de code et de diff enrichis. La documentation précise aussi que la 2.x a retiré les runtimes de blocs de code Monaco et stream-markdown, ce qui explique pourquoi ce peer est devenu optionnel plutôt qu'intégré. Pour les projets bloqués sur la ligne 1.x, le README donne pnpm add markstream-vue@1, avec les préversions 1.x sur le tag legacy-next.
Mermaid, KaTeX et HTML sûr : ce que le README annonce, pas ce qu'il prouve
Le titre du dépôt mentionne Mermaid, KaTeX, les blocs de code en diff et le HTML sûr, et la description parle de mises à jour à faible gigue. Le README confirme que Mermaid et KaTeX font partie de la surface stable, en tant qu'options. Il ne donne ni la liste des clés de configuration, ni le comportement exact du rendu partiel pour ces deux intégrations. La question pratique, et elle est sérieuse, est celle d'un diagramme Mermaid dont la source arrive en morceaux : à quel moment le rendu tente-t-il de dessiner, et que se passe-t-il entre deux fragments ? Le README ne répond pas. Même remarque pour KaTeX et une formule dont le délimiteur de fermeture n'est pas encore arrivé. Sur le HTML sûr, le README parle d'une politique, sans en énumérer les règles. Ce sont les zones où la documentation est la plus mince, et ce sont précisément celles qui décident du comportement en production. À traiter comme des points à valider sur la page de test partageable citée dans les badges du dépôt.
Ce que la 2.x a cassé, et pourquoi c'est le vrai coût
La migration de 1.x vers 2.0 n'est pas cosmétique. Le README indique que la version 2 supprime les runtimes de blocs de code Monaco et stream-markdown, et renvoie vers un guide de migration dédié. Si votre application comptait sur ces runtimes, la mise à jour implique de réintroduire le peer stream-diffs ou de revoir la façon dont vous affichez le code. La ligne 1.x reste maintenue et publiée sous le tag legacy, ce qui offre une porte de sortie, mais une porte de sortie n'est pas une stratégie : elle fige votre projet sur une branche dont la durée de vie n'est pas documentée dans le matériel fourni. Le rythme de publication observé est élevé : les versions markstream-vue@2.0.11, markstream-vue2@2.0.11 et markstream-svelte@2.0.11 datent toutes du 9 septembre 2026, et la dernière poussée sur le dépôt est le même jour. Un versionnage synchronisé entre paquets simplifie l'alignement des versions, mais il signifie aussi que chaque correctif traverse toute la famille. Pour une équipe qui n'utilise qu'un framework, cela reste une dépense de suivi à prévoir. La licence est MIT, ce qui autorise l'usage commercial et la modification sans obligation de publier vos changements ; le dépôt contient un fichier SECURITY.md, mais le README n'en détaille pas le contenu. Rien ici ne relève d'un conseil juridique.
Quand un parseur classique est le bon choix
L'alternative la plus directe est celle que le README nomme lui-même : marked ou markdown-it. La différence d'approche est nette. Ces bibliothèques prennent une chaîne complète et produisent un résultat en une passe, sans état de flux, sans notion de contenu partiel, sans politique de rendu progressif des blocs lourds. Si votre application reçoit la réponse entière du LLM avant de l'afficher, elles font le travail pour une fraction de la complexité. Si vous êtes en React, react-markdown est cité comme l'outil du Markdown fini, et markstream-react existe pour le cas streaming. Le README renvoie également vers des comparaisons détaillées avec vue-stream-markdown et Streamdown, ce qui indique que le créateur du projet considère ces deux-là comme les concurrents sérieux sur le créneau du streaming. Ces pages ne figurent pas dans le matériel fourni, donc je ne peux pas en résumer les conclusions. Le seul critère que je peux affirmer depuis le README : si votre Markdown ne change plus pendant la lecture, markstream-vue est un outil plus lourd que nécessaire.
Framework-agnostique en théorie, six paquets en pratique
Le dépôt s'annonce multi-framework, et le tableau des paquets couvre Vue 3, Vue 2, React, Svelte 5, Angular standalone et Octane. Cette largeur a un revers : le paquet markstream-octane s'installe avec octane en dépendance, markstream-svelte exige svelte@^5, et markstream-angular vise le mode standalone. Chaque adaptateur a donc ses propres contraintes de version, et rien dans le README ne garantit que les six paquets exposent la même surface de props ni le même rythme de correction. Le versionnage synchronisé en 2.0.11 suggère une intention d'alignement, pas une preuve de parité fonctionnelle. Pour un lecteur qui hésite entre deux frameworks, la question utile n'est pas « lequel est supporté » mais « lequel a la même couverture de tests », et le README ne répond pas. La CI citée dans les badges couvre le dépôt, sans détail par paquet. Si votre choix de framework est encore ouvert, c'est un argument pour vérifier le contenu de chaque paquet avant de trancher.
Conclusion éditoriale
Adoptez markstream-vue si votre interface Vue 3, Nuxt ou VitePress affiche du Markdown qui change encore pendant que l'utilisateur le lit, et si vous acceptez la rupture de la 2.x. Passez votre chemin pour un blog, une documentation statique ou un rendu unique en fin de réponse : marked ou markdown-it suffisent et coûtent moins cher. Avant d'installer, vérifiez deux points dans la documentation : le contenu exact de la migration 1.x vers 2.0, qui supprime les runtimes de blocs de code Monaco et stream-markdown, et la nécessité ou non du peer optionnel stream-diffs selon vos blocs de code. Le reste, soit mode="chat", :content et :final, se lit dans l'exemple du README.
Notes de la communauté