État

Tous les systèmes opérationnelsMis à jour le 31 octobre 2026
console.logOpérationnel
Il y a 90 joursUn appel par frame modifiée, aucun au repos.Aujourd’hui
console.clearRarement utilisé
Il y a 90 joursÀ la première frame, après invalidate(), au repos une fois 100 frames empilées, et à 300.Aujourd’hui
YogaOpérationnel
Il y a 90 joursLayout flexbox WebAssembly, pointScaleFactor 1.Aujourd’hui
Turbolog encoderOpérationnel
Il y a 90 joursFiltrage par hachage des lignes et encodage %c par plages.Aujourd’hui
DevTools ThrottlerRespecté
Il y a 90 joursLimitation du viewport à 50 ms. Les frames sont espacées d’au moins 66 ms.Aujourd’hui
textjs.orgOpérationnel
Il y a 90 joursDocumentation, Apprendre, Playground, blog et boutique.Aujourd’hui

Test de performance en direct

Le pipeline @textjs/core s’exécute dans cet onglet sur un tableau de bord de 100×32 et écrit les frames dans une console en mémoire.

Frame complète
—
layout + rendu + encodage
Saisie
—
modification d’une ligne
Frame au repos
—
aucun changement
spans %c
—
3 200 cellules

Démarre automatiquement lorsque la page est inactive.

Historique des performances

packages/core/test/perf.test.ts à chaque jalon, sur la même machine (Apple M5 Pro · Bun 1.4.4). Moyenne de 1000 frames.

VersionFrame complèteSaisieAu reposspans %c
0.1.0mars 2025 · @textjs/core · 7c91cea0.194ms0.065ms0.043ms205
0.2.0juil. 2025 · textjs.org · 92437cc0.192ms0.067ms0.042ms205
0.3.0nov. 2025 · 10× input · 8c2d1b10.205ms0.065ms0.043ms146
0.3.0nov. 2025 · Mobile pass · e2e6e460.212ms0.067ms0.045ms146
0.4.0mai 2026 · Zero-flash frames · f007ade0.184ms0.046ms0.028ms146
1.0.0oct. 2026 · Text.js 1.0 · 57968b60.163ms0.011ms0.000ms149

Interface DevTools

bench/devtools dans Chrome for Testing : rendus vides, frames affichées et délai d’affichage, 5 s par exécution. Méthode de mesure.

PiloteFPSRendus videsAffichées / émisesDélai p50
Ajouter à la suite (en production)151.0%74 / 7510.4ms
Effacer à chaque frame1570.6%70 / 7560.4ms
Ajouter à la suite, sans cadence600.8%67 / 29531.2ms
Effacer à chaque frame6081.1%45 / 3009.8ms

Incidents passés

Du plus récent au plus ancien. Les heures sont en UTC.

octobre 2026

  • Pages bloquées sous l’en-tête sur iOS Safari27 oct. – 28 oct. 2026 · Résolu
    1. Résolu

      Cet incident est résolu.

    2. Sous surveillance

      Un correctif a été déployé. L’ancrage du défilement est désactivé (overflow-anchor: none). Nous surveillons la situation.

    3. Identifié

      Le titre principal peut encore rester coincé sous l’en-tête fixe après un défilement vers le bas puis vers le haut. L’ancrage du défilement de Safari ajuste la position de défilement.

    4. Sous surveillance

      Un correctif a été déployé. Ces éléments ne défilent désormais qu’horizontalement, et scrollbar-gutter: stable ne s’applique qu’aux appareils avec souris.

    5. Identifié

      Les onglets de fichiers, les blocs de code et les tableaux de texte ont un débordement vertical de 1 px dû au soulignement de l’onglet actif : ils défilent donc sur les deux axes et iOS leur attribue les balayages verticaux destinés à la page. scrollbar-gutter: stable provoque aussi un saut au premier défilement sur iOS.

    6. En cours d’investigation

      Nous examinons des signalements indiquant qu’il est impossible de remonter en haut des pages de textjs.org sur iOS Safari.

    Cet incident a touché : textjs.org.

    Analyse post-incident

    Les pages de textjs.org ne bougent pas pendant leur chargement : l’ancrage du défilement n’avait donc rien à corriger. Sur iOS Safari, il coinçait la section principale sous l’en-tête fixe et empêchait de remonter en haut de la page. ?debug=scroll sur textjs.org affiche désormais en direct les événements de défilement, de toucher et de redimensionnement, et identifie l’appelant de chaque appel programmatique de focus ou de défilement.

    Correctifs : 297c5d7, 55da525, 8424fcd · Journal des modifications : 1.0.0

  • Échec des tests des règles de lint en CI23 oct. 2026 · Résolu
    1. Résolu

      Le testeur lit désormais it.only à la demande, lorsqu’un test appelle RuleTester.itOnly. La CI réussit.

    2. Identifié

      Bun lève une exception à la lecture de it.only lorsque la variable d’environnement CI est définie. Le testeur de règles assigne RuleTester.itOnly = it.only à l’import, ce qui fait échouer son chargement.

    3. En cours d’investigation

      La suite de tests de eslint-plugin-textjs échoue en CI avant l’exécution du moindre test de règle. Les exécutions locales réussissent.

    Analyse post-incident

    @typescript-eslint/rule-tester reçoit ses fonctions de test sous forme de propriétés statiques de RuleTester. Le correctif enveloppe it.only dans une fonction. Aucun paquet ni aucune page n’a été affecté.

    Correctif : eca3f78

  • Décalage de mise en page sur /playground et /opencode21 oct. – 22 oct. 2026 · Résolu
    1. Résolu

      Le décalage cumulé de mise en page est de 0 sur toutes les routes.

    2. Sous surveillance

      Un correctif a été déployé. Les deux pages utilisent le même layout de pavé, et la taille est ajoutée à la suite sans déplacer « Ajuster la console ». Nous surveillons la situation.

    3. Identifié

      Le contrôle de taille de la console ajoute la taille mesurée à la suite de son libellé après l’hydratation (Fit console · 120×36), ce qui déplace le nœud texte « Ajuster la console ». Les lignes supérieure et inférieure du pavé ont aussi des hauteurs différentes entre les deux pages, ce qui recentre le pavé lors de la navigation.

    4. En cours d’investigation

      Notre audit des décalages de mise en page indique un décalage cumulé de 0,0001 sur /playground et /opencode. Toutes les autres routes couvertes affichent 0. Le pavé de focus se déplace aussi lors de la navigation entre les deux pages.

    Cet incident a touché : textjs.org.

    Analyse post-incident

    Le pavé dispose désormais d’emplacements supérieur et inférieur de hauteur fixe, et chaque démo réserve les mêmes lignes : changer de page ou de démo ne déplace donc rien. Le panneau de connexion OpenCode affiche une ligne d’état dans chaque état, avec un squelette jusqu’à son hydratation. apps/web/scripts/e2e-layout.mjs vérifie que les boîtes sont identiques entre les routes, les démos, les tailles de fenêtre et les états de connexion.

    Correctif : 8f22b9b · Journal des modifications : 1.0.0

  • La barre latérale de la documentation disparaît en bas des pages longues16 oct. – 17 oct. 2026 · Résolu
    1. Résolu

      Cet incident est résolu.

    2. Sous surveillance

      Un correctif a été déployé. Les chapitres d’Apprendre affichent eux aussi le pied de page dans la colonne de contenu. Nous surveillons la situation.

    3. Identifié

      La barre latérale des chapitres d’Apprendre présente le même problème.

    4. Sous surveillance

      Un correctif a été déployé. Les pages de documentation affichent le pied de page dans la colonne de contenu, afin que le layout atteigne le bas de la page.

    5. Identifié

      La barre latérale utilise position: sticky dans le layout de la documentation, et le pied de page du site s’affiche après ce layout. Un élément fixe ne reste ancré que tant que son bloc conteneur est à l’écran : lorsque le pied de page apparaît au défilement, il entraîne donc la barre latérale avec lui.

    6. En cours d’investigation

      Nous examinons des signalements indiquant que la barre latérale de la documentation disparaît en bas des pages longues lors du défilement.

    Cet incident a touché : textjs.org.

    Analyse post-incident

    Les pages avec une barre latérale fixe (documentation et chapitres Apprendre) affichent le pied de page dans leur colonne de contenu. Les autres pages conservent le pied de page partagé.

    Correctif : 131ac96 · Journal des modifications : 1.0.0

  • Nom de paquet textjs indisponible sur npm14 oct. – 15 oct. 2026 · Résolu
    1. Résolu

      Cet incident est résolu.

    2. Sous surveillance

      Le paquet du framework et de la CLI est désormais @textjs/next, dans le même espace de noms que @textjs/core et @textjs/react. Les imports passent de textjs à @textjs/next.

    3. Identifié

      Le nom textjs appartient à un autre paquet npm depuis le 25 mars 2016.

    4. En cours d’investigation

      La publication du paquet du framework textjs sur npm échoue avec 403 Forbidden.

    Analyse post-incident

    À partir de Text.js 1.0, les applications importent depuis @textjs/next au lieu de textjs, et le pont OpenCode est bunx @textjs/app proxy, qui s’exécute depuis n’importe quel répertoire.

    Text.js 1.0 : un renommage · Journal des modifications : 1.0.0

septembre 2026

  • Calques de rendu vides aux sauts de ligne15 sept. – 16 sept. 2026 · Résolu
    1. Résolu

      Cet incident est résolu.

    2. Sous surveillance

      Un correctif a été déployé. Les sauts de ligne qui ne prolongent pas une séquence réinitialisent désormais %c avec un style vide, pour que DevTools émette un simple saut de ligne. Chaque frame contient un seul rideau.

    3. Identifié

      Lorsqu’une séquence stylée se termine à un saut de ligne, le \n est écrit dans le span %c de la séquence. DevTools scinde le span au saut de ligne, et la partie vide restante devient un span display: inline-block avec contain: paint, qui obtient son propre calque de rendu.

    4. En cours d’investigation

      Nous examinons la présence d’éléments <span> vides à la plupart des sauts de ligne dans les frames DevTools, et d’un span rideau doublé sur certaines frames.

    Cet incident a touché : Turbolog encoder.

    Analyse post-incident

    Les spans de même style fusionnent toujours au-delà des sauts de ligne. Le rideau a aussi été déplacé sur sa propre ligne : DevTools place le lien source (VM12:1) à droite de la première ligne d’un message, et un rideau en ligne laissait ce lien à côté de la ligne 0, réduisant sa largeur.

    Journal des modifications : 1.0.0

août 2026

  • Latence d’affichage accrue après console.clear27 août – 31 août 2026 · Résolu
    1. Résolu

      Le retard d’affichage médian dans bench/devtools est de 10,4 ms. Le correctif est inclus dans Text.js 1.0.

    2. Sous surveillance

      Un correctif a été déployé. Après toute frame qui efface la console, le moteur de rendu attend une fois 110 ms, afin que les frames suivantes arrivent plus de 50 ms après le dernier rafraîchissement de DevTools et empruntent sa voie immédiate.

    3. Identifié

      Après un effacement, DevTools insère une ligne « La console a été effacée ». Elle prend le créneau immédiat du mécanisme de limitation et reporte la frame suivante sur le minuteur de 50 ms. Avec des frames espacées de 66 ms, toutes les frames suivantes restent sur ce minuteur.

    4. En cours d’investigation

      bench/devtools indique un retard d’affichage médian de 63 ms une fois la console effacée. Le retard reste à ce niveau pour toutes les frames suivantes.

    Cet incident a touché : DevTools Throttler, console.clear.

    Analyse post-incident

    Les entrées discrètes sont toujours rendues de façon synchrone lorsque l’intervalle entre les frames le permet.

    Rompre le verrouillage de phase · Journal des modifications : 1.0.0

  • Indicateur de chargement désalignant les lignes dans la console DevTools11 août – 12 août 2026 · Résolu
    1. Résolu

      Cet incident est résolu. Le correctif est inclus dans Text.js 1.0.

    2. Sous surveillance

      Un correctif a été déployé. L’indicateur dots par défaut dessine désormais des blocs de quadrant (▘ ▝ ▗ ▖), chacun occupant une cellule dans Menlo. Les frames braille sont disponibles avec variant="braille" pour les terminaux.

    3. Identifié

      L’indicateur de chargement par défaut dessine des motifs braille (U+2800 à U+28FF). Text.js compte chacun comme une cellule, mais Menlo, la police de la console DevTools sur macOS, n’a pas de glyphes braille. Le glyphe de remplacement est plus large qu’une cellule et décale le reste de la ligne vers la droite.

    4. En cours d’investigation

      Sur macOS, les lignes contenant un <Spinner> sont désalignées dans DevTools. Les cellules à droite de l’indicateur de chargement sortent de la grille.

    Cet incident a touché : console.log.

    Analyse post-incident

    LineChart dessine des points de quadrant par défaut pour la même raison. Le braille est disponible avec marker="braille".

    Journal des modifications : 1.0.0

mai 2026

  • Rendus vides fréquents dans la console DevTools5 mai – 19 mai 2026 · Résolu
    1. Résolu

      Le correctif est disponible dans Text.js 0.4.0. Les rendus vides sont à 1,0 %, tous sur la première frame.

    2. Sous surveillance

      textjs.org ajoute désormais les frames à la suite au lieu d’effacer la console. Un span rideau de largeur nulle masque les frames précédentes, et les frames sont espacées d’au moins 66 ms.

    3. Identifié

      DevTools applique console.clear() de façon synchrone, mais limite le rendu des nouveaux messages à un toutes les 50 ms. Chaque frame supprime immédiatement la précédente et s’affiche jusqu’à 50 ms plus tard. Dans bench/devtools, un tableau de bord de 100×32 était vide lors de 70,6 % des rendus DevTools à 15 fps et de 81,1 % à 60 fps.

    4. En cours d’investigation

      Nous examinons des signalements de la console DevTools qui devient brièvement vide entre les frames sous charge.

    Cet incident a touché : console.clear, DevTools Throttler.

    Analyse post-incident

    Depuis 0.1.0, Turbolog envoyait un console.clear() et un console.log() par frame modifiée. bench/devtools, qui pilote la véritable interface DevTools dans Chrome for Testing, a été créé pour mesurer cet incident et a produit les chiffres du tableau de l’interface DevTools ci-dessus.

    Correctif : f007ade · Turbolog : éliminer le flash · Journal des modifications : 0.4.0

avril 2026

  • Chemins de fichiers restylés en liens dans les frames de console14 avr. – 15 avr. 2026 · Résolu
    1. Résolu

      Cet incident est résolu.

    2. Sous surveillance

      Un correctif a été déployé. L’encodeur insère un word joiner (U+2060) dans les textes path:line, //host:port et data:, sauf si la cellule autorise les liens.

    3. Identifié

      DevTools transforme les URL et les textes path:line et //host:port des messages de console en liens et leur impose les couleurs de son thème. L’encodeur séparait déjà :// et www., mais path:line et le //host:port suivant un schéma sont encore reconnus.

    4. En cours d’investigation

      Du texte comme src/app.tsx:12 et http://localhost:3000 s’affiche dans la couleur des liens de DevTools au lieu de son style %c.

    Cet incident a touché : Turbolog encoder.

    Analyse post-incident

    :// et www. contiennent un word joiner depuis 0.1.0. Les cellules qui doivent rester cliquables définissent l’attribut allow-link et sont écrites sans modification.

    Journal des modifications : 0.4.0

novembre 2025

  • Frappes retardées dans les applications de console4 nov. – 18 nov. 2025 · Résolu
    1. Résolu

      Le correctif est disponible dans Text.js 0.3.0.

    2. Sous surveillance

      Un correctif a été déployé. Les entrées discrètes, comme une frappe ou un collage, sont désormais rendues de façon synchrone dans la même tâche. Les autres mises à jour sont toujours validées sur requestAnimationFrame.

    3. Identifié

      Chaque mise à jour, y compris une frappe, attend le prochain requestAnimationFrame avant que React ne valide les changements et que la frame soit journalisée.

    4. En cours d’investigation

      La saisie dans les applications de console accuse un retard sur le clavier, surtout dans OpenCode sur textjs.org.

    Cet incident a touché : textjs.org.

    Analyse post-incident

    Les frappes n’attendent plus la prochaine frame d’animation. Les validations qui ne proviennent pas d’une entrée, comme les minuteurs et les données en streaming, restent regroupées par frame d’animation.

    Correctif : 8c2d1b1 · Journal des modifications : 0.3.0