NextBlock™ relie le CMS hébergé, le starter open source et les outils dev dans un même socle produit. Le workspace Nx, les contrats de blocs typés et l'éditeur partagé permettent d'avancer vite sans sacrifier la cohérence.
Socle unique
Une même base
Le site public, le shell CMS et le starter gardent les mêmes choix produit et la même direction visuelle.
Contenu typé
Blocs avec garde-fous
Schémas Zod, contenus par défaut et contrats de rendu rendent les extensions plus sûres à maintenir.
Expérience éditoriale
Edition premium
La couche Tiptap donne aux éditeurs une interface riche sans masquer la puissance HTML pour les cas avancés.
Architecture monorepo et flux de dépendances
Le dossier apps/nextblock contient l'expérience Next.js en production, incluant le site public et le shell CMS authentifié. Le CLI apps/create-nextblock reprend cette base pour que les nouveaux projets partent des mêmes décisions produit.
- @nextblock-cms/ui - composants UI, tokens et primitives visuelles partagées
- @nextblock-cms/utils - traductions, gardes d'environnement et helpers de stockage
- @nextblock-cms/db - migrations, accès base typé et types générés
- @nextblock-cms/editor - la surface d'édition Tiptap v3 réutilisable
- @nextblock-cms/sdk - contrats typés pour l'auteuring et la validation des blocs
- @nextblock-cms/ecommerce - le module commerce premium lorsqu'il est activé
Lancez nx graph et vous voyez immédiatement comment un changement se propage. Les alias de tsconfig.base.json et la configuration Tailwind partagée aident à garder une vraie parité entre marketing, back-office et projets générés.
Le registre de blocs comme surface produit
Le registre dans apps/nextblock/lib/blocks/blockRegistry.ts définit les types disponibles, les schémas Zod, les contenus de départ et les composants d'édition ou de rendu. On y trouve aujourd'hui des blocs comme text, heading, section, posts_grid, checkout et product_details.
Les sections supportent des colonnes imbriquées, ce qui permet de composer de vraies pages plutôt qu'une simple liste de contenu. Des helpers comme getBlockDefinition(), getInitialContent() and validateBlockContent() gardent cette flexibilité bien typée.
La couche d'edition
Le package @nextblock-cms/editor enveloppe Tiptap v3 dans une surface éditoriale réutilisable avec slash commands, menus contextuels, drag handles, tableaux, listes de taches, compteurs et blocs de code. Le but est de conserver un HTML riche quand une equipe en a besoin.
A l'interieur du shell CMS
Dans apps/nextblock/app/cms, chaque zone suit un motif lisible : pages de liste, routes de creation et d'edition, composants clients cibles et server actions qui encapsulent les mutations Supabase. Les editeurs y gagnent une interface coherente et les identifiants restent cote serveur.
Open core sans derive produit
Le coeur du CMS est open source sous AGPL. Les modules premium comme @nextblock-cms/ecommerce restent disponibles en source mais sont actives via package_activations et verifyPackageOnline(). Le meme shell peut donc rester simple pour l'open source tout en deverrouillant les surfaces commerce au bon moment.
Pourquoi l'ensemble tient
Le workspace Nx garde les librairies honnetes, l'app Next.js maintient la coherence UI, les migrations Supabase codifient les regles d'acces, et l'editeur Tiptap donne la meme experience de contribution quel que soit le deploiement. Quand une equipe lance npm create nextblock, elle recupere une facon de travailler complete, pas juste des fichiers.