Publié le 22 octobre 2025
Chrome abandonne la fonctionnalité d'édition en direct des sources JavaScript. Elle sera déplacée derrière un indicateur expérimental dans Chrome 142 et nous prévoyons de la supprimer complètement dans Chrome 145 (février 2026). Nous ne supprimons pas d'autres fonctionnalités puissantes liées aux fichiers sources, comme les remplacements locaux, les espaces de travail ou les extraits, qui continueront d'être entièrement compatibles.
L'équipe Chrome DevTools s'efforce constamment de fournir aux développeurs des outils puissants et fiables. Dans le cadre de cet effort, nous devons parfois abandonner des fonctionnalités qui ne sont plus à la hauteur. Nous n'avons pas pris cette décision à la légère. Elle est basée sur le coût de maintenance disproportionnellement élevé de la fonctionnalité, sa faible utilisation et l'existence d'alternatives modernes supérieures. Nous savons que les modifications apportées à un workflow peuvent être perturbantes. Cet article vise à expliquer clairement nos raisons.
Qu'est-ce que la modification en direct ?
L'édition en direct vous permet de remplacer le contenu d'un fichier de script au moment de l'exécution, à la volée. Cela fonctionnait même lorsque le script était mis en pause à un point d'arrêt. Vous pouvez modifier le code JavaScript dans le panneau "Sources" et appliquer la modification en enregistrant le fichier (Cmd+S / Ctrl+S). Le débogueur corrigeait ensuite les fonctions déjà définies au moment de l'exécution. Si la fonction modifiée se trouvait dans la pile d'appels, elle serait également redémarrée.
L'objectif était de fournir un moyen de tester de petites modifications sans recharger complètement la page, ce qui effacerait l'état de l'application. Son objectif était donc similaire à celui du remplacement à chaud de modules (HMR, Hot Module Replacement) dans les piles de développement modernes.
Pourquoi le supprimons-nous ?
L'expérience utilisateur pour l'édition en direct a toujours été difficile. Le raccourci associé (Cmd+S / Ctrl+S) est généralement associé à l'enregistrement d'un fichier, mais pas à d'autres effets secondaires, ce qui peut être surprenant. En cas d'échec, le message peut être peu clair. Les outils de développement peuvent afficher un message d'avertissement tel que "LiveEdit failed: Functions that are on the stack (currently being executed) can not be edited" (Échec de LiveEdit : les fonctions qui se trouvent dans la pile (en cours d'exécution) ne peuvent pas être modifiées), qui peut être ignoré, laissant le développeur dans le doute quant à l'application de sa modification.
La situation se complique encore lorsque la modification en direct interagit avec d'autres fonctionnalités des outils de développement liées aux fichiers sources. Par exemple, la modification en direct du contenu d'un extrait DevTools peut induire en erreur les outils de développement en ce qui concerne l'identité de la source de l'extrait, ce qui fait que la nouvelle version s'affiche en tant que fichier en lecture seule. Lorsque la fonctionnalité Espaces de travail est activée, les outils de développement peuvent observer les modifications apportées à la source dans le système de fichiers et les appliquer de manière transparente à la page en direct. Ce comportement peut être attendu ou surprenant selon l'environnement de l'utilisateur et la configuration de sa chaîne d'outils.
Le problème initial que l'édition en direct tentait de résoudre (apporter des modifications sans perdre l'état de l'application) est désormais résolu plus efficacement par le remplacement à chaud de modules (HMR, Hot Module Replacement). HMR est une fonctionnalité standard des frameworks de développement Web modernes tels que React, Angular ou Vue. Il a le même effet dans l'espace utilisateur et à un niveau d'abstraction plus élevé. La modification en direct dans les outils de développement peut interférer avec ce processus, ce qui peut entraîner un comportement inattendu et défectueux.
Ces problèmes nuisent à l'expérience utilisateur. De plus, nos statistiques d'utilisation confirment que cette fonctionnalité n'est pas devenue un élément essentiel des workflows de la plupart des développeurs. Le nombre d'utilisateurs qui interagissent avec cette fonctionnalité est très faible et en baisse.
Coûts de maintenance et complexité technique élevés
Remplacer du code sur une page en ligne n'est pas simple en termes de définition d'une sémantique raisonnable, mais aussi en termes d'implémentation. Cela impose un coût d'ingénierie important au moteur JavaScript V8 et aux outils pour les développeurs Chrome, ce qui nécessite une réflexion approfondie dans de nombreuses parties de V8. Si vous ne faites pas très attention, la modification en direct peut entraîner des plantages difficiles à reproduire et à déboguer. Par exemple, si la nouvelle version d'une fonction contient un nombre différent de littéraux d'expression régulière, d'objet ou de fonction par rapport à la version précédente, la structure de données qui suit ces littéraux doit être soigneusement réconciliée.
Cette charge de maintenance ralentit l'implémentation de nouvelles fonctionnalités JavaScript et détourne les ressources de l'amélioration des fonctionnalités des outils de développement les plus utilisées.
Cette complexité a également entraîné de nombreux scénarios non pris en charge, y compris :
- Modification d'une fonction qui se trouve dans la pile d'appels, mais pas dans le frame le plus haut.
- Modifier des fonctions ou des générateurs asynchrones
- Modifier le code de premier niveau d'un module ES.
Autres solutions
Comme mentionné précédemment, le remplacement à chaud de modules (HMR) est une alternative plus populaire et supérieure à l'édition en direct sur plusieurs aspects clés :
- La modification en direct remplace des parties de l'ancienne version de la page en ligne au niveau du code source. En revanche, le HMR remplace l'ancienne version au niveau d'abstraction prévu par le framework Web, ce qui augmente les chances de migrer correctement l'état du composant et de l'application lors d'une mise à jour en direct.
- HMR fonctionne sur le code source que vous avez créé. Vous modifiez vos fichiers d'origine (par exemple, TypeScript, JSX) dans votre éditeur, et l'outil de compilation gère la mise à jour dans le navigateur. En revanche, la modification en direct n'affecte que les fichiers sources déployés, qui sont dans de nombreux cas la sortie de compilation générée par la chaîne d'outils.
- Il est robuste et bien intégré. Le HMR est un élément essentiel de la chaîne d'outils de développement moderne. Il offre une expérience fiable avec des commentaires clairs lorsque les mises à jour réussissent ou échouent.
La suppression de la modification en direct n'a aucune incidence sur deux autres fonctionnalités puissantes des outils de développement Chrome :
- Les remplacements locaux vous permettent d'intercepter une requête réseau et de diffuser un fichier local à la place. Il est idéal pour prototyper des modifications sur un site de production en ligne où vous n'avez pas accès au code source. Les modifications sont conservées lorsque vous actualisez la page.
- Les espaces de travail transforment les outils de développement en un éditeur plus puissant en créant une liaison bidirectionnelle entre le panneau "Sources" et les fichiers de votre projet local. Lorsque vous enregistrez une modification dans les outils de développement, elle est directement enregistrée dans votre système de fichiers. Cela peut ensuite déclencher le processus HMR ou de rechargement en direct de votre serveur de développement.
Conclusion
Nous supprimons la modification en direct, car son coût de maintenance élevé et sa faible utilisation la rendent non viable. L'écosystème de développement Web moderne a fourni une solution bien supérieure avec le remplacement à chaud de modules.
En supprimant cette fonctionnalité, nous pouvons concentrer nos efforts d'ingénierie sur les parties les plus importantes des outils pour les développeurs Chrome. Voici le calendrier de suppression :
- Dans un avenir proche : la fonctionnalité sera déplacée derrière une fonctionnalité expérimentale dans Chrome 142, disponible en tant que flag Chrome (chrome://flags/#devtools-live-edit).
- Chrome 145 (février 2026) : la fonctionnalité et le flag Chrome correspondant seront complètement supprimés.
N'hésitez pas à nous faire part de vos commentaires sur ce changement. Ajoutez vos commentaires sur le problème de commentaires.