Tsd: Déprécier TSD

:+1:

pour les références à mettre à niveau depuis tsd

pack web+script dactylographié
https://github.com/angular/universal-starter/commit/cfb7b52b12e1da9de7ee7c2a452e7636c93aaa09

gulpjs + tapuscrit
https://github.com/angular/answers-app/pull/27/files

gulpjs avec tapuscrit
https://gist.github.com/gdi2290/e544407980e261acc172

commandes

$ npm uninstall tsd
$ rm -rf typings
$ npm install typings
$ typings init --upgrade
$ rm tsd.json
$ typings install

Juste un petit ajout aux étapes de migration @gdi2290 concernant quelque chose qui vient de m'arriver.
Si quelqu'un le suit et se retrouve avec des centaines de TS2300: duplicate indetifier ... lors de la compilation, la solution est ici https://www.npmjs.com/package/typings#maindts -and-browserdts

Comment faites-vous tsd link avec les saisies ?

Comment faites-vous un lien tsd avec les saisies ?

Vous ne le faites pas. Le lien TSD est défectueux et n'est pas vraiment une solution solide à long terme - car il repose sur des modules ambiants, provoque des identifiants en double et oblige généralement les utilisateurs à réinstaller des sous-dépendances. En supposant que vous vouliez exactement la même chose, vous pouvez faire typings install npm:<library>/<path-to-d-ts> --ambient . Très probablement, vous voulez une solution différente où les sous-dépendances sont gérées correctement. Dans ce cas, publiez votre fichier typings.json avec votre bibliothèque et faites typings install npm:<library> --save - les dépendances dans <library>/typings.json seront résolues.

A rencontré un problème lors de l'installation des saisies à partir d'un autre référentiel. Création d'un nouveau problème : https://github.com/typings/typings/issues/133

Vous vous demandez simplement quelle est la vision/l'intention ici pour DefinitelyTyped/tsd vs Typings ? Je comprends que Typings est décentralisé et qu'il peut parler à DefinitelyTyped, mais je sais aussi que Typings a également des dépôts pour certains projets populaires... d'où ma question.

Ne serait-il pas logique d'obliger toutes les définitions de type à être centralisées dans les installations de packages npm au lieu de répliquer la moitié de l'infrastructure à l'intérieur de nos projets locaux ?

• pas de tsd
• pas de saisie
• pas de répétition des efforts
• pas d'empreintes de dépendance répétées...

JSPM est un exemple alarmant

NPM dispose déjà des équipements nécessaires pour prendre en charge et traiter cela.

Est-ce que quelqu'un théorise même l'impact des dépendances transitoires ?

Je n'enverrais pas mon enfant dans une garderie, ce qui submerge la tâche d'une autre garderie ailleurs... quelque chose va finir par se déconnecter... sans parler d'une seule dépendance transitoire errant dans l'écosystème.

@nhhockeyplayer idéalement, ce serait le cas, mais pour que cela se produise, chaque auteur devrait inclure et maintenir des définitions de type.

En rapport

• https://github.com/moment/moment/pull/2916
• https://github.com/pwnall/node-xhr2/pull/20

Pour Angular 2, nous pouvons supposer que chaque module ng2 inclura des définitions de type, mais pour les autres modules, ce ne sera probablement pas le cas. Il y aura donc une communauté (ng2) qui bénéficiera davantage en s'assurant que chaque module de son écosystème comprend des définitions de type (le cas idéal).

@blakeembrey désolé d'avoir npm, ce qui pourrait amener des personnes à l'utiliser sans savoir au départ que le package est obsolète. C'est probablement parce qu'il n'y a pas eu de nouvelle version depuis que le package est devenu obsolète.

Si vous installez NPM, il le dit.

Edit : Mais je vais vérifier et sortir une nouvelle version.

Cool, alors ça va

pourriez-vous ajouter un avis de dépréciation à la page npm ?
Permet aux personnes qui effectuent des retours de comprendre plus facilement les frappes.

Ce serait cool d'expédier d'abord la version complète et finie de typings , puis de déprécier tsd car pour le moment, typings ne fait que rendre les choses plus difficiles et déroutantes avec ce gâchis avec plusieurs dépôts IMO. ??

Il y a quatre problèmes sur cette page de problèmes qui remontent maintenant à des mois, soulignant que tsd ne fonctionne plus pour installer des packages de base tels que jquery ou react. Déprécier ou arrêter le développement est une chose, mais il semble que tsd ait en fait été arrêté (?). Il s'agit d'un réel problème, d'autant plus qu'il semble qu'aucun service d'annonce explicite n'ait été carrément interrompu, car tsd est le genre d'outil qui pourrait faire partie d'un déploiement automatisé. Je viens de faire tuer un service Web car son déploiement automatisé exécute tsd, qui ne fonctionne plus.

Il dit qu'il est obsolète à l'installation depuis plus d'un an maintenant. Étant donné que TSD est basé sur GitHub, tout fonctionne toujours parfaitement bien. Ce que vous verriez, ce sont les changements DefinitelyTyped. L'architecture TSD ne peut pas gérer les changements, et la décision de TypeScript a été de prendre en charge NPM @types .