Typescript: Пожалуйста, предоставьте автозаполнение для<reference>и пути импорта</reference>

Созданный на 22 июл. 2014  ·  36Комментарии  ·  Источник: microsoft/TypeScript

Здравствуй,

Visual Studio (2013 Ultimate) предоставляет intellisense для атрибута src для элементов скрипта, считывая файловую систему и отображая доступные файлы или папки.

Image

Было бы очень полезно, если бы аналогичная функциональность могла быть предоставлена ​​для <reference> и операторов импорта:


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

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

API Moderate Suggestion Visual Studio help wanted

Самый полезный комментарий

Это, безусловно, моя самая большая трата времени при работе с машинописным текстом. Если он может автоматически заполнять имя моего класса, он должен иметь возможность убедиться, что для него есть оператор импорта. В конечном итоге я делаю обоснованное предположение о пути, а затем добавляю к нему "../" и жду, чтобы увидеть, исчезнет ли красный глоток, и повторяю, пока он не исчезнет.

Также было бы неплохо иметь возможность «оптимизировать импорт» и автоматически удалять неиспользуемый импорт.

Все 36 Комментарий

: +1:

@NoelAbrahams, кстати,

image

@basarat , интересно. Никогда не использовал resharper и не думаю, что это изменится. Так что для таких людей, как я, я надеюсь, что это войдет в плагин VS. :улыбка:

: +1:

@NoelAbrahams btw atom-typescript завершит ваши ссылки: https://github.com/TypeStrong/atom-typescript#relative -paths

и даже автозаполнение внешнего модуля "name" и "./path"s": rose:

Я не знаю, получил ли @ahmad-farid шанс начать это дело, но @basarat , как вы думаете, эта функциональность потенциально может внести свой вклад в сам TypeScript, или же она более тесно связана с atom-typescript?

он более тесно связан с атомным машинописным текстом

Тесно связано с тем, что я использую плохую токенизацию, чтобы обнаружить это:
https://github.com/TypeStrong/atom-typescript/blob/d5fb4707b989f15d3be8d57cfa28d88af50b4702/lib/main/atom/typescriptGrammar.ts#L68 -L76

Код для получения этих результатов немного проще

Не обязательно должно быть тесно связано. Но именно так я написал это как потребитель TypeScript, и PR не может быть копипаста.

Если бы кто-то сделал это, он бы сделал _am I в ссылке на комментарий / строку импорта? _ Обнаружение на getCompletionInfo а затем выполнил бы поиск там.

Также больше возможных обручей: https://github.com/Microsoft/TypeScript/pull/2173#issuecomment -89347414

Вы не можете перетащитьэто кажется намного проще.

для автозаполнения импорта я бы посоветовал иметь еще одну функцию, такую ​​как «Копировать ссылку на импорт» в обозревателе решений, щелкните правой кнопкой мыши файл и затем вставьте его в файл, который будет писать как 'import fileName = require ("../ dir / filename");'. Это должно отслеживать относительные пути и регистр имени файла.

если кто-то может подсказать мне, где мне искать это в этом источнике, я могу попробовать добавить.

Код, связанный с Visual Studio, который вам нужно будет изменить, чтобы внести подобные изменения, в настоящее время не является открытым исходным кодом.

В какой-то момент у нас действительно была генерация ссылок /// методом перетаскивания, но она крайне не обнаруживается и не очень хорошо масштабируется (вы действительно хотите перетащить 5+ элементов из разрозненных частей вашего решения в папки, которые могут быть закрыты обозреватель решений?).

В любом случае, такого рода взаимодействия были бы хороши, но это также должно быть проще сделать в рабочем процессе, ориентированном на клавиатуру, в котором поможет автозаполнение.

у нас так много модулей, что обход файловой системы нецелесообразен, и некоторые из них генерируются именами внешних модулей, а не файлов. Поэтому мы хотели бы запускать периодическое индексирование, а затем каким-то образом предоставлять их список языковым службам (например, RPC или файл, который мы размещаем на локальном диске и т. Д.)

+1 с автозаполнением при импорте будет здорово.

По-прежнему наблюдается много запросов на это, особенно с учетом того, что теперь с VSCode и Salsa это, по сути, регрессия (т.е. они раньше давали завершение по require для модулей). Я считаю, что некоторые редакторы, не принадлежащие Microsoft, также уже поддерживают это в TypeScript / JavaScript. Нам следует подумать о том, чтобы вытащить это (ping @mhegazy ).

Честно говоря, это единственная причина, по которой я должен продолжать использовать Webstorm, в котором созданы собственные обработчики для автоматического завершения импорта и ссылок. И не только автозаполнение, но и автоматические исправления.

У нас есть около 25 тыс. Строк банкомата Typescript, и было бы очень хорошо, если бы эту функцию можно было внедрить, чтобы все другие IDE могли ее принять.

Нам тоже нужна эта функция. Это один из самых больших недостатков мира Java, в котором рефакторинг можно легко выполнить с помощью eclipse или intellij.

Я хотел бы здесь вмешаться, хотя автоматическое завершение импорта очень полезно и приятно работать, я хотел бы отметить, что эта функция является одной из причин того, что веб-шторм не является оптимальным. Сканирование node_modules на постоянной основе создает значительные накладные расходы на память и обработку, которые, я думаю, немного замедлили бы VSCode.

Короче говоря, мне бы понравилась эта функция, но не за счет потрясающей скорости VSCode. Как легкий редактор, я рассчитываю на скорость, мощность и гибкость за счет удобства. Медленная среда IDE имеет более высокую совокупную стоимость владения из-за того, что она постоянно перегружается, создавая задержки, тогда как более легкий редактор позволяет вам прожигать в непрерывном непрерывном темпе.

@mikepc curiou, использовали ли вы другие реализации, такие как https://packagecontrol.io/packages/AutoFileName, и как вы находите его производительность для проектов, над которыми работает WebStorm.

Я думаю, что у вас может быть сложный алгоритм завершения импорта, который не страдает от описанных вами проблем с производительностью. Одним из вариантов оптимизации было бы использование поля exclude в tsconfig для исключения файлов и папок из индекса автозаполнения. Теперь будут автоматически заполняться только пути к файлам проекта. Если кто-то импортирует модуль из зависимости, машинописный текст знает, где находится эта зависимость. Таким образом, папка импортированной зависимости также включается в индекс. Удалением можно управлять через счетчики ссылок для каждого модуля зависимости.

Я ничего не знаю о внутренней работе различных методов
обход пакета, и если это действительно возможно, включить его только с помощью
незначительный удар производительности, я бы очень хотел, чтобы он был добавлен мне нравится
используя VSCode. Я просто хочу продолжать получать удовольствие от его использования.

В пн, 18 апреля 2016 г., в 12:37, Фредерик Шуберт <
[email protected]> написал:

Думаю, у вас может быть сложный алгоритм завершения импорта
который не страдает от описанных вами проблем с производительностью. Один
оптимизация заключалась бы в использовании поля exclude в tsconfig для исключения
файлы и папки из индекса автозаполнения. Теперь только файл проекта
пути будут заполнены автоматически. Если кто-то импортирует модуль из зависимости, тогда
typescript знает, где находится эта зависимость. Итак, папка
импортированная зависимость также включается в индекс. Удаление могло быть
управляется через счетчики ссылок для каждого модуля зависимости.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/188#issuecomment -211543527

После прочтения этой темы я все еще не уверен, что это будет реализовано в VS Code? Просто раздражает каждый раз делать все это вручную.

Это, безусловно, моя самая большая трата времени при работе с машинописным текстом. Если он может автоматически заполнять имя моего класса, он должен иметь возможность убедиться, что для него есть оператор импорта. В конечном итоге я делаю обоснованное предположение о пути, а затем добавляю к нему "../" и жду, чтобы увидеть, исчезнет ли красный глоток, и повторяю, пока он не исчезнет.

Также было бы неплохо иметь возможность «оптимизировать импорт» и автоматически удалять неиспользуемый импорт.

Да пожалуйста, это такая заноза в жопе.

есть новости по этому поводу?

есть новости по этому поводу?

работаю над этим. но нечего сообщить.

Было ли согласовано, как это должно работать для импорта?

Я полагаю, это было бы приятным пользовательским интерфейсом: если в VS Code я нажму Ctrl + T (введите для поиска символов по всему проекту) и выберу символ, это позволит мне каким-то образом сгенерировать для него оператор импорта.

Крошечный бит связан, почему-то список символов проекта не показывает мне экспортированные переменные, например, export let globalStyles = {} но он появляется в списке символов файла. В списке символов проекта должны отображаться все символы, чтобы он работал как графический интерфейс для импорта.

@Ciantic Звучит неплохо. Я бы предпочел, чтобы при использовании Intellisense он автоматически импортирует вещи, которые он автозаполняет, которые не входят в область действия. Я также хотел бы иметь возможность очистить неиспользуемый импорт или другие функции для их сортировки. Еще одна вещь, которая была бы хороша, - это что-то вроде того, что если вы удалите последнее использование чего-то импортированного, оператор импорта будет удален.

Я создал это, чтобы устранить проблему для себя https://marketplace.visualstudio.com/items?itemName=Sammons.ts-import-assistance , код здесь: https://github.com/Sammons/ts-import-assistance . Он не супер-умный, но делает то, что мне нужно. По сути, я не нашел простого способа узнать, какие символы отсутствовали в текущем документе, поэтому это команда, которую вы можете выполнить для поиска и импорта выделенного вами символа.

Это просто надстройка над встроенным поиском символов.

Я также наткнулся и использовал этот плагин VS Code, чтобы помочь тем временем:
https://marketplace.visualstudio.com/items?itemName=steoates.autoimport

Это очень помогло, когда я переключал проект с пространств имен (внутренних модулей) на внешние модули.

@Taytay Спасибо, попробовал, но из-за этого мой VS Code зависает ... Возможно, мое приложение слишком велико, но для меня оно бесполезно.

О черт @rolandoldengarm. Понятно. (Как бы то ни было, я обнаружил, что автор всегда реагирует на вопросы, если вы захотите продолжить.)

@Taytay Спасибо за информацию, но я сделал собственное расширение ;-) в настоящее время я переписываю логику, чтобы сделать это быстрее. Я не использую регулярное выражение для анализа файлов (как это делают многие другие), но использую компилятор машинописного текста для генерации AST исходного кода.
Если вам интересно, вы найдете его здесь: https://marketplace.visualstudio.com/items?itemName=rbbit.typescript-hero

@buehler Это прекрасно работает! Пока проблем не было. Определенно намного быстрее, чем печатать все это.

пожалуйста, каков его статус? дорожная карта проверила это, но ночная сборка не показывает этого

как вы используете ночную сборку?

@mhegazy я использую VSCode с

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

в .vscode/settings.json указывающем на пакет npm для ночной сборки (последний только что обновленный)

нет автозаполнения для путей модулей для импорта

image

как вы можете видеть, автозаполнение показывает только уже увиденный текстовый токен, а не имя файла на диске

Он работает с относительными путями, но не с «абсолютными путями» (комбинация baseUrl и путей).
Любое решение или способ решения этой проблемы?
Спасибо

Была ли эта страница полезной?
0 / 5 - 0 рейтинги