
# Avancé

Les détails internes. Si vous intégrez Phasis, vous pouvez ignorer cette section. Si vous modifiez le moteur, chaque page ici est essentielle.

## Pages

- **[Architecture](https://phasis.inline0.dev/fr/docs/advanced/architecture)** — comment le code source devient exécutable : lexer → parseur → AST → compilation en bytecode → VM à bytecode avec repli sur l’interpréteur arborescent. Chargeur de modules, realms, rôle de `Phasis\Engine` comme frontière du realm.
- **[VM à bytecode](https://phasis.inline0.dev/fr/docs/advanced/bytecode-vm)** — jeu d’opcodes, boucle de dispatch, caches inline, chemin rapide de transpilation source JsToPhp, heuristique function-shape canSkipEnvAlloc, et cas où les appels suivent le chemin bytecode ou celui de l’interpréteur arborescent.
- **[Benchmarks](https://phasis.inline0.dev/fr/docs/advanced/benchmarks)** — chiffres `bench/` actuels, leur interprétation, pourquoi ~100× V8 constitue le plafond en régime stable des interpréteurs arborescents et ce qui pourrait réduire l’écart.
- **[Tests](https://phasis.inline0.dev/fr/docs/advanced/testing)** — modèle par oracle. Chaque changement est vérifié à l’aide de trois références indépendantes : Node.js (référence de la spécification V8), test262 et la suite d’égalité octet par octet pour les bibliothèques populaires.

## Conventions de contribution

- **Ne touchez pas au moteur central sans raison sérieuse.** Tout ce qui se trouve sous `src/Runtime/`, `src/Bytecode/`, `src/Lexer/`, `src/Parser/`, `src/Regex/` est sur le chemin critique de test262. Le modifier sans vérification test262 correspondante risque fortement d'introduire des régressions. Les éléments intégrés (`src/BuiltIn/`) sont plus sûrs, car les sous-suites test262 de chaque élément intégré détectent localement les régressions.
- **Utilisez des traits pour organiser le code, pas des classes.** Quand un fichier dépasse environ 2K lignes, répartissez-le dans des fichiers de traits sous un répertoire frère (`src/BuiltIn/Temporal/`, `src/Runtime/Parts/`, etc.) au lieu de créer de nouvelles classes — cela permet aux recherches `self::` de fonctionner et évite de casser la surface des méthodes privées API.
- **Exécutez `bin/verify-all` localement avant de pousser vos modifications.** Il exécute PHPStan, PHPCS, toutes les suites PHPUnit (unitaires, oracle, populaires, wpt) ainsi que la régression de l'oracle. La CI exécute les suites WPT et populaires lorsque des modifications touchent `src/` ; la matrice test262 complète est lancée manuellement. Échantillonnez donc localement les catégories test262 concernées.
- **Pour chaque ajout à la plateforme Web API, ajoutez un fixture WPT.** Déposez le `.any.js` de `tests/Wpt/upstream/<area>/` dans `tests/Wpt/fixtures/<category>/` et le runner le détectera.

## Voir aussi

- [Compatibilité](https://phasis.inline0.dev/fr/docs/compatibility) — méthode de mesure des sorties oracle.
- [CLI référence](https://phasis.inline0.dev/fr/docs/cli) — `bin/phasis`, `bin/test262`, `bin/wpt`.
