Comment produire un fichier de définition "typings" .d.ts à partir d'une bibliothèque JavaScript existante?
J'utilise beaucoup de bibliothèques personnelles et tierces. Je vois que le répertoire "typings" en contient pour Jquery et WinRT ... mais comment sont-ils créés?
Plusieurs options s'offrent à vous en fonction de la bibliothèque en question, de son écriture et du niveau de précision recherché. Passons en revue les options, par ordre décroissant de pertinence.
Peut-être qu'il existe déjà
Vérifiez toujours DefinitelyTyped ( https://github.com/DefinitelyTyped/DefinitelyTyped ) en premier. Il s’agit d’un dépôt de communauté rempli de milliers de fichiers .d.ts et il est fort probable que ce que vous utilisez existe déjà. Vous devez également vérifier TypeSearch ( https://Microsoft.github.io/TypeSearch/ ), qui est un moteur de recherche pour les fichiers .d.ts publiés par NPM; cela aura légèrement plus de définitions que DefinitelyTyped. Quelques modules fournissent également leurs propres définitions dans le cadre de leur distribution NPM, alors voyez également si c'est le cas avant d'essayer d'écrire la vôtre.
Peut-être que vous n'en avez pas besoin
TypeScript prend désormais en charge l'indicateur --allowJs et générera davantage d'inférences basées sur JS dans les fichiers .js. Vous pouvez essayer d'inclure le fichier .js dans votre compilation avec le paramètre --allowJs pour voir si cela vous donne suffisamment d'informations sur le type. TypeScript reconnaîtra des éléments tels que les classes de style ES5 et les commentaires JSDoc dans ces fichiers, mais pourra être déclenché si la bibliothèque s’initialise de manière étrange.
Commencez avec --allowJs
Si --allowJs vous a donné des résultats corrects et que vous souhaitez écrire vous-même un meilleur fichier de définition, vous pouvez combiner --allowJs avec --declaration pour afficher la "meilleure estimation" de TypeScript concernant les types de la bibliothèque. Cela vous donnera un bon point de départ et peut être aussi bon qu'un fichier créé à la main si les commentaires JSDoc sont bien écrits et que le compilateur a pu les trouver.
Commencez avec dts-gen
Si --allowJs ne fonctionne pas, vous pouvez utiliser dts-gen ( https://github.com/Microsoft/dts-gen ) pour obtenir un point de départ. Cet outil utilise la forme d'exécution de l'objet pour énumérer avec précision toutes les propriétés disponibles. Du côté positif, cela a tendance à être très précis, mais l’outil ne prend pas encore en charge la suppression des commentaires JSDoc pour renseigner des types supplémentaires. Vous courez ça comme ça:
npm install -g dts-gen
dts-gen -m <your-module>
Cela générera your-module.d.ts dans le dossier actuel.
Appuyez sur le bouton Snooze
Si vous voulez juste tout faire plus tard et rester sans types pendant un moment, dans TypeScript 2.0, vous pouvez maintenant écrire
declare module "foo";
ce qui vous laissera import le module "foo" de type any. Si vous avez un global que vous voulez traiter plus tard, écrivez simplement
declare const foo: any;
ce qui vous donnera une variable foo.
Vous pouvez utiliser tsc --declaration fileName.ts comme le décrit Ryan ou spécifier declaration: true sous compilerOptions dans votre tsconfig.json si vous avez déjà eu un tsconfig.json dans votre projet.
La meilleure façon de traiter cela (si un fichier de déclaration n'est pas disponible sur DefinitelyTyped ) est d'écrire des déclarations uniquement pour les choses que vous utilisez plutôt que pour la bibliothèque entière. Cela réduit beaucoup le travail - et en plus, le compilateur est là pour aider en se plaignant des méthodes manquantes.
Comme le dit Ryan, le compilateur tsc a un commutateur --declaration qui génère un fichier .d.ts à partir d'un fichier .ts. Notez également que (sans les bogues), TypeScript est supposé être capable de compiler Javascript, vous pouvez donc transmettre le code javascript existant au compilateur tsc.
comme décrit dans http://channel9.msdn.com/posts/Anders-Hejlsberg-Steve-Lucco-and-Luke-Hoban-Inside-TypeScript à 00:33:52 ils avaient construit un outil convertir les métadonnées WebIDL et WinRT en TypeScript d.ts
Je rechercherais un mappage existant de vos bibliothèques JS tierces qui prennent en charge Script # ou SharpKit. Les utilisateurs de ces compilateurs croisés C # à .js auront fait face au problème auquel vous êtes confrontés et ont peut-être publié un programme open source pour analyser votre bibliothèque tierce et les convertir en classes squelettes C #. Si c'est le cas, piratez le programme du scanner pour générer TypeScript à la place de C #.
Sinon, traduire une interface publique C # pour votre bibliothèque tierce en définitions TypeScript peut s'avérer plus simple que de procéder de la même manière en lisant le code source JavaScript.
Mon intérêt particulier est le framework RIA ExtJS de Sencha et je sais que des projets ont été publiés pour générer une interprétation en C # pour Script # ou SharpKit.
Voici quelques exemples de PowerShell qui créent un fichier de définition TypeScript unique, une bibliothèque qui comprend plusieurs fichiers *.js avec JavaScript moderne.
Tout d’abord, changez toutes les extensions en .ts.
Get-ChildItem | foreach { Rename-Item $_ $_.Name.Replace(".js", ".ts") }
Deuxièmement, utilisez le compilateur TypeScript pour générer des fichiers de définition. Il y aura beaucoup d'erreurs de compilation, mais nous pouvons les ignorer.
Get-ChildItem | foreach { tsc $_.Name }
Enfin, combinez tous les fichiers *.d.ts en un index.d.ts, en supprimant les instructions import et en supprimant le default de chaque instruction d'exportation.
Remove-Item index.d.ts;
Get-ChildItem -Path *.d.ts -Exclude "Index.d.ts" | `
foreach { Get-Content $_ } | `
where { !$_.ToString().StartsWith("import") } | `
foreach { $_.Replace("export default", "export") } | `
foreach { Add-Content index.d.ts $_ }
Cela se termine par un seul fichier index.d.ts utilisable, contenant de nombreuses définitions.