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 quelle méthode 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 ce qui changerait sans rien modifier.

Cinq façons d'installer, quatre façons de mettre à jour

Les quatre premières options du guide d'installation correspondent une à une aux chemins ci-dessous. La cinquième, où un agent de code IA crée le site, se met à jour comme le chemin 2 ou 3. 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, Vercel 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. Un fork GitHub manuel contient déjà le workflow, mais GitHub y désactive les Actions. Activez-les une fois depuis l'onglet Actions du fork.

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/.

Un nouveau projet a besoin de ce premier commit. Le CLI create-nextblock lance git init mais ne crée aucun commit, y compris en mode Docker et lorsqu'un agent IA l'exécute. Validez donc une fois avant votre première mise à jour : git add -A, puis git commit -m initial. Le .gitignore généré exclut déjà vos fichiers .env et les configurations MCP de l'agent.

4. Le monorepo cloné — une commande

npm run update
npm run dev

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. Une fois la mise à jour terminée, relancez le serveur de développement avec npm run dev (port 4200).

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

Sous PowerShell, un -- isolé est supprimé : les formes avec option ci-dessus s'exécutent alors comme un simple npm run update, avec ses confirmations. npm garde l'option pour lui : il affiche l'avertissement Unknown cli config pour --check, --db-only et --skip-db, mais --yes et --force sont aussi des options de npm, qu'il prend sans cet avertissement. Pour un aperçu, utilisez npm run update:check. Pour les autres options, appelez le script directement. Par exemple, dans un projet créé avec npm create nextblock, lancez node tools/update.mjs --db-only ; dans le monorepo, node apps/nextblock/tools/update.mjs --db-only. L'invite de commandes (cmd.exe) et les terminaux macOS et Linux ne sont pas concernés.

Ce qui arrive à votre base de données

Les évolutions du schéma vont uniquement vers l'avant. 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 surtout la structure — tables, colonnes, index, permissions. Quelques-unes corrigent aussi des données. Elles rafraîchissent le contenu de démonstration, les couleurs de thème et les textes d'interface fournis par NextBlock, en général seulement là où ils sont encore tels que livrés. Plus rarement, une migration applique une correction mécanique ciblée à tout le contenu. Par exemple : passer les vidéos YouTube intégrées sur youtube-nocookie, ou retirer une classe CSS qui ralentissait le premier affichage. Aucune migration ne supprime vos pages, articles, produits, médias ou utilisateurs.

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 status, qui liste les fichiers ajoutés, et git diff. Pour annuler le code, lancez git reset --hard HEAD et git clean -fd, puis npm install pour rétablir vos dépendances. git clean supprime les fichiers ajoutés par la mise à jour, ainsi que tout fichier non suivi créé depuis : vérifiez d'abord avec git clean -nd. Les migrations déjà appliquées le restent : restaurez votre sauvegarde si vous avez besoin de l'ancien schéma. La mise à jour elle-même ne supprime jamais de fichier : ceux que vous avez ajoutés ne disparaissent jamais.
• Installations basées sur git : le workflow quotidien applique chaque mise à jour sous forme de commit de fusion. git log l'affiche et git revert -m 1 <commit-de-fusion> l'annule. Git considère alors ces changements comme déjà fusionnés. Les synchronisations suivantes ne les réappliqueront donc pas tant que vous n'aurez pas annulé ce revert. Vous avez lancé npm run update vous-même, sur un clone ou une copie locale de votre fork ? Juste après, git reset --hard ORIG_HEAD ramène le code en arrière et npm install rétablit les dépendances précédentes. Les migrations déjà appliquées le restent.
• 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, git clean -fd puis npm install annulent 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, git clean -fd puis npm install : dans les deux cas la base n'a jamais été touchée. Sans ces deux dernières commandes, les nouveaux fichiers de migration restent sur le disque, et une prochaine mise à jour ou reconstruction peut les appliquer.

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 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 projets créés avec npm create nextblock affichent cette bannière, y compris ceux créés par un agent IA. Les déploiements en un clic et les forks sur Vercel ne l'affichent pas : le workflow quotidien fusionne les mises à jour pour eux. 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 modifie le code, les dépendances et le schéma de la base. Quelques migrations apportent aussi des corrections ciblées aux données, surtout au contenu de démonstration, aux traductions et aux couleurs de thème fournis par NextBlock (voir Ce qui arrive à votre base de données). Aucune ne supprime votre contenu.

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. Définir CI=true désactive aussi les confirmations, quel que soit le terminal.

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 ?

Aucune commande. Une fois l'étape Connect GitHub du tableau de bord validée, ce chemin est entièrement automatique. Pour mettre à jour tout de suite plutôt qu'à minuit, ouvrez l'onglet Actions de votre dépôt et cliquez sur Run workflow sous NextBlock Upstream Sync. Vous pouvez aussi lancer la commande sur un clone local, puis pousser le résultat.