9025c64c0b
Système de gestion de traductions pensé en CMS headless : un back-office pour ceux qui traduisent, une API pour ce qui consomme. Architecture - Symfony 7.4 / API Platform 4.3 / MariaDB 11.4, SPA React 19 servie en même origine — ce qui rend viable le cookie de session plutôt qu'un jeton en localStorage. - Deux APIs séparées : Management (session ou clé) et Delivery (stateless, clé seule). Les fusionner ferait porter à chaque lecture de bundle le coût de la session. - Stockage canonique en ICU MessageFormat, sérialisation par plateforme. Le format d'une plateforme ne contamine pas la base. - Publication par releases immuables ; le déploiement est un déplacement de pointeur, donc le rollback aussi. - Isolation multi-organisation par filtre Doctrine, avec un test d'architecture qui casse la CI si une entité échappe à l'invariant. Éditeur, deux vues - Par langue : source et cible, jamais douze colonnes. Grille virtualisée, saisie sans bouton « Enregistrer », panneau de contexte permanent. - Par clé : une clé, toutes ses langues empilées et repliées. Répond à « ce libellé est-il prêt partout ? ». - Mode Focus dans les deux : une file à vider, ⌘↵ pour enchaîner. - Le traducteur ne voit jamais d'ICU : pastilles de variables, un champ par catégorie CLDR de la langue cible. Administration - Deux niveaux : projet (membres, clés API, plateformes) et organisation (annuaire des comptes, création de projets). - Invitations par e-mail, jeton 256 bits stocké haché. - Désactiver un compte coupe les sessions en cours, pas seulement les connexions suivantes. - Les plateformes s'archivent ; ni elles ni les environnements ne se suppriment — la trace explique pourquoi telle clé existe. CLI tqs - PHAR autonome de 3 Mo, autoloader généré : le dépôt client ne dépend ni de Composer ni de la disponibilité de TQ-Slator. - init / push / pull / status ; le sync est non destructif par défaut et son prune est scopé plateforme. 126 tests, PHPStan niveau 8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
43 lines
1.6 KiB
TypeScript
43 lines
1.6 KiB
TypeScript
import { defineConfig } from 'vite';
|
|
import react from '@vitejs/plugin-react';
|
|
import tailwindcss from '@tailwindcss/vite';
|
|
import { resolve } from 'node:path';
|
|
|
|
export default defineConfig({
|
|
root: 'assets',
|
|
plugins: [react(), tailwindcss()],
|
|
|
|
resolve: {
|
|
// Les `paths` de tsconfig ne servent qu'à TypeScript : le bundler a
|
|
// besoin de sa propre déclaration, sinon la compilation passe et le
|
|
// build échoue — l'ordre le plus déroutant possible.
|
|
alias: { '@': resolve(import.meta.dirname, 'assets') },
|
|
},
|
|
|
|
build: {
|
|
// Le front est construit DANS public/, donc servi par FrankenPHP en
|
|
// même origine que l'API. C'est la condition du choix « cookie de
|
|
// session » : un front sur un autre domaine imposerait CORS avec
|
|
// credentials et un cookie SameSite=None, ce qui rouvrirait le CSRF.
|
|
outDir: resolve(import.meta.dirname, 'public'),
|
|
|
|
// public/ contient déjà index.php et les assets des bundles Symfony :
|
|
// le vider effacerait le point d'entrée de l'application.
|
|
emptyOutDir: false,
|
|
|
|
assetsDir: 'build',
|
|
manifest: false,
|
|
sourcemap: true,
|
|
},
|
|
|
|
server: {
|
|
port: 5173,
|
|
// En développement, Vite sert le front et relaie l'API vers FrankenPHP.
|
|
// Le navigateur ne voit qu'une seule origine : les cookies de session
|
|
// fonctionnent exactement comme en production.
|
|
proxy: {
|
|
'/api': { target: 'http://localhost:8080', changeOrigin: false },
|
|
'/delivery': { target: 'http://localhost:8080', changeOrigin: false },
|
|
},
|
|
},
|
|
});
|