- En 2023, une PR de refactorisation du dépôt Svelte, convertie vers un code basé sur JSDoc, a attiré l’attention des sceptiques de TypeScript
- L’équipe de Svelte a expliqué qu’il ne s’agissait pas d’une position anti-TypeScript, mais d’une forme de dépendance continue à TypeScript
- L’article insiste sur le fait qu’il ne faut pas opposer JSDoc et TypeScript, car JSDoc fait lui-même partie de TypeScript
- TypeScript agit comme moteur IntelliSense, en prenant en charge à la fois l’interprétation des commentaires JSDoc et l’autocomplétion du code
- Sans étape de build, JSDoc offre les mêmes capacités d’analyse statique et joue en pratique le même rôle que TypeScript dans les projets JS modernes
La PR de Svelte et l’origine de la controverse
- En mai 2023, une PR de refactorisation interne du dépôt Svelte est montée en première page de Hacker News
- Cette PR consistait à déplacer des déclarations de type de fichiers
.ts vers des commentaires JSDoc dans des fichiers .js
- Certains y ont vu un rejet des avantages de TypeScript
- Le créateur de Svelte, Rich Harris, a directement expliqué sur HN que « ce n’est pas anti-TypeScript »
- Il a précisé que l’engagement de Svelte envers TypeScript reste très fort
- Après cet épisode, de nombreux articles comparant « TypeScript vs JSDoc » sont apparus, popularisant l’idée de JSDoc comme un « TypeScript sans étape de build »
L’origine et la nature de TypeScript
- À la fin des années 2000 et au début des années 2010, JavaScript était perçu comme un langage manquant d’autocomplétion et de sûreté de typage
- Les développeurs de Microsoft y répondaient en utilisant ScriptSharp pour convertir du code C# en JS
- C’est dans ce contexte que TypeScript est né, au départ essentiellement comme un outil de build destiné à améliorer le développement JS
TypeScript, c’est IntelliSense
- TypeScript n’est pas seulement un langage, il joue aussi le rôle de moteur IntelliSense
- Même sans utiliser de fichiers
.ts, l’autocomplétion, les informations sur les paramètres et la navigation entre symboles sont fournies par le service de langage TypeScript
- Dans la plupart des éditeurs, lorsque l’on écrit du code JS, les services TypeScript fonctionnent déjà en arrière-plan
TypeScript, c’est JSDoc
- Le service de langage TypeScript sert aussi à interpréter les commentaires JSDoc
- Le CHANGELOG de TypeScript inclut fréquemment des ajouts liés à JSDoc
- Les projets basés sur JSDoc peuvent aussi être configurés avec
tsconfig.json, et la commande tsc permet d’effectuer la vérification de types
- Autrement dit, les développeurs qui utilisent JSDoc utilisent déjà TypeScript
Retour d’expérience sur des projets basés sur JSDoc
- L’auteur partage son expérience de réécriture du frontend d’un projet existant à partir d’annotations de types JSDoc
- À l’exception de fonctionnalités d’exécution comme les énumérations (
enum), la plupart des expressions TypeScript sont possibles avec JSDoc
- Les génériques ont une syntaxe un peu plus complexe, mais poussent à s’appuyer davantage sur l’inférence de types
- Dans un projet JSDoc, cliquer sur une fonction permet d’aller vers le vrai code, ce qui améliore l’expérience de développement
- L’écosystème d’outils TypeScript reste réutilisable dans les projets JSDoc
- Par exemple, des bibliothèques qui génèrent des types à partir de schémas OpenAPI ou GraphQL peuvent aussi générer des types sous forme de commentaires JSDoc
Conclusion et autres cas
- JSDoc n’est pas une alternative à TypeScript, il partage le même système d’analyse statique
- Il permet d’omettre l’étape de build tout en offrant une sûreté de typage équivalente
- L’article mentionne aussi un cas de migration du projet webpack vers JSDoc
- En tant qu’expert TypeScript, l’auteur affirme clairement : « JSDoc, c’est TypeScript »
Aucun commentaire pour le moment.