Mise à niveau

Mettre à niveau une application existante

Dix étapes, de la plus récente à la plus ancienne. Commencez par celle qui se trouve juste au-dessus de votre version actuelle et descendez — ou, si vous partez de la version 0.12, commencez par le bas et remontez.

Vous êtes en	À lire	Ce que cela implique
0.26	0.26 → 0.27	Un horaire cron qui restreint les deux champs de jour s’exécute sur l’un ou l’autre, donc plus souvent, et un horaire contenant un nombre mal formé est refusé, donc cette tâche cesse de s’exécuter. Une clé dont la stratégie isId n’est pas compatible avec son type interrompt le démarrage. Sur Rebase Cloud, un déploiement ou un aperçu échoue lorsqu’un fichier de fonction ou de cron ne se charge pas.
0.25	0.25 → 0.26	Sont refusés : une écriture désignant une relation via multi-sauts, un nom de rôle qui ne désigne pas un seul rôle, un jeton de page du stockage local antérieur à la mise à niveau et un amont de fonctions qui ne peut pas fonctionner. La connexion OAuth régularise un compte non vérifié au lieu de répondre local-account-unverified, le serveur MCP n’envoie plus REBASE_TOKEN à l’application, et les types générés suppriment la clé d’un belongsTo excludeFromApi. Sur Rebase Cloud, rebase cloud webhooks et --scale-to-zero true sont retirés, et d’anciens jetons devront peut-être être recréés.
0.24	0.24 → 0.25	?count= sur une liste REST devient l’interrupteur du comptage derrière meta.total, donc un filtre sur une colonne nommée count passe dans ?where= ; list_collections du MCP distant n’envoie plus sa liste que dans le bloc de texte, sans structuredContent ; et @rebasepro/app n’exporte plus la table de traduction espagnole es. Sont refusés : un OPTIONS simple vers une route sans gestionnaire, des noms de table qui entrent en collision au démarrage, un upsert sur la collection des utilisateurs, page avec offset, une chaîne vide dans un champ obligatoire et un mot de passe choisi par un administrateur qui ne respecte pas la politique de mot de passe. Une session dure par défaut 30 jours d’inactivité, client.cron appelle /api/admin/cron, les lectures hors ligne auxquelles il est impossible de répondre en entier échouent avec OFFLINE, et quelques exports internes et props inutilisées disparaissent.
0.23	0.23 → 0.24	Le SQL que produisent db push et db generate quitte drizzle/ pour .rebase/sql/, qui n’est pas commité, l’option --generate de rebase dev disparaît parce que dev régénère toujours les types du SDK, et une modification de schéma en direct n’inclut aucun SQL dans son commit. Les permissions deviennent des portées : les surfaces d’administration demandent une portée plutôt que le rôle admin, les clés d’API portent des portées au lieu d’une liste de permissions et d’un indicateur admin, et schema-admin n’est plus un administrateur. Un --collections relatif est lu depuis l’endroit où la commande s’exécute, un upsert dans une ligne de la corbeille et une mise à jour qui change une clé sont refusés, le point de terminaison MCP distant prend les arguments du SDK, et les sockets temps réel ouverts, les liens de vérification d’e-mail, signUp et les codes de récupération MFA changent leur façon de traiter une session.
0.21 – 0.22	0.21 → 0.23	Une clé d’API sur un chemin imbriqué a besoin de read sur ses parents, les variables numériques et durées de session illisibles empêchent le démarrage, un dépôt d’authentification personnalisé a besoin de unlinkUserIdentity, et la conversion d’un invité en compte exige le captcha register. 0.22 ne déclare aucun changement incompatible : c’est donc une seule étape depuis 0.21.
0.18 – 0.20	0.18 → 0.21	context.client.data ne compile plus dans un callback de collection — effectuez vos requêtes via context.data — et selectedEntities cède la place à une sélection qui peut désigner des lignes que personne n’a chargées. Les versions 0.19 et 0.20 ne déclarent aucun changement cassant, il s’agit donc d’une seule étape depuis la 0.18.
0.17	0.17 → 0.18	Onze changements cassants, la plupart étant des erreurs de compilation plutôt que des changements de comportement silencieux. rebase.data disparaît au runtime, les plages de peer dependencies sont restreintes aux carets (^), et la version minimale de Node passe à 22.22.0.
0.14 – 0.16	0.14 → 0.17	Les paquets admin sont renommés, les ressources sont déclarées plutôt que configurées, et un bundle compilé avant cela ne démarrera pas sur un runtime actuel. Les versions 0.15 et 0.16 ne cassent rien, il s’agit donc d’une seule étape depuis la 0.14.
0.13	0.13 → 0.14	Chaque clé réseau est en camelCase, et la connexion anonyme nécessite désormais une activation explicite (opt-in).
0.12	0.12 → 0.13	L’étape la plus importante, et la seule qui modifie qui peut lire vos données. Elle supprime le schéma auth, renomme des paquets, redéfinit la signification de id, abandonne CJS, migre le panneau d’administration vers react-router 8, et corrige trois failles par lesquelles des accès non souhaités pouvaient être accordés.

Les sections de chaque page sont présentées dans l’ordre où vous devez les appliquer, et chacune indique le symptôme que vous risqueriez sinon de déboguer par le mauvais bout.

Ensuite, quelle que soit l’étape franchie :

• La checklist de mise à niveau ci-dessous — l’ensemble des greps et des commandes utiles à exécuter par la suite, regroupés en un seul bloc.

Checklist de mise à niveau

[ ] grep for authenticated() and (auth|rebase).uid() IS NOT NULL in config/collections/
[ ] decide the intent of each rule; rewrite the ones that meant "public"
[ ] replace not(authenticated()) with serverContext()
[ ] if realtime.requireAuth was true with an AuthAdapter, treat the socket as
    having been open — verify RLS on every subscribable collection (section 2)
[ ] SELECT ... FROM pg_policies — record the qual of every policy BEFORE
[ ] update package names and imports
[ ] grep for rebase.data — it is now rebase.dataAsAdmin (section 8)
[ ] grep for the other ten removed deprecated exports (section 8)
[ ] drop react-router-dom; import RouterProvider from "react-router/dom"
[ ] check node >= 22.22.0 and react >= 19.2.7 (react-router 8 requires both)
[ ] move defaultSecurityRules into config/collections/index.ts
[ ] grep for .userId
[ ] grep for row.id on tables not keyed on id
[ ] run db push
[ ] run rebase doctor --policies — expect no Insecure or Orphaned entries
[ ] SELECT ... FROM pg_policies again — confirm every intended change landed
[ ] exercise the app signed OUT, in a private window — watch the websocket too

--- 0.13 → 0.14 (part 2) ---
[ ] re-run rebase generate-sdk, then build — the compiler finds row.author_id
[ ] grep for snake_case where/orderBy keys; a stale one is a 400, not a warning
[ ] grep for raw fetch consumers reading row.<something>_id — these read
    undefined and raise nothing
[ ] if the project was introspected, re-run rebase schema introspect
[ ] decide anonymous sign-in: set auth.allowAnonymous: true, or confirm you
    never used it (grep for signInAnonymously)
[ ] drop @rebasepro/client-postgres from package.json

--- 0.14 → 0.17 (part 3) ---
[ ] rename @rebasepro/admin → @rebasepro/cms and admin-types → cms-types,
    and RebaseAdmin → RebaseCMS
[ ] move dataSources / storageSources out of the backend config into
    rebase.json and config/, then `rebase build` — an old bundle will not boot
[ ] grep collections for admin.titleProperty; it is refused at boot now
[ ] grep crons for ctx.client and for `userId` as an identity key
[ ] rename --legacy to --workspace wherever build/start is scripted
[ ] if you implement EmailService yourself, `send` must return a result

rebase doctor --policies est la commande à intégrer dans votre CI : elle retourne un code d’erreur non nul si une stratégie comporte encore la tautologie permissive, ou si un push antérieur l’a rendue obsolète. Les lectures de pg_policies avant et après valent tout de même la peine d’y consacrer une minute — elles vous montrent les expressions brutes, ce qui constitue le seul moyen de repérer une stratégie ouverte par défaut (fail-open) rédigée selon une syntaxe non reconnue par le détecteur. Ni les paquets ni le système de types ne vous alerteront : le changement réside dans la base de données, et seul db push l’y applique.

Voir aussi

• Changelog — les notes de version résumées dans chacune de ces sections
• Compatibilité — les six contrats, et ceux qu’une version peut rompre
• Commandes CLI — rebase doctor et les commandes exécutées par les checklists