Architecture dégroupée : quatre modules frontend deviennent autonomes + miroir OSS renforcé

R4 : diviser le frontend en modules véritablement indépendants

L'interface du studio était devenue suffisamment grande pour que ses quatre packages les plus lourds – chat, workbench, paramètres, tableau de bord – soient tous intégrés dans le dépôt principal, compilés ensemble et publiés ensemble. Pour les développeurs, changer une ligne dans le chat signifiait attendre que l'ensemble du frontend soit reconstruit ; sur le plan architectural, les dépendances enchevêtrées entre les quatre blocs devenaient de plus en plus difficiles à démêler. Le plan R4 d'aujourd'hui a enregistré chacun de ces quatre packages en tant que sous-modules indépendants, chacun avec son propre référentiel, sa propre version, son propre CI. L'avantage a été immédiat : chaque module peut itérer et tester indépendamment, et toucher le chat ne force pas une reconstruction de l'atelier. L'inconvénient est également clair : plus de sous-modules à gérer. Mais pour qu'un projet passe du "prototype rapide" au "maintenable à long terme", cette étape devait arriver tôt ou tard, et le plus tôt sera le mieux.

La fermeture des dépendances CLI devient également autonome

Pas seulement le front-end. Ce jour-là, nous avons également extrait la fermeture des dépendances de la CLI (contrats, agent-hôte, plateforme-io, noyau) du référentiel principal vers des référentiels de sous-modules autonomes. Auparavant, ils vivaient comme des sous-répertoires du dépôt principal, partageant un « node_modules » et un pipeline de construction ; mais la CLI est fondamentalement un produit indépendant qui doit rester compatible entre les différentes versions de Studio, et son intégration dans le monorepo limite sa flexibilité. Une fois extraite, la CLI peut versionner et tester indépendamment, et le miroir OSS n'a besoin que de synchroniser ces référentiels pour se construire complètement - avant cela, les dépendances manquantes provoquaient l'échec de l'installation du bun du miroir public.

Le miroir OSS : du « navigable » au « constructible »

Cette journée a donné au miroir public OSS (ForgeaX-Games/forgeax-studio) un durcissement en profondeur. Le plus gros changement : le transfert de code vers le dépôt public ne va plus directement vers le référentiel principal : il doit passer par un flux PR + fusion automatique, ce qui signifie que chaque synchronisation reçoit une vérification CI, une piste de révision et un point de restauration. Dans le même temps, le dépôt public a obtenu pour la première fois un véritable build CI : vérification de type, "bun fx setup", tests de fumée, exécution de bout en bout pour garantir que le code open source que les utilisateurs reçoivent est réellement compilé. Une faille de sécurité a également été comblée : les administrateurs pouvaient auparavant contourner la protection des succursales et effectuer des opérations directement ; maintenant enforce_admins=true ferme ce chemin. La fuite MIRROR_TOKEN a également été corrigée et une porte de fonctionnement à sec du miroir PR a été ajoutée. En une phrase : le miroir est passé de "code que vous pouvez parcourir mais ne peut pas créer" à "CI garantit qu'il est construit, le processus garantit qu'il est traçable".

Refonte de la fenêtre 2 × 2 : exécuter × afficher les modes orthogonaux

Cette journée a également abouti à une spécification de conception importante : la refonte de la fenêtre d'affichage 2×2. L'idée principale est de découpler le « mode d'exécution » (Édition/Lecture) du « mode d'affichage » (Scène/Jeu) en deux dimensions orthogonales, formant une matrice 2×2. Auparavant, Edit et Play de l'éditeur étaient deux états mutuellement exclusifs, avec la totalité de la fenêtre d'affichage reconstruite sur le commutateur ; le nouveau design vous permet de voir simultanément la vue de la scène et la vue du jeu, en fonction de différents états d'exécution. Il s'agit d'une étape vers l'égalisation de l'expérience d'édition de l'UE5 : édition et prévisualisation sur un seul écran sans basculer d'avant en arrière.

v0.3.3 version nocturne automatique + une pile de correctifs de build

Le pipeline de versions nocturnes a produit automatiquement la v0.3.3 ce jour-là. Mais le processus a également exposé et résolu un bon nombre de problèmes en cours de route : il manquait le binaire side-car Bun dans la version de bureau, l'extraction récursive des sous-modules échouait par intermittence et nécessitait un mécanisme de nouvelle tentative, les chemins d'alias Vite n'avaient pas suivi la restructuration des noms de packages et la version Tauri ne pouvait pas trouver les définitions de type qui avaient été déplacées des contrats. Un bug de remappage du GUID du workbench côté serveur et une racine d'actif platform-io ont également été corrigés. Chaque correctif est petit en soi, mais ensemble, ils constituent l'étape clé entre "le pipeline de publication automatique peut fonctionner" et "le pipeline de publication automatique fonctionne de manière fiable".

Ce que signifie cette journée

Le mot-clé de cette journée est « frontières ». Lorsqu'un projet passe du prototypage rapide à la maturité, l'une des choses les plus importantes à faire est de tracer des limites claires dans le code : quelles pièces sont des modules indépendants, qui dépend de qui, qui peuvent être publiés de manière indépendante. La division R4 et l'extraction des dépendances CLI tracent des limites à l'intérieur du dépôt principal ; le renforcement du miroir OSS trace une frontière entre les référentiels internes et publics ; la protection des succursales et le flux PR tracent une frontière entre les « personnes » et les « changements de code ». Une fois les limites claires, chaque partie peut évoluer, tester et sortir indépendamment, et le projet peut passer d'« une personne poussant une grosse boule de boue » à « un ensemble de modules clairs, chacun avançant de son propre chef ».