Les mises à jour de NextBlock : une seule commande, quelle que soit l'installation

NextBlock évolue en continu — nouveaux blocs, corrections de l'éditeur, correctifs de sécurité, et parfois une modification de la base de données dont le nouveau code dépend. Suivre tout cela supposait autrefois de savoir laquelle des quatre méthodes d'installation vous aviez utilisée. Ce n'est plus le cas. Tout projet NextBlock, quelle que soit sa création, comprend une seule commande :

La commande détermine dans quel type d'installation elle s'exécute, choisit la bonne source pour le nouveau code, installe les dépendances correspondantes, puis applique les migrations dont la nouvelle version a besoin. Si vous préférez regarder avant de sauter, npm run update -- --check indique exactement ce qui changerait sans rien modifier.

Les quatre installations et leurs mises à jour

Elles correspondent une à une aux quatre options du guide d'installation. La commande est la même partout ; seule la provenance du nouveau code change.

1. Vercel en un clic et forks GitHub — sans intervention

Ce chemin se met à jour tout seul. Lors du déploiement, NextBlock a créé un dépôt qui vous appartient ; l'étape Connect GitHub du tableau de bord y installe un workflow qui s'exécute chaque jour à minuit UTC et peut aussi être lancé à la demande depuis l'onglet Actions de votre dépôt.

1. Le workflow fusionne la dernière version de NextBlock dans votre branche de déploiement.
2. Une fusion propre est poussée sur votre branche, ce qui déclenche un déploiement Vercel normal.
3. Pendant ce build de production, NextBlock applique les migrations en attente avant de construire l'application — le nouveau code ne tourne donc jamais sur un ancien schéma.
4. En cas de conflit, rien n'est poussé. Le workflow ouvre une issue GitHub et votre tableau de bord affiche une bannière ambre qui pointe dessus. Résolvez, fermez l'issue, et la bannière disparaît d'elle-même.

Vous travaillez sur un clone local de ce fork ? npm run update effectue la même fusion sur votre machine, en ajoutant le dépôt upstream s'il manque, puis installe les dépendances et applique les migrations.

2. npm create nextblock → Docker — mettre à jour puis reconstruire

Depuis le dossier de votre projet :

npm run update
npm run docker:up

La première commande met à jour l'application et ses dépendances et prépare les nouvelles migrations ; la seconde reconstruit les conteneurs et applique ces migrations. La pile auto-hébergée dispose de son propre service de migration : la mise à jour lui confie donc l'étape schéma plutôt que d'appliquer le même SQL via deux suivis différents. Votre base de données et vos médias vivent dans des volumes Docker et ne sont touchés par aucune des deux commandes — docker:up reconstruit des images, pas des données.

3. npm create nextblock → Supabase géré — une commande

npm run update
npm run build
npm start

Votre projet est une application Next.js autonome sans dépôt amont à tirer : le nouveau code provient donc du paquet create-nextblock publié sur npm — exactement l'artefact à partir duquel votre projet a été généré, versionné en phase avec la release. NextBlock récupère votre version actuelle et la nouvelle, puis applique la différence entre les deux comme une fusion git à trois voies : la mise à jour se comporte donc exactement comme un git pull — les fichiers que vous n'avez jamais touchés se mettent à jour silencieusement, ceux que vous avez personnalisés conservent vos changements. Elle fusionne ensuite les nouvelles versions de dépendances dans votre package.json, lance npm install et applique les migrations.

Cela nécessite un dépôt git avec au moins un commit et une copie de travail propre — validez votre travail avant de mettre à jour. Sans cela il n'y a rien contre quoi fusionner : les fichiers sont alors copiés et tout ce qui est remplacé est conservé sous .nextblock-backup/.

4. Le monorepo cloné — une commande

npm run update

Dans un clone du dépôt NextBlock, la commande met votre copie à jour, réinstalle les dépendances du workspace et applique les migrations en attente. Elle refuse de s'exécuter par-dessus des modifications non validées et vous explique comment les mettre de côté : une mise à jour ne peut donc jamais faire disparaître du travail en cours. Si vous avez des commits locaux, elle s'arrête et vous oriente vers git pull --rebase plutôt que de deviner.

Ce que fait réellement npm run update

1. Identifie l'installation. Monorepo ou application autonome ; basée sur git ou sur npm ; Docker ou non.
2. Met à jour le code depuis la bonne source — fusion git, pull en avance rapide, ou le paquet create-nextblock publié.
3. Installe les dépendances avec npm install, pour que le code et les paquets qu'il importe avancent ensemble.
4. Rafraîchit les fichiers de migration livrés dans @nextblock-cms/db, afin que les dernières évolutions du schéma soient sur le disque avant toute application.
5. Applique les migrations en attente, en les listant d'abord et en demandant confirmation.
6. Efface la bannière de mise à jour du tableau de bord une fois la nouvelle version réellement en place.

Options

Ce qui arrive à votre base de données

Les évolutions du schéma sont uniquement additives. NextBlock ne réécrit ni ne rejoue jamais une migration déjà appliquée : chacune est appliquée et enregistrée dans la même transaction, si bien qu'un échec est annulé proprement et laisse la base exactement dans son état initial. Les migrations déjà appliquées sont ignorées par numéro de version, ce qui rend une nouvelle exécution totalement sûre.

Les migrations modifient la structure — tables, colonnes, index, permissions. Vos pages, articles, produits, médias et utilisateurs vous appartiennent : la mise à jour ne les supprime ni ne les réécrit.

En cas de problème

• Projets autonomes : la mise à jour est appliquée comme une fusion git à trois voies dans votre copie de travail — rien n'est validé à votre place. Examinez-la avec git diff, et annulez tout avec git reset --hard HEAD. Rien n'est jamais supprimé : les fichiers que vous avez ajoutés ne disparaissent jamais.
• Installations basées sur git : la mise à jour est un commit ordinaire. git log l'affiche et git revert l'annule.
• Un conflit se comporte différemment selon l'installation, volontairement. Sur un fork ou un clone, la fusion amont est annulée et votre copie de travail reste intacte. Sur un projet autonome, le conflit est laissé en place pour que vous le résolviez — c'est votre dépôt, et c'est tout l'intérêt — et git reset --hard HEAD annule toute la mise à jour.
• Une migration en échec est annulée. Corrigez la cause et relancez : rien ne reste à moitié appliqué.
• Les conflits non résolus bloquent la base. Si une fusion a laissé des conflits, la mise à jour termine le code et les dépendances mais s'arrête avant les migrations — votre schéma ne prend jamais de l'avance sur un code que vous n'avez pas fini d'arbitrer. Résolvez-les puis relancez npm run update pour appliquer les migrations, ou abandonnez avec git reset --hard HEAD : dans les deux cas la base n'a jamais été touchée.

Si vous avez personnalisé un fichier appartenant à NextBlock — sous app/, components/ ou lib/ — votre modification est conservée. La mise à jour fusionne le changement amont dans votre version, et seul un changement qui chevauche réellement le vôtre entre en conflit — la commande liste ces fichiers, et chacun porte les marqueurs habituels <<<<<<< your version / >>>>>>> NextBlock. Modifiez-les comme n'importe quel conflit, ou lancez git checkout -- <fichier> pour abandonner la fusion sur ce seul fichier. Les personnalisations dans vos propres fichiers, dans le CMS ou dans .env ne sont jamais touchées.

Savoir qu'une mise à jour est disponible

Inutile de surveiller. NextBlock vérifie en arrière-plan pendant que vous utilisez le CMS et affiche une bannière sur le tableau de bord dès qu'une version plus récente est publiée, en indiquant votre version actuelle et celle disponible. Les administrateurs peuvent aussi lancer npm run update -- --check à tout moment.

FAQ des mises à jour

La mise à jour va-t-elle écraser mon contenu ou mes réglages ?

Non. Contenus, médias, utilisateurs et réglages vivent dans votre base de données ; la configuration du site vit dans vos variables d'environnement. La mise à jour ne touche que le code, les dépendances et la structure du schéma.

Dois-je installer chaque version ?

Non, mais rester proche de la dernière version vous garantit les correctifs de sécurité et rend chaque saut plus petit. Les migrations s'appliquent dans l'ordre : sauter plusieurs versions fonctionne malgré tout.

Puis-je l'exécuter en CI ?

Oui — npm run update -- --yes ne pose aucune question et renvoie un code d'erreur si l'étape schéma échoue, pour qu'un pipeline puisse le détecter.

Et si aucune connexion à la base n'est configurée ?

Le code et les dépendances sont tout de même mis à jour ; l'étape schéma est ignorée avec un avertissement indiquant la variable d'environnement à définir. Relancez ensuite npm run update -- --db-only.

J'ai déployé sur Vercel, mais depuis npm create nextblock. Est-ce automatique aussi ?

Non — et c'est la distinction qui piège le plus. Les mises à jour automatiques dépendent du fait que votre dépôt soit le monorepo NextBlock, pas de l'endroit où le site est hébergé. Un projet généré par le CLI reste l'application autonome aplatie, quel que soit l'hébergeur : il se met à jour avec npm run update. L'étape Connect GitHub ne s'affiche pas sur ce type d'installation, car le workflow qu'elle installe fusionnerait une arborescence totalement différente dans la vôtre.

Je suis sur le déploiement Vercel en un clic — dois-je lancer quelque chose ?

Non. Ce chemin est entièrement automatique. La commande existe pour mettre à jour tout de suite plutôt qu'à minuit, ou lorsque vous travaillez sur un clone local.