Typescript: Включить переход к реализации в редакторах машинописного текста

Итак, вы хотите, чтобы эта функция перешла к соответствующему .js если он доступен, при условии, что определение является окружающим, верно?

@RyanCavanaugh @mousetraps @ bowdenk7

Итак, вы хотите, чтобы эта функция перешла к соответствующему .js, если он доступен, при условии, что определение является окружающим, верно?
Да, это сценарий, который был бы очень полезен для повышения производительности. Одно это было бы очень ценно. Я считаю, что автор атомного машинописного текста считает, что большее количество хуков в компиляторе Typescript упростит ему реализацию этого. Я не понимаю, является ли это информация о номерах строк реализации js информацией, которую компилятор машинописного текста обычно знает внутри себя.

Кроме того, в другом сценарии можно было бы перейти к определению исходного файла машинописного текста .ts в библиотеке, используемой приложением. Я предполагаю, что эта информация доступна для предварительной компиляции в файлы d.ts и .js. Теперь у нас есть целые наборы библиотек, записываемых в файлы .ts в качестве исходного кода, выводящего синтаксис ES5 js. Было бы неплохо получить возможность перейти к исходному определению реализации машинописного текста в файлах .ts.

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

Доступна ли эта информация о номере строки реализации функции / класса в исходных картах? Есть ли другие источники этой информации?

Учитывая, что мы собираемся использовать флаг --allowJS , языковая служба должна иметь возможность работать с файлами JS.

Я не знаю, как .d.ts files и .js files в настоящее время работают вместе в этом отношении. @sheetalkamat, вероятно (определенно) знает об этом больше, чем я.

Повторное открытие, потому что переход к файлам js еще не поддерживается

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

Эта проблема была перемещена / закрыта / дублирована / удалена несколько раз, и исправление этой ошибки может значительно повысить производительность.

https://github.com/ubershmekel/vscode-ts-goto-source есть проект, в котором воспроизводится проблема. Как описано в https://github.com/Microsoft/vscode/issues/26325 и указано в https://github.com/Microsoft/vscode/issues/10806 и https://github.com/Microsoft/vscode/issues / 18321

Примечание. Мне пришлось использовать "typescript.disableAutomaticTypeAcquisition": true с одной точки, чтобы использовать javascript «перейти к определению», потому что кажется, что файлы .d.ts вступают во владение, если они найдены.

@DanielRosenwasser Есть новости по этому

Это особенно раздражает, если вы работаете в монорепозитории, полностью написанном на Typescript. Я несколько раз при добавлении поля к типу или аналогичных небольших изменениях использовал «перейти к определению», добавил его, а затем обнаружил, что он снова отсутствует, понимая, что я добавил его в файл .d.ts а не в фактический .ts файл

@DanielRosenwasser Это прогрессирует? Мне бы очень понравилась эта функция

та же проблема. Хотите «Перейти к реализации» к исходному коду, а не к xx.d.ts

Да, несколько раз в день я по ошибке редактирую файл декларации после использования cmd + click и в конечном итоге сбиваюсь с толку, когда код работает некорректно. Тем более, что src и dec очень похожи. Было бы здорово, если бы был какой-то способ выбрать, хочу ли я перейти к источнику объявления, или даже лучше, если бы VSCode понял это, поскольку переход к источнику всегда предпочтительнее ИМХО (если он доступен).

переход к источнику всегда предпочтительнее ИМХО (если он доступен)

Когда исходник находится в TS. Если источник находится на JS, хотя есть веская причина перейти на .d.ts

Когда исходник находится в TS. Если источник находится на JS, хотя есть веская причина перейти на .d.ts

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

Есть ли причина, по которой это все еще не принято? Обходной путь, альтернатива или что-то в этом роде? заранее спасибо

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

У меня есть ветка # 21930, которая позволяет создавать именно эти исходные карты файлов объявлений (и они будут доступны для просмотра либо по запросу, либо после слияния # 21930), и я работаю над добавлением поддержки в наш LS для отслеживания этих карт. Мы хотим отправить его в версии 2.8.

Так что да, мы над этим работали. Просто нужно было произвести множество внутренних изменений. 😄

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

Есть ли обходной путь для этого?
Поскольку у нас есть большой модуль для наших запросов к базе данных, написанный на ts, было бы действительно неплохо увидеть реальный исходный код с помощью одной команды вместо поиска по node_modules.

@ derN3rd Существует vscode-search-node-modules для просмотра node_modules на панели команд (и у меня также есть вилка, которая всегда открывает README vscode-open-node-modules )

Я понимаю, что это далеко не идеальный ux, чтобы щелкнуть требовать / импортировать и открыть файл с исходным кодом, но определенно лучше, чем прокрутка node_modules

@ derN3rd мы будем поставлять флаг --declaratrionMap в 2.9 (который может быть выпущен в течение следующего месяца), и мы уже включили переход к определениям в исходном исходном TS через связанный .d.ts используя их (которые, если вы отправляете файлы декларации в папку модулей узлов, могут получить многое из того, что вы хотите). Мы также изучаем возможность перехода к связанному JS и обратно, при условии, что включены обычные исходные карты.

@weswigham спасибо за быстрый ответ! Звучит отлично
Не могли бы вы опубликовать здесь обновление, если функция готова или готова к тестированию?

--declarationMap (и связанное с ним перенаправление LS) было в наших ночных сборниках сразу после выпуска 2.8. Единственное, что мы еще не сделали, - это скачкообразное переключение файлов JS, так как это может потребовать дополнительной координации редактора.

Есть какие-нибудь новости о 3.0-RC?

Та же проблема с файлами .css и .json . Перейти к определению, чтобы перейти к файлу .d.ts .

import React from 'react'
import Route from 'react-router-dom/Route'
import Switch from 'react-router-dom/Switch'
import Loadable from 'react-loadable'
import  './App.css'
import './tailwind.css'

Перейти к определению на ./App.css приведет меня к

declare module '*.css' {
    const content: any;
    export default content;
}

declare module '*.svg' {
    const content: any;
    export default content;
}

declare module '*.json' {
    const content: any;
    export default content;
}

VS Code теперь поставляется с TypeScript 3.0.3. Есть новости по этому поводу?

У меня работает (карты объявлений, созданные с помощью TS 2.9.2, под управлением VSCode 1.27.0). Переход от потребителя API (реализованный в JS) _Go to Definition_ приводит меня к реализации в файле .ts.

@robsman _Go to Definition_ приведет вас к скомпилированному js-коду, а _Go to Type Definition_ приведет вас к файлу .d.ts.

Как вы используете / включаете свой скомпилированный модуль, чтобы открывать исходные файлы?

Эта проблема все еще существует для меня в VSCode 1.27.0, поскольку обе функции переводят меня в файл .d.ts

РЕДАКТИРОВАТЬ: Я думаю, что неправильно понял ваш комментарий. Это приведет вас к настоящему коду? Если да, то используете ли вы монорепозиторий или ваш скомпилированный код поставляется в собственном модуле npm? Вы отправляете исходные файлы вместе со своим скомпилированным кодом?

@ derN3rd прошел повторное тестирование, оба _Go to Definition_ и _Go to Type Definition_, а также _Peek Definition_ привели меня к реальному коду в _.ts_ файле.

Объявление и реализация API находятся в отдельном модуле, который вызывающий пакет называет зависимостью _git + ssh ..._.

@robsman Я думаю, что Go to Definition должен отсылать меня к источнику "этого" класса или функции в исходном js файле (если это javascript) внутри node_modules not .d.ts . Я имею в виду, как это работает в Sublime Text 3. Во всяком случае, я не понимаю, для какого VSCode эта функция в текущем состоянии

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

Пожалуйста, добавьте меня в длинный список людей, которые пытаются использовать командный щелчок для навигации по коду. У меня нет TS в моем проекте, а пакет npm, к которому я перехожу, не использует TS, но при нажатии команды на require ('co-body') я перехожу к внутреннему сгенерированному определению TS. Я долгое время пользуюсь IntelliJ и по-прежнему из-за этого возвращаюсь к IntelliJ.

это длинная просьба

Мне очень нравится VS Code, я только начал новый проект Node и решил впервые использовать TypeScript. Пока все в основном хорошо, но эта проблема была болевой точкой. При работе с открытым исходным кодом возможность перехода к реальному исходному коду в зависимостях жизненно важна для рабочего процесса. Я работаю с исходными файлами TypeScript и использую модули JS NPM со связанными модулями @types/xxx , которые не имеют связанной документации. IntelliSense с TypeScript прекрасен, но не всегда предоставляет достаточно информации. По крайней мере, было бы неплохо иметь возможность напрямую перейти к источнику модуля из оператора import . Я считаю, что в некоторых библиотеках, которые работают, а в других, например, в Passport, я не могу обойтись без дополнительных заглушек TypeScript в модуле @types .

Это должно быть помечено _Bug_, а не _Suggestion_.

Отсутствие навигации по коду действительно разрушает возможности VSCode для разработчиков JavaScript.

извините за спам, но @promaty я использую расширение search-node-modules 😬 пока

У WebStorm такое же поведение: StackOverflow , BugTracker.

• VSCode имеет действия «Перейти к определению» и «Перейти к определению типа».

• В WebStorm есть действия «Перейти к объявлению» и «Перейти к объявлению типа».

Но при использовании TypeScript обе IDE делают одно и то же: всегда переходите к определению типа!

«Перейти к определению» и «Перейти к определению типа», когда они используются в библиотеках node_modules/ , оба переводят меня к файлам .d.ts . Я использую последний код VS на момент написания (1.34.0).

Например: npm package @angular/[email protected] , когда я импортирую TestBed из @angular/core/testing и пытаюсь увидеть определение TestBed.createComponent , я получаю две разные вещи:

• «Перейти к определению» -> node_modules/@angular/core/testing/src/test_bed_common.d.ts строка 117
• «Перейти к определению типа» -> node_modules/@angular/core/testing/src/component_fixture.d.ts строка 14

В основном это означает, что исходный код Angular скрыт от меня в VS Code 😞 Я не уверен, что это симптом того, как написана библиотека Angular, или того, как TypeScript / VS Code находит исходные реализации.

Все, что я знаю, это то, что я могу надежно использовать «Перейти к определению» и «Перейти к определению типа» в своем собственном коде, и в этом случае я попадаю непосредственно в источник; Мне никогда не показывали файл .d.ts для моего собственного кода.

Сейчас нам нужно вручную искать исходные коды: /

Ой, я просто понял, что как-то в Intellij IDEA эта функция работает очень хорошо, даже если я работаю в том же проекте, используя Typescript 3.0.1

Я считал, что приоритетность этого вопроса надо повысить.

Нам нужно выполнить команду + , чтобы открыть настройки рабочего пространства -> снять отметку с Use Ignore Files -> удалить Search: Exclude: **/node_modules и вручную выполнить поиск в исходных кодах.

ЕЖЕДНЕВНО!

Вот почему flow по-прежнему полезен.

Может ли кто-нибудь из команды машинописцев подсказать, где в коде это потенциально можно исправить?

Забавно то, что если в каком-то пакете нет доступных типов, «Перейти к определению типа» для него действительно лучше. Это означает, что лучше не печатать, если вам нравятся функции «Перейти» 😄

Вот скринкаст, который показывает, что я могу перейти к определению пакетов device которые не имеют типизации, но compression приводит меня к некоторому файлу случайных типизаций:

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh Я должен согласиться с другими людьми, это должно быть обозначено как ошибка, а не предложение ..

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

const Foo: <T> = () => {
...
}

если T поступает из модуля npm, когда я пытаюсь перейти к определению, он покажет мне 2 определения. Мой собственный код и определение набора текста. Если я перейду к определению типа, он перейдет прямо к файлу определения.
В первом случае следует сразу перейти к определению.
Чтобы обойти это, я изменил редактор -> goto location: multiple на goto вместо peek

Мне нужна эта функция. Как я могу помочь с его реализацией?

+1 за это пожалуйста!

с 2015 и решений нет :(

OP спрашивал, можем ли мы перейти к .ts files, когда мы находим .d.ts files - если вы отправляете файлы .ts файлами .d.ts и декларацией карты, сгенерированные --declarationMaps , это наше текущее поведение (так что это уже сделано). _Second_ запрос в этом потоке, который мы сейчас отслеживаем, - это возможность перейти к выходному файлу .js (который может быть полезен, если, например, .ts sources не ' т отправлено). С точки зрения реализации, это просто вопрос объединения исходных карт декларации и исходных карт javascript, которые мы уже выпускаем, однако мы еще не решили, как такая функция должна проявляться. Go to implementation в ts-коде уже имеет полезное значение для большей части кода (который относится к определению, но предпочитает объявления реализации / значений) ... исправляем ли мы это каким-либо образом (скажем, если мы разрешаем объявление file, попробуйте вместо этого разрешить js-файл), или мы добавим новую конечную точку? Если позже, нам нужно поговорить с командой vscode о том, как мы хотим это раскрыть.

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

Кодеры из команды vscode могут предложить идеи о том, как это должно быть реализовано, например, Go to js implementation или что-то в этом роде, первым хорошим шагом будет создание заявки на трекере проблем vscode и перекрестная ссылка на эти заявки, чтобы общение могло начинать.

Насколько я понимаю, здесь есть несколько связанных проблем. (1) является большим, но мы должны помнить и о других:
1) Нет простого способа перейти к реализации типа TS на JS или TS, если этот тип объявлен в пакете DefininiteTyped. (или в других случаях, когда .d.ts не совмещен с реализацией)
2) Перейти к определению типа не работает, если выделение само по себе является типом. Вы получите ошибку «определение типа не найдено».
3) Перейти к определению для идентификатора, не являющегося типом, ведет себя непоследовательно. Иногда он переходит к реализации, иногда нет. Теоретически это то же самое, что и (1), но также можно решить (1), оставив это несоответствие на месте.

Я думаю, пользователям было бы проще решить все три проблемы без добавления третьего пункта меню «Перейти». Вместо этого я предлагаю сохранить только два пункта меню, но сделать их более последовательными:

• Перейти к определению всегда следует переходить к реализации , независимо от того, является ли это локальным кодом, пакетом node_modules со встроенными файлами .d.ts или определением DefinitoTyped, отдельным от пакета JS.
• Переход к определению типа всегда должен переходить к объявлению TS , независимо от того, является ли выбранный тип идентификатором или нет.

Существуют ли другие распространенные сценарии использования TS, требующие третьего выбора?

Кстати, я думаю, мы могли бы переименовать «Go To Definition» в «Go To Implementation», если бы мы хотели сделать различие более ясным, но IMHO это кажется необязательным изменением. Согласованность (независимо от имени) - это старший бит.

Нет простого способа перейти к реализации JS или TS типа TS, если этот тип объявлен в пакете DefininiteTyped. (или в других случаях, когда .d.ts не совмещен с реализацией)

_Технически_, если вы хотите вручную раскрутить некоторые исходные карты для работы с пакетом DT, это уже могло бы сработать. Но здесь точно нет автоматизированного решения. Любое имеющееся у нас решение основано на улучшении сценариев, связанных с выходными данными компилятора TS, и это единственный раз, когда мы можем отказаться от дополнительных метаданных, необходимых для создания правильных ассоциаций между файлами. Я полагаю, что некоторые пакеты поддерживают это сегодня - на днях я использовал azure js sdk и отлаживал некоторые вещи, и был приятно удивлен, когда перешел к некоторым определениям и обнаружил, что они были в исходном источнике. Так что да, он работает с источниками TS, к которым прилагается последняя версия вывода --declarationMaps .

Перейти к определению типа не работает, если выделение само является типом. Вы получите ошибку «определение типа не найдено».

Я думаю, вам всем следует открыть новый выпуск по этому поводу. Это просто сбой экзепекций / баг, имо. Как минимум, ошибку можно было бы улучшить - что-то вроде «выбор - это только тип, поэтому определение типа не связано с его значением».

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

Он переходит к определению _first_, где первое довольно произвольно и основано на таких вещах, как файлы заказа, в которые были загружены. Окно peek по общему признанию более полезно, поскольку оно показывает все сайты определений. «Реализации» здесь не участвуют.

Я, как пользователь, буду доволен, если это сработает так:

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

Я считаю, что существуют следующие сценарии поиска исходного исходного кода:

1. Пакет написан на машинописном тексте и в исходном коде во внешнем репозитории, либо
   а) распределение включает файлы d.ts и js ИЛИ
   б) распределение включает файлы d.ts , js и ts
2. Пакет написан на машинописном тексте и в исходном коде в текущем репозитории (случай монорепозитория) и
   а) раздача включает файлы d.ts и js
3. Пакет написан на javascript и оригинальном исходном коде во внешнем репозитории и либо
   а) дистрибутив включает собственные файлы d.ts и js ИЛИ
   а) в дистрибутив входят только файлы js и используются внешние определения @types
4. Пакет написан на javascript и исходном коде в текущем репозитории (случай монорепозитория) и
   а) дистрибутив включает собственные файлы d.ts и js

1b) - редко используется, и мне не нравится этот подход, поскольку такие ресурсы, как bundlephobia и npm Trends, сообщают об огромных размерах пакетов, которые на самом деле не так уж велики во время выполнения, но люди судят о размере на основе этих ресурсов. Итак, полагаться на то, что сопровождающие включат файлы ts в дистрибутив, - не лучшая идея, но, конечно, если включены файлы ts , дело решено.

1а) - (самый?) Частый случай. Пакет должен каким-то образом объявлять (через package.json или исходные карты?), Где исходные источники были расположены при компиляции (например, файлы символов microsoft pdb объявляют) ИЛИ откуда их можно загрузить, например git + revision + дорожка. Код VS перейдет к локальному файлу или git fetch к локальному кешу и откроет его при переходе от объявления к реализации.

2a) - если возможно автоматически обнаружить случай монорепо (с использованием некоторой эвристики), исходная навигация Ctrl + Click может напрямую открыть реализацию. Если это невозможно, достаточно вернуться к 1a).

Меня меньше волнует 3, но было бы неплохо, если бы 3a) мог открывать реализацию JS при второй навигации Ctrl + Click. В случае 3b) пакет @types должен объявлять, какие пакеты JS он аннотирует, чтобы код VS мог иметь эту информацию для перехода к реализации JS во внешнем пакете.

Меня еще меньше волнует 4, но он может иметь такое же поведение, как 2a) - резерв для 4a) - 3a)

Надеюсь, это поможет.

1а) - (самый?) Частый случай.

Да, это то, о чем я говорю, сейчас у нас есть все инструменты для поддержки. Мы можем объединить файлы .js.map и .d.ts.map чтобы создать отображение .d.ts на .js (без промежуточного .ts ). Но, хм. Действительно, вы бы предпочли перейти к файлу декларации, а затем снова взаимодействовать, чтобы перейти к связанному js? Не хотите сразу переходить к js?

«На самом деле, вы бы предпочли перейти к файлу декларации, а затем снова взаимодействовать, чтобы перейти к связанному js? Вы не хотите сразу переходить к js?»

В случае 1а) мне подходят двойной или одиночный прыжок. Хотя одиночный прыжок можно рассматривать как «более эффективный», двойной прыжок имеет преимущество «напоминания» пользователю о том, что второй прыжок - это прыжок в черный ящик с точки зрения «потребления библиотеки» (т. Е. Напоминание о том, что исходный код файл, к которому осуществляется переход, не является частью текущего проекта). Возможно, это поведение можно настроить.

В случае 3a), 3b) или 4, я обязательно хочу двойной прыжок. Сначала я хочу увидеть объявления и только после этого (в очень редких случаях, например, при отладке) реализацию. Переход прямо к JS, пропуская объявление TS, устраняет все преимущества объявлений. Итак, я определенно хочу сначала увидеть декларацию TS.

(объединение ответов на @weswigham и @avkonst из нескольких сообщений)

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

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

создать отображение из .d.ts в .js (без промежуточных .ts).

Не уверен, что понимаю "без промежуточного ТС". Вы имеете в виду, что даже если исходный код .ts доступен, VSCode перейдет к транспилированному .js? Это кажется плохой идеей. Если исходный источник доступен, то VSCode должен перемещаться туда - точно так же, как это было бы, когда отладчик переходит в транспилированный код с исходной картой. Тем не менее, если автор пакета был злым или ленивым и не включил исходный источник TS в свой дистрибутив npm, то для VSCode кажется разумным вернуться к транспилированному JS и, возможно, показать предупреждающее сообщение, объясняющее, почему пользователь видит такой странный, нечитаемый код и побудить пользователей отговорить автора пакета включить исходный исходный код в свой пакет.

Действительно, вы бы предпочли перейти к файлу декларации, а затем снова взаимодействовать, чтобы перейти к связанному js? Не хотите сразу переходить к js?

Я не думаю, что двухэтапный подход повысит ценность. Я думаю, что гораздо лучше иметь четкий, согласованный UX: используйте «Go To Type Definition», чтобы перейти к определению типа, и используйте Go To Definition (или Go To Implementation - как бы мы это ни называли), чтобы перейти к исходному исходный код или, как указано выше, в транспилированный JS, если исходный код недоступен.

IMHO, гораздо сложнее иметь разное поведение в зависимости от того, определен ли выбранный символ в вашем собственном коде или в node_modules. Это не имеет значения. Если я хочу увидеть тип, VSCode должен привести меня к типу. Если я хочу увидеть код реализации, VSCode должен отвезти меня туда. Это особенно верно, потому что в крупных организациях то, что «мой код», а что «код библиотеки», не всегда является яркой гранью. Если кто-то другой преобразовал код в общий внутренний пакет, мне не пришлось бы менять способ перехода к этому коду.

Сначала я хочу увидеть объявления и только после этого (в очень редких случаях, например, при отладке) реализацию.

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

> «Перейти к определению типа» не работает, если выделение само по себе является типом.
Я думаю, вам всем следует открыть новый выпуск по этому поводу. Это просто сбой экзепекций / баг, имо.

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

«Это идет к первому определению, где первое довольно произвольно и основано на таких вещах, как порядок загрузки файлов».

В своих ответах я не упомянул, что следует перейти к первому определению. Я сказал, что при нажатии Ctrl + Click на символе он должен в первую очередь перейти к определению (так как он работает сейчас) и только при последующем нажатии Ctrl + Click на реализацию.

«Кажется, более понятным является требование, чтобы разработчик явно выбирал (выбирая тот или иной пункт меню), хотят ли они видеть объявление типа или просмотреть код реализации».

Отдельные контекстные меню - это хорошо и неплохо. Они не являются взаимоисключающими для поведения Ctrl + Click.

Интересно, почему над этой критической ошибкой еще не работают. По мере того, как растет распространение машинописного текста, это становится все более и более головной болью.

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

@zjaml , вы хотите, чтобы он переходил к исходным файлам TypeScript или исходным файлам JavaScript? Поддерживаются исходные файлы TypeScript. Это исходные файлы JavaScript, для которых эта проблема в настоящее время все еще открыта.

Тангенциально связанные; У меня есть монорепозиторий с общим пакетом, который публикуется в npm. Из-за этого общедоступного интерфейса dist - это файлы js + d.ts. Когда я работаю в репозитории, VSCode всегда переходит к d.ts вместо источника. Вы знаете способ обойти это?

@ 0x80 Я считаю, что эта проблема все еще открыта для сценария, который вы только что описали. Я думаю, что единственный способ обойти это, если проект с открытым исходным кодом, и вы скомпилировали его из исходного текста машинописного текста. Затем вы можете включить флаг --declarationMaps для компилятора машинописного текста, и IDE, поддерживающие карты объявлений, будут обращаться к исходному тексту машинописного текста вместо файлов d.ts.

Это действительно важно. Мне нужна простая вещь: CTLR + Щелкните и перейдите к файлу node_modules / library / source.js или source.ts. Проект с открытым исходным кодом с 60 зависимостями node_modules, и вы снова можете использовать блокнот с проводником.

Когда я щелкнул правой кнопкой мыши по компоненту, я увидел: «Перейти к определению» и «Перейти к определению типа». Я подумал: «Отлично, это хорошо продумано, решение моей проблемы здесь!». Затем я щелкнул «Перейти к определению» и ... перешел к определению типа.

Это действительно важно. Мне нужна простая вещь: CTLR + Щелкните и перейдите к файлу node_modules / library / source.js или source.ts. Проект с открытым исходным кодом с 60 зависимостями node_modules, и вы снова можете использовать блокнот с проводником.

+1
Такая же потребность.

При всем уважении, тот факт, что это не реализовано, невероятен. Такой простой, относительно простой
построить функцию, которая сэкономит людям массу времени.

При всем уважении, тот факт, что это не реализовано, невероятен. Такой простой, относительно простой
построить функцию, которая сэкономит людям массу времени.

+1

Что ж, пока эта функция еще недоступна, есть ли лучший обходной путь, кроме поиска всех node_modules? Это действительно неудобство ...
Например, я перехожу к определению, и оно привело меня к node_modules/@com.abc/sample/lib/core/internal/abc.d.ts когда тот, который я хочу, фактически находится в node_modules/@com.abc/sample/src/core/internal/abc.ts

@ Happin3ss

есть ли лучший обходной путь, кроме поиска всех node_modules?

Текущее решение AFAIK - это карты объявлений . Это карты источников, которые сопоставляют файлы .d.ts с соответствующим источником TS. Если вы можете убедить библиотеки в том, что вы зависите от реализации карт объявлений (что, как мне кажется, эффективно требует публикации .d.ts внутри пакета библиотеки, а не полагаться на @types), то вы сможете автоматически переходить со своего клиентского кода. в исходный код TS (или даже JS, если используется компилятор TS на JS?).

То, что я делаю, - это постепенно заполняю PR для моих самых важных зависимостей (по крайней мере, тех, которые созданы в TS), чтобы заставить их добавлять карты объявлений.

Очевидно, было бы лучше, если бы изменение библиотеки не требовалось.

Другой обходной путь (если изменение библиотеки невозможно) работает в случае, когда библиотека связывает .d.ts внутри пакета, но не имеет карт объявлений. В этом случае я воспользуюсь «Перейти к определению», чтобы перейти к объявлению типа, а затем нажму кнопку «Проводник» в VSCode, чтобы отобразить боковую панель папки. Обычно это очень приближает меня к папке src для пакета, поэтому вместо того, чтобы искать по всем node_modules, я могу просто перейти в нужную папку и открыть правильный файл. Это зависит от четкого именования файлов и т. Д. И не является панацеей.

Просто чтобы быть на 100% ясным - я бы хотел увидеть лучшее решение для библиотек, особенно. те, где .d.ts создается отдельно от пакета.

Не уверен, что я это пропустил, но было бы действительно полезно для понимания того, что происходит, иметь реальные минимальные примеры источников, объявлений и карт объявлений. Я никогда не видел, чтобы «Перейти к определению», «Перейти к определению типа» или «Перейти к реализациям» на самом деле переходили ни к чему, кроме файла .d.ts для транспилированного TS. Я просто попытался привести простой пример , но он не работает; Я не могу заставить VS Code перейти к чему-либо, кроме файла .d.ts , даже если .d.ts.map находится рядом с ним. Я также нашел кого-то с той же проблемой , которого проигнорировали.

Понятно, что поддержка внешней типизации, такой как @types была бы сложной, но что там говорит о том, что даже «счастливый путь» не может работать?

Есть много библиотек, которые генерируют файлы объявлений, но не карты объявлений, и неясно, какой аргумент будет для их включения. Этот вариант был добавлен без четкого объяснения, по крайней мере, один, который я смогу найти.

Да, я подтверждаю, что карты объявлений не решают проблему. В моем проекте есть карты объявлений, но vscode не выходит за пределы файлов .d.ts.

Было бы здорово, если бы это случилось.

Если есть "слон в комнате" проблем для разработчиков ms vscode, то это он.

Есть обновления по этому поводу?
Я просто решил сделать большой шаг: перейти с JS на TS. Я подумал - "что я делаю не так?" но на самом деле это неожиданное поведение VSCode

Есть обновления по этому поводу?
Я просто решил сделать большой шаг: перейти с JS на TS. Я подумал - "что я делаю не так?" но на самом деле это неожиданное поведение VSCode

С тех пор, как подняли такое поведение, прошла долгая история. Ну, здесь ничего не происходит. Пока никаких планов.
Что касается меня, я продолжаю использовать vscode как своего рода редактор, и продукты Intellij (IDEA) для моих материалов по кодированию, даже если мне это не очень нравится.

Открыт на 5 лет, надеюсь, будет исправлен в 2025 году.

Я создал неудачные тесты в # 39426, но я не знаю, как это реализовать

Еще один жалкий комментарий от ts dev, который каждый день проходит через ад в поисках определений.

Это безумие ... Я думал, что я просто TS noob, но теперь я вижу, что поведение, которое я получаю, на самом деле «стандартное» ???? Так расстраивает, что во всех других IDE / языках, которые я использовал, это реализовано в первоначальном выпуске ... :( Мне нравится код VS, но, честно говоря, это может быть нарушением сделки

Может ли кто-нибудь объяснить, почему функции go to definition/implementation в VSCode с расширениями Python для, да, языка Python работают лучше (по крайней мере, он работает), чем для JS, имеющего собственные встроенные решения?

Так, что происходит?
Я использую scss.d.ts для модулей css и не могу перейти к scss.

Также при создании простых .js и, соответственно, d.ts я не могу сразу перейти к js

почему бы не использовать веб-шторм?
это может решить эту проблему !!!
моя версия 2020.1

почему бы не использовать веб-шторм?
это может решить эту проблему !!!
моя версия 2020.1

Потому что это не решение с открытым исходным кодом и не бесплатное

Пожалуйста, исправьте это.

Совершенно ясно, что эта проблема может быть решена только в том случае, если к власти придет какой-то менеджер из Microsoft, эту проблему нужно решать и координировать, менеджер разрабатывает рабочий процесс и поручает работу кодировщикам. ☝
Эту проблему нужно отправить руководству, чтобы оно взяло на себя ответственность, и они решат, как это будет реализовано.
Так что, если здесь есть кто-то компетентный из Microsoft, он может попробовать. 😊