Typescript: Veuillez fournir une saisie semi-automatique pour<reference>et importer des chemins</reference>

Créé le 22 juil. 2014  ·  36Commentaires  ·  Source: microsoft/TypeScript

Salut,

Visual Studio (2013 Ultimate) fournit intellisense pour l'attribut src pour les éléments de script, en lisant le système de fichiers et en affichant les fichiers ou dossiers disponibles.

Image

Ce sera très utile si des fonctionnalités similaires peuvent être fournies pour <reference> et les instructions d'importation:


 <reference path="foo/    <--- here

import foo = require('foo/   <--- and here

API Moderate Suggestion Visual Studio help wanted

Commentaire le plus utile

C'est de loin ma plus grosse perte de temps lorsque je travaille avec du tapuscrit. S'il peut compléter automatiquement mon nom de classe, il devrait être en mesure de s'assurer qu'il existe une instruction d'importation pour celui-ci. Je finis par faire une supposition éclairée sur le chemin, puis en y ajoutant "../" et en attendant de voir si le swiggly rouge s'en va et en répétant jusqu'à ce qu'il le fasse.

Ce serait également bien de pouvoir "optimiser les importations" et de supprimer automatiquement les importations inutilisées.

Tous les 36 commentaires

: +1:

@NoelAbrahams btw

image

@basarat , intéressant. Je n'ai jamais utilisé de réaffûteur et je ne pense pas que cela va changer. Donc, pour les utilisateurs d'outils anti-tiers comme moi, j'espère que cela ira dans le plugin VS. :sourire:

: +1:

@NoelAbrahams btw atom-typescript complètera vos références: https://github.com/TypeStrong/atom-typescript#relative -paths

et même le module externe de saisie semi-automatique "nom" et "./chemin"s: rose:

Je ne sais pas si @ ahmad-farid a réellement eu la chance de commencer là-dessus, mais @basarat , est-ce que vous pensez que cette fonctionnalité pourrait potentiellement contribuer à TypeScript lui-même, ou est-elle plus étroitement couplée à atom-typescript?

est-il plus étroitement couplé à atom-typescript

Étroitement couplé en ce sens que je fais la tokenisation _poor_ pour les détecter:
https://github.com/TypeStrong/atom-typescript/blob/d5fb4707b989f15d3be8d57cfa28d88af50b4702/lib/main/atom/typescriptGrammar.ts#L68 -L76

Le code pour obtenir ces résultats est un peu plus simple

N'a pas besoin d'être étroitement couplé. Mais c'est juste comme ça que je l'ai écrit en tant que consommateur TypeScript et il ne peut pas y avoir de RP copier-coller.

Si quelqu'un devait PR cela, il ferait la détection _am I dans une chaîne de commentaire / importation de référence? _ Sur getCompletionInfo , puis y ferait les recherches.

Également plus de cerceaux possibles: https://github.com/Microsoft/TypeScript/pull/2173#issuecomment -89347414

Ne pouvez-vous pas glisser-déposer pourcela semble beaucoup plus facile.

pour l'importation de saisie semi-automatique, je suggérerais d'avoir une autre fonctionnalité comme "Copier la référence d'importation" dans l'explorateur de solutions, cliquez avec le bouton droit sur le fichier, puis collez-le dans un fichier qui écrirait comme 'import fileName = require ("../ dir / filename");'. Cela devrait garder une trace des chemins relatifs et de la casse des noms de fichiers.

si quelqu'un peut me guider où devrais-je le chercher dans cette source, je peux essayer d'ajouter.

Le code lié à Visual Studio que vous devez modifier pour apporter des modifications comme celle-ci n'est pas open source pour le moment.

Nous avons en fait eu une génération de références par glisser-déposer /// à un moment donné, mais elle est très indécelable et ne s'adapte pas très bien (voulez-vous vraiment faire glisser et déposer plus de 5 éléments de parties disparates de votre solution dans des dossiers qui peuvent être fermés dans explorateur de solution?).

Dans tous les cas, ce type d'interactions serait bien, mais cela devrait également être plus facile à faire dans un flux de travail axé sur le clavier, ce qui aiderait la saisie semi-automatique.

nous avons tellement de modules que parcourir le système de fichiers n'est pas pratique, et certains d'entre eux sont des noms de modules externes générés, pas des fichiers. Nous aimerions donc lancer une indexation périodique, puis en fournir une liste aux services linguistiques (par exemple, un RPC, ou un fichier que nous installons sur le disque local, etc.)

+1 ayant l'auto-complétion à l'importation sera génial.

Je vois encore beaucoup de requêtes pour cela, d'autant plus que maintenant avec VSCode et Salsa, c'est effectivement une régression (c'est-à-dire qu'ils donnaient des complétions sur require pour les modules). Je pense que certains éditeurs non-Microsoft fournissent déjà un support pour cela dans TypeScript / JavaScript. Nous devrions envisager de tirer ceci (ping @mhegazy ).

Honnêtement, c'est la seule raison pour laquelle je dois continuer à utiliser Webstorm, qui a construit des gestionnaires personnalisés pour les importations et les références complètes automatiques. Et pas seulement la saisie semi-automatique, mais également les corrections automatiques.

Nous avons environ 25k lignes d'atmosphère Typescript et ce serait vraiment bien si cette fonctionnalité pouvait être introduite afin que tous les autres IDE puissent l'adopter.

Nous avons également besoin de cette fonctionnalité. C'est l'un des plus gros inconvénients venant d'un monde Java où un refactoring peut facilement être fait en utilisant eclipse ou intellij.

Je voudrais intervenir ici, bien que l'achèvement automatique de l'importation soit très utile et agréable à travailler, je tiens à souligner que cette fonctionnalité est l'une des raisons pour lesquelles la tempête Web n'est pas optimale. L'analyse de node_modules sur une base continue crée une surcharge importante de mémoire et de traitement qui ralentirait un peu VSCode, je pense.

En bref, j'adorerais cette fonctionnalité, mais pas au prix de la vitesse impressionnante de VSCode. En tant qu'éditeur léger, je m'attends à avoir vitesse, puissance et flexibilité au détriment de la commodité. Un IDE lent a un coût total de possession plus élevé en raison de sa capacité à créer constamment des retards où un éditeur plus léger vous permet de parcourir à un rythme continuellement ininterrompu.

@mikepc curiou si vous avez utilisé d'autres implémentations comme https://packagecontrol.io/packages/AutoFileName et comment vous trouvez sa performance pour les projets sur lesquels WebStorm se débat.

Je pense que vous pouvez avoir un algorithme sophistiqué pour l'achèvement de l'importation qui ne souffre pas des problèmes de performances que vous décrivez. Une optimisation consisterait à utiliser le champ d'exclusion dans le tsconfig pour exclure des fichiers et des dossiers de l'index d'auto-complétion. Désormais, seuls les chemins des fichiers de projet seront automatiquement complétés. Si quelqu'un importe un module à partir d'une dépendance, alors dactylographié sait où se trouve cette dépendance. Ainsi, le dossier de la dépendance importée est également inclus dans l'index. La suppression peut être gérée via des compteurs de référence pour chaque module de dépendance.

Je n'ai aucune connaissance du fonctionnement interne des différentes méthodes de
traversée de paquet, et si effectivement il est possible de l'inclure avec seulement un
petit coup de performance J'adorerais l'avoir ajouté. j'apprécie
en utilisant VSCode. Je veux juste continuer à en profiter.

Le lun 18 avril 2016 à 12:37 PM, Frederik Schubert <
[email protected]> a écrit:

Je pense que vous pouvez avoir un algorithme sophistiqué pour l'achèvement de l'importation
qui ne souffre pas des problèmes de performances que vous décrivez. Un
l'optimisation consisterait à utiliser le champ d'exclusion dans le tsconfig pour exclure
fichiers et dossiers de l'index de saisie semi-automatique. Maintenant seulement le fichier de projet
les chemins se compléteront automatiquement. Si quelqu'un importe un module à partir d'une dépendance, alors
typescript sait où se trouve cette dépendance. Ainsi, le dossier du
la dépendance importée est également incluse dans l'index. La suppression pourrait être
géré via des compteurs de référence pour chaque module de dépendance.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/Microsoft/TypeScript/issues/188#issuecomment -211543527

Après avoir lu cette rubrique, je ne suis toujours pas sûr que cela sera implémenté dans VS Code? C'est juste ennuyeux de faire tout cela manuellement à chaque fois.

C'est de loin ma plus grosse perte de temps lorsque je travaille avec du tapuscrit. S'il peut compléter automatiquement mon nom de classe, il devrait être en mesure de s'assurer qu'il existe une instruction d'importation pour celui-ci. Je finis par faire une supposition éclairée sur le chemin, puis en y ajoutant "../" et en attendant de voir si le swiggly rouge s'en va et en répétant jusqu'à ce qu'il le fasse.

Ce serait également bien de pouvoir "optimiser les importations" et de supprimer automatiquement les importations inutilisées.

Oui s'il vous plaît, c'est une telle douleur dans le cul.

des nouvelles à ce sujet ?

des nouvelles à ce sujet ?

J'y travaille. mais rien à signaler.

Y a-t-il eu accord sur la manière dont cela devrait fonctionner pour les importations?

J'imagine que ce serait une expérience utilisateur agréable: dans VS Code, si je clique sur Ctrl + T (Tapez pour rechercher des symboles à l'échelle du projet) et que je choisis un symbole, cela me permettrait de générer une déclaration d'importation pour cela.

Un tout petit peu lié, une raison pour laquelle la liste des symboles à l'échelle du projet ne me montre pas les variables exportées, par exemple export let globalStyles = {} mais elle apparaît dans la liste des symboles de fichier. La liste des symboles à l'échelle du projet doit afficher tous les symboles pour qu'elle fonctionne comme interface graphique d'importation.

@Ciantic Cela sonne bien. Je préfère l'avoir lors de l'utilisation d'Intellisense, il importe automatiquement les éléments qu'il complète automatiquement qui ne sont pas dans la portée. Je voudrais également avoir la possibilité de nettoyer les importations inutilisées ou d'autres fonctionnalités pour les trier. Une autre chose qui serait bien est quelque chose comme si vous supprimez la dernière utilisation d'un élément importé, l'instruction d'importation est supprimée.

J'ai construit ceci pour arrêter le problème pour moi-même https://marketplace.visualstudio.com/items?itemName=Sammons.ts-import-assistance , le code est ici: https://github.com/Sammons/ts-import-assistance . Ce n'est pas super intelligent mais il fait ce dont j'ai besoin. Essentiellement, je n'ai trouvé aucun moyen facile de voir quels symboles manquaient dans le document actuel - c'est donc une commande que vous pouvez exécuter pour rechercher et importer le symbole que vous avez mis en évidence.

Cela s'appuie simplement sur la recherche de symboles intégrée.

Je suis également tombé sur et j'ai utilisé ce plug-in VS Code pour aider entre-temps:
https://marketplace.visualstudio.com/items?itemName=steoates.autoimport

Cela m'a aidé _tremendously_ lorsque je commutais un projet d'espaces de noms (modules internes) vers des modules externes.

@Taytay Merci,

Oh dang @rolandoldengarm. Compris. (Pour ce que ça vaut, j'ai trouvé que l'auteur était réactif dans les problèmes au cas où vous voudriez le poursuivre.)

@Taytay Merci pour l'info, mais j'ai fait ma propre extension ;-) actuellement je réécris la logique pour la rendre plus rapide. Je n'utilise pas de regex pour analyser les fichiers (comme beaucoup d'autres le font), mais j'utilise le compilateur dactylographié pour générer l'AST de la source.
Si vous êtes intéressé, vous le trouverez ici: https://marketplace.visualstudio.com/items?itemName=rbbit.typescript-hero

@buehler Cela fonctionne très bien! N'avait pas encore de problèmes. Certainement beaucoup plus rapide que de tout taper.

s'il vous plaît quel est le statut de celui-ci? la feuille de route l'a vérifié, mais la compilation nocturne ne l'affiche pas

comment utilisez-vous la version nocturne?

@mhegazy J'utilise VSCode avec le

    "typescript.tsdk": "./node_modules/typescript/lib",

dans le .vscode/settings.json pointant vers le package npm nightly build (dernière mise à jour)

il n'y a pas de saisie semi-automatique pour les chemins de module pour les importations

image

comme vous pouvez le voir, la saisie semi-automatique ne montre qu'un jeton de texte déjà vu et non le nom d'un fichier sur le disque

Il fonctionne avec des chemins relatifs, mais pas avec des "chemins absolus" (combinaison de baseUrl et de chemins).
Une solution ou contourner ce problème?
Merci

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

CyrusNajmabadi picture CyrusNajmabadi  ·  3Commentaires

remojansen picture remojansen  ·  3Commentaires

Antony-Jones picture Antony-Jones  ·  3Commentaires

MartynasZilinskas picture MartynasZilinskas  ·  3Commentaires

blendsdk picture blendsdk  ·  3Commentaires