J'utilise beaucoup de bibliothèques, les miennes et celles de tiers. Je vois que le répertoire "typings" en contient pour Jquery et WinRT... mais comment sont-elles créées ?
Plusieurs options s'offrent à vous en fonction de la bibliothèque en question, de la manière dont elle est rédigée et du niveau de précision que vous recherchez. Passons en revue ces options, par ordre décroissant de désirabilité.
Vérifiez toujours que DefinitelyTyped ( https://github.com/DefinitelyTyped/DefinitelyTyped ) en premier lieu. Il s'agit d'un repo communautaire rempli de milliers de fichiers .d.ts et il est très probable que la chose que vous utilisez s'y trouve déjà. Vous devriez également consulter TypeSearch ( https://microsoft.github.io/TypeSearch/ ) qui est un moteur de recherche pour les fichiers .d.ts publiés par NPM ; il aura un peu plus de définitions que DefinitelyTyped. Quelques modules fournissent également leurs propres définitions dans le cadre de leur distribution NPM, voyez donc si c'est le cas avant d'essayer d'écrire les vôtres.
TypeScript prend désormais en charge l'élément --allowJs et fera plus d'inférences basées sur JS dans les fichiers .js. Vous pouvez essayer d'inclure le fichier .js dans votre compilation avec l'option --allowJs pour voir si cela permet d'obtenir des informations suffisantes sur le type de produit. TypeScript reconnaîtra des choses comme les classes de style ES5 et les commentaires JSDoc dans ces fichiers, mais peut se tromper si la bibliothèque s'initialise d'une manière bizarre.
--allowJs
Si --allowJs vous a donné des résultats satisfaisants et que vous souhaitez écrire vous-même un meilleur fichier de définition, vous pouvez combiner les éléments suivants --allowJs avec --declaration pour voir la "meilleure estimation" de TypeScript sur les types de la bibliothèque. Cela vous donnera un point de départ décent, et peut être aussi bon qu'un fichier écrit à la main si les commentaires JSDoc sont bien écrits et que le compilateur a été capable de les trouver.
Si --allowJs n'a pas fonctionné, vous pouvez utiliser dts-gen ( https://github.com/Microsoft/dts-gen ) pour obtenir un point de départ. Cet outil utilise la forme de l'objet en cours d'exécution pour énumérer avec précision toutes les propriétés disponibles. L'avantage est que cela tend à être très précis, mais l'outil ne prend pas encore en charge la récupération des commentaires JSDoc pour remplir des types supplémentaires. Vous exécutez cet outil de la manière suivante :
npm install -g dts-gen
dts-gen -m <your-module>Cela permettra de générer your-module.d.ts dans le dossier en cours.
Si vous souhaitez faire tout cela plus tard et vous passer des types pendant un certain temps, TypeScript 2.0 vous permet désormais d'écrire
declare module "foo";qui vous permettra import les "foo" module de type any . Si vous souhaitez traiter une question globale plus tard, écrivez simplement
declare const foo: any;qui vous donnera un foo variable.
Il s'agit là d'une barrière importante à l'entrée dans de nombreux cas. Il serait intéressant de disposer d'un outil capable de produire au moins les "meilleures suppositions" basées sur l'inférence de type. Même si elles ne sont pas optimales, elles pourraient au moins être ajustées au fil du temps.
+1 - D'autres bonnes nouvelles : --declarations génère à la fois le .js et le fichier .d.ts ce qui signifie que vous n'avez besoin que d'une seule compilation.
Une collection de définitions de haute qualité pour les bibliothèques populaires est disponible à l'adresse suivante github.com/borisyankov/DefinitelyTyped
Semble actuellement passer des fichiers *.js dans tsc génère une erreur "Error reading file "angular-resource.js" : File not found". Il faut donc renommer explicitement les fichiers *.js en *.ts pour pouvoir utiliser tsc. Voir ce problème pour plus de détails - j'ai essayé d'utiliser ceci sur angularjs : typescript.codeplex.com/workitem/26
D'après ce que je sais, tsc peut compiler n'importe quel JavaScript valide, mais s'il ne s'agit pas de TypeScript valide (la compilation donne des avertissements), l'option --declarations ne produit pas de fichier .d.ts, donc à moins que votre bibliothèque ne soit écrite en TypeScript, vous devez toujours créer manuellement le fichier de déclarations.
Tel que décrit dans http://channel9.msdn.com/posts/Anders-Hejlsberg-Steve-Lucco-and-Luke-Hoban-Inside-TypeScript à 00:33:52 ils ont construit un outil pour convertir les métadonnées WebIDL et WinRT en TypeScript d.ts
Je chercherais une correspondance existante de vos bibliothèques JS tierces qui supportent script# ou SharpKit. Les utilisateurs de ces compilateurs croisés C# vers .js auront été confrontés au problème que vous rencontrez maintenant et auront peut-être publié un programme open source pour scanner vos librairies tierces et les convertir en classes C# squelettiques. Si c'est le cas, modifiez le programme d'analyse pour générer TypeScript à la place de C#.
A défaut, traduire une interface publique C# pour votre librairie tierce en définitions TypeScript peut être plus simple que de faire la même chose en lisant le JavaScript source.
Je m'intéresse particulièrement au framework ExtJS RIA de Sencha et je sais que des projets ont été publiés pour générer une interprétation C# pour script# ou SharpKit.
FYI : Je viens de créer mon premier fichier de définition de typecript pour Sencha/ExtJS : github.com/andremussche/extjsTypescript/blob/master/jsondocs/
Hey Camel Case, j'ai créé un blog sur l'utilisation d'ExtJs avec typescript : blorkfish.wordpress.com/2013/01/28/using-extjs-with-typescript
Je viens de publier un module pour Jackson (sérialiseur JSON) qui produit TypeScript des fichiers de définition des classes Java.
Il peut contribuer à générer d.ts pour les REST service développé en Java .
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
