Jeudi 25 juillet 2024 à 16:56

Rich Harris explains this clearly. JSDoc for writing a lib. TypeScript for writing an app. (from)

Ce conseil entre en opposition avec ce que j'ai écrit en octobre 2023 :

Si je dois coder et publier une librairie sur npm alors, je choisis TypeScript.
Quand je dis librairie, je parle de librairie qui contient des classes, des fonctions ou des composants importés par d'autres projets.

Pourquoi est-ce que je choisis d'utiliser TypeScript pour les librairies ?

Je permets aux développeurs qui utilisent TypeScript dans leur projet, de pouvoir bénéficier de la documentation, l'autocomplétion, la détection des erreurs… de la librairie que j'aurais mise à disposition ;

Je n'ai pas vérifié, mais je pense que le typage de TypeScript permet à des outils d'auto générer une grande partie de la documentation d'une librairie.

Ce conseil entre aussi en opposition avec ce second élément que j'ai écrit en octobre 2023 :

Si je dois coder une application web, alors pour le moment, je choisis JavaScript.
Le code implémenté dans une application web, n'est généralement pas utilisé par des utilisateurs "externes". Par conséquent, je ne trouve pas très important de mettre à disposition une documentation aux autres développeurs. Je pense qu'à petite taille, l'effort ne vaut pas la peine. Ma réponse est peut-être différente si 10, 20… développeurs contribuent à la même base code 🤔.

Généralement, le code d'une application web est plutôt simple, beaucoup de CRUD et peu de librairie complexe.

Pour le moment, je pense que l'effort d'ajouter le boilerplate code de typage TypeScript (importer les types, d'ajouter le typage dans le code) ne sera pas compensé par les fonctionnalités de détection d'erreurs , d'autocomplétions et de refactoring que permet TypeScript.

Je pense qu'il serait bon que je revoie ma doctrine d'artisan développeur sur ce sujet.