Typescript: Typescript 편집기에서 구현으로 이동 활성화

따라서 정의가 앰비언트인 경우 이 기능이 해당 .js 하기를 원합니다.

@RyanCavanaugh @mousetraps @bowdenk7

따라서 정의가 앰비언트인 경우 이 기능이 해당 .js로 이동하기를 원합니다(사용 가능한 경우). 맞습니까?
예, 이것은 생산성에 매우 유용한 시나리오입니다. 이것만으로도 매우 가치가 있을 것입니다. 나는 atom-typescript 작성자가 Typescript 컴파일러의 더 많은 후크가 이를 구현하기 쉽게 만들 것이라고 믿습니다. 이것이 js 구현 줄 번호에 대한 정보인지 여부는 typescript 컴파일러가 일반적으로 내부적으로 알고 있는 정보인지 확실하지 않습니다.

또한 다른 시나리오에서는 응용 프로그램에서 사용 중인 라이브러리의 원래 typescript .ts 파일 정의로 점프할 수 있습니다. 이 정보를 d.ts 및 .js 파일로 미리 컴파일할 수 있다고 생각합니다. 이제 ES5 구문 js를 출력하는 소스로 .ts 파일에 작성된 전체 라이브러리 세트가 있습니다. .ts 파일에서 원래 typescript 구현 정의로 점프하는 기능을 달성하는 것이 좋을 것입니다.

소스 맵 사용 또는 원본 ts 소스에 대한 소스/링크 배포가 필요할 수 있으므로 필요한 라이브러리의 .ts 파일 구현으로 점프하기 위해 더 많은 것을 요구한다는 것을 알고 있습니다. 함수와 클래스의 초기 라이브러리를 생성하는 typescript 컴파일러는 구현이 있는 행을 알고 라이브러리가 어떻게든 배포될 때 행 번호를 보존할 수 있으므로 클래스를 사용하는 응용 프로그램의 typscript 컴파일러가 도서관에서 어떤 줄로 건너뛸지 알 수 있습니다.

소스 맵에서 사용할 수 있는 구현 함수/클래스의 행 번호에 대한 정보가 있습니까? 이 정보의 다른 출처가 있습니까?

--allowJS 플래그를 사용할 예정이므로 언어 ​​서비스는 JS 파일과 함께 작동할 수 있어야 합니다.

그런 점에서 .d.ts 파일과 .js 파일이 현재 어떻게 함께 작동하는지 모르겠습니다. @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

참고 .d.ts 파일이 발견되면 인계받는 것처럼 보이기 때문에 자바스크립트 "정의로 이동"을 사용하기 위해 한 지점에서 "typescript.disableAutomaticTypeAcquisition": true 를 사용해야 했습니다.

@DanielRosenwasser 이에 대한 업데이트가 있습니까? - 나에게 가장 원하는 기능.

이것은 전적으로 Typescript로 작성된 단일 저장소에서 작업하는 경우 특히 성가시다. 유형에 필드를 추가하거나 "정의로 이동"을 사용하는 이와 유사한 작은 변경 사항을 여러 번 추가한 다음 나중에 실제 .ts 아닌 .d.ts 파일에 추가했음을 깨닫고 다시 누락되었음을 발견했습니다. .ts 파일

@DanielRosenwasser 이것이 진행되고 있습니까? 나는이 기능을 정말로 좋아할 것입니다.

같은 문제. xx.d.ts 아닌 소스 코드로 "구현으로 이동"하고 싶습니다.

네, 하루에도 여러 번 cmd+click을 사용한 후 실수로 선언 파일을 편집하고 코드가 제대로 실행되지 않을 때 혼란스러워집니다. 특히 src와 dec가 매우 유사해 보이기 때문입니다. 선언 소스로 이동하려는 경우 선택할 수 있는 방법이 있다면 굉장할 것입니다. 또는 VSCode가 소스로 이동하는 것이 항상 더 바람직한 IMHO(사용 가능한 경우)인 것으로 파악한다면 더 좋을 것입니다.

소스로 이동하는 것이 항상 더 선호되는 IMHO(사용 가능한 경우)

소스가 TS에 있을 때. 소스가 JS에 있는 경우 .d.ts로 이동해야 하는 좋은 이유가 있습니다.

소스가 TS에 있을 때. 소스가 JS에 있는 경우 .d.ts로 이동해야 하는 좋은 이유가 있습니다.

왜요? 마우스를 가져가서 유형 정의를 볼 수 있습니다. 어쨌든 유형 정의와 구현에 대한 별도의 명령이 있어야 합니다.

이것이 아직 보류 중인 이유가 있습니까? 해결 방법, 대안 또는 무엇입니까? 미리 감사드립니다

Typescript 파서는 종종 .ts 구현 파일에서 d.ts 파일을 생성하기 때문에. Typescript 편집기가 개발자를 구현 클래스 또는 기능 목록으로 안내할 수 있도록 d.ts 및 .ts 파일 간의 연결을 보존할 수 있습니까(아마도 typescript 컴파일러 옵션으로 출력)?

저는 이러한 선언 파일 소스맵을 정확하게 생성할 수 있는 #21930 분기 를 가지고 있으며(요청 시 또는 #21930이 병합되면 검토를 위해 해당 항목을 가질 것입니다), 이러한 맵을 따르기 위해 LS에 지원을 추가하는 작업을 하고 있습니다. 우리는 그것을 2.8에서 발송하고 싶습니다.

예, 우리는 그것에 대해 작업했습니다. 내부적으로 많은 변화가 필요했을 뿐입니다. 😄

이 문제에 대한 업데이트는 node_modules 아래의 폴더를 수동으로 확장하고 항목 모듈 파일을 찾아 구현을 찾는 데 따른 수고를 덜어줄 것입니다.

이에 대한 해결 방법이 있습니까?
ts로 작성된 db 쿼리를 위한 큰 모듈이 있으므로 node_modules를 통해 검색하는 대신 하나의 명령으로 실제 소스 코드를 보는 것이 정말 좋을 것입니다.

@derN3rd 명령 패널에서 node_modules 를 탐색할 수 있는 vscode-search-node-modules 확장이 있습니다(또한 항상 README vscode-open-node-modules 여는 포크가 있습니다)

필요/가져오기를 클릭하고 파일을 오픈 소스하는 것이 완벽한 ux와는 거리가 멀지만 node_modules 스크롤하는 것보다 확실히 낫다는 것을 이해합니다.

@derN3rd 우리는 2.9에서 --declaratrionMap 플래그를 출시할 예정이며(다음 달에 출시될 수 있음) 이미 연결된 .d.ts 를 통해 원래 소스 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과 함께 제공됩니다. 이 문제에 대한 소식이 있습니까?

나를 위해 작동합니다(VSCode 1.27.0을 실행하는 TS 2.9.2로 생성된 선언 맵). API 소비자(JS로 구현됨)에서 탐색 _정의로 이동_은 .ts 파일의 구현으로 이동합니다.

@robsman _Go to Definition_은 컴파일된 js 코드로 이동하는 반면 _Go to Type Definition_은 .d.ts 파일로 이동합니다.

소스 파일을 열기 위해 컴파일된 모듈을 어떻게 사용/포함합니까?

이 문제는 VSCode 1.27.0에서 여전히 존재합니다. 두 기능 모두 .d.ts 파일로 이동하기 때문입니다.

편집 : 귀하의 의견을 오해 한 것 같습니다. 실제 코드로 이동합니까? 그렇다면 monorepo를 사용하고 있습니까 아니면 컴파일된 코드가 자체 npm 모듈에 포함되어 있습니까? 컴파일된 코드와 함께 소스 파일을 제공합니까?

@derN3rd 는 _Go to Definition_ 및 _Go to Type Definition_ 및 _Peek Definition_을 통해 _.ts_ 파일의 실제 코드를 다시 테스트했습니다.

API 선언과 구현은 모두 호출 패키지가 _git+ssh..._ 종속성으로 참조하는 별도의 모듈에 있습니다.

@robsman Go to Definition 는 node_modules 아닌 .d.ts node_modules 내부의 소스 js 파일(자바스크립트인 경우)의 "this" 클래스 또는 함수의 소스를 참조해야 한다고 생각합니다. Sublime Text 3에서 작동하는 것처럼 말입니다. 어쨌든 나는 현재 상태에서 이 기능이 어떤 VSCode에 대해 이해하지 못합니다.

희망은 이 문제의 우선 순위를 정할 수 있습니다. 많은 의견과 관련 문제로 인해 정말 큰 고통입니다.

코드를 탐색하기 위해 command-click을 사용하려는 사람들의 긴 목록에 저를 추가해 주십시오. 내 프로젝트에 TS가 없고 탐색하려는 npm 패키지가 TS를 사용하지 않지만 require('co-body')를 명령 클릭하면 내부적으로 생성된 TS 정의로 이동합니다. 저는 오랫동안 IntelliJ 사용자이며 여전히 이 때문에 IntelliJ로 대체합니다.

긴 요청입니다

저는 VS Code를 아주 좋아하고 막 새로운 Node 프로젝트를 시작했고 처음으로 TypeScript를 사용하기로 결정했습니다. 지금까지는 대부분 좋았지만 이 문제가 골칫거리였습니다. 오픈 소스에서 작업할 때 종속 항목의 실제 소스 코드를 클릭하여 연결하는 기능은 워크플로에 매우 중요합니다. TypeScript 소스 파일에서 작업하고 관련 문서가 없는 관련 @types/xxx 모듈과 함께 JS NPM 모듈을 사용하고 있습니다. TypeScript가 포함된 IntelliSense는 훌륭하지만 항상 충분한 정보를 제공하지는 않습니다. 최소한 import 문에서 모듈 소스로 직접 클릭할 수 있으면 좋을 것입니다. 나는 작동하는 일부 라이브러리를 믿고 다른 라이브러리(예: Passport)에서는 @types 모듈의 부속 TypeScript 스텁을 지나칠 수 없습니다.

이것은 _제안_이 아니라 _버그_로 표시되어야 합니다.

코드 탐색이 없으면 JavaScript 개발자의 VSCode 경험이 정말 망가집니다.

스레드에 스팸을 보내서 죄송하지만 search-node-modules 확장 😬을 사용합니다.

WebStorm은 StackOverflow , BugTracker 와 같은 동작을 합니다.

• VSCode에는 "정의로 이동" 및 "유형 정의로 이동" 작업이 있습니다.

• WebStorm에는 "선언으로 이동" 및 "유형 선언으로 이동" 작업이 있습니다.

그러나 TypeScript를 사용할 때 두 IDE 모두 동일한 작업을 수행합니다. 항상 유형 정의로 이동합니다!

node_modules/ 라이브러리에서 "정의로 이동" 및 "유형 정의로 이동"을 사용하면 둘 다 .d.ts 파일로 이동합니다. 저는 작성 시점(1.34.0)을 기준으로 최신 VS 코드를 사용 중입니다.

예를 들면 : NPM 패키지 @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에서 숨겨져 있다는 것을 의미합니다.

내가 아는 것은 내 코드에서 "정의로 이동" 및 "유형 정의로 이동"을 안정적으로 사용할 수 있다는 것뿐입니다. 이 경우 소스로 직접 이동합니다. 내 코드에 대해 .d.ts 파일이 표시되지 않습니다.

지금은 수동으로 소스 코드를 검색해야 합니다./

아, Intellij IDEA가 Typescript 3.0.1을 사용하여 같은 프로젝트에 있더라도 이 기능이 정말 잘 작동한다는 것을 알았습니다.

이 문제의 우선순위를 높여야 한다고 생각했습니다.

작업 공간 설정을 열려면 + , 명령 -> Use Ignore Files 선택 취소 -> Search: Exclude: **/node_modules 삭제 및 수동으로 소스 코드를 검색해야 합니다.

매일!

이것이 flow 가 여전히 유용한 이유입니다.

typescript 팀의 누군가가 코드에서 잠재적으로 수정할 수 있는 위치를 제안할 수 있습니까?

재미있는 점은 일부 패키지에 사용 가능한 유형이 없는 경우 "유형 정의로 이동"이 실제로 더 잘 작동한다는 것입니다. "이동" 기능이 마음에 들면 타이핑을 사용 하지 않는 것이 좋습니다.

다음은 타이핑이 없는 device 패키지의 정의로 이동할 수 있음을 보여주는 스크린캐스트이지만 compression 는 나를 임의의 타이핑 파일로 안내합니다.

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh 나는 다른 사람들과 동의해야합니다. 이것은 제안이 아닌 버그로 표시되어야합니다..

내 경우에는 내 자신의 코드에 이와 같은 것이 정의되어 있으면

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

T가 npm 모듈에서 온 경우 정의로 이동하려고 할 때 2개의 정의가 표시됩니다. 내 자신의 코드와 타이핑 정의. 유형 정의로 이동하면 정의 파일로 바로 이동합니다.
첫 번째 경우에는 정의로 바로 이동해야 합니다.
이 문제를 해결하기 위해 편집기 --> goto location: multiple을 goto 대신 peek

이 기능이 필요합니다. 구현을 어떻게 도울 수 있습니까?

이것에 대해 +1하십시오!

2015년부터 솔루션이 없습니다 :(

우리가 갈 수있는 경우 영업 이익은 요구했다 .ts 우리가 발견 할 때 파일 .d.ts 당신이 운반 할 경우 - 파일을 .ts 의 파일 .d.ts 파일과 선언 --declarationMaps 의해 생성된 지도, 이것이 우리의 현재 동작입니다. 여기에서 추적하는 이 스레드의 _second_ 요청은 .js 출력 파일로 이동하는 옵션입니다(예: .ts 소스가 t 배송). 구현 측면에서 이는 선언 소스 맵과 우리가 이미 내보낸 자바스크립트 소스 맵을 결합하는 문제일 뿐이지만 이러한 기능이 어떻게 표시되어야 하는지는 아직 결정하지 않았습니다. ts 코드의 Go to implementation 는 이미 대부분의 코드에 유용한 의미를 가지고 있습니다. 파일, 대신 js 파일로 확인하려고 시도), 아니면 새 엔드포인트를 추가합니까? 나중이라면 vscode 팀과 어떻게 표면화하고 싶은지에 대해 이야기해야 합니다.

@DanielRosenwasser 솔직히 말해서, 여기서 우리가 정말로 필요로 하는 것은 정확히 어떻게 이런 것을 노출시키고 싶은지에 대한 보다 자세한 설명입니다.

vscode 팀의 코더는 이것이 구현되어야 하는 방법에 대한 아이디어를 제안할 수 있습니다(예: Go to js implementation 또는 이와 유사한 것). 첫 번째 좋은 단계는 vscode 이슈 트래커에서 티켓을 생성하고 이 티켓을 상호 참조하여 커뮤니케이션이 가능하도록 하는 것입니다. 시작하다.

내 이해는 여기에 몇 가지 관련된 문제가 있다는 것입니다. (1)이 가장 중요하지만 다른 사람들도 염두에 두어야 합니다.
1) TS 유형의 JS 또는 TS 구현으로 이동하는 쉬운 방법이 없습니다. (또는 .d.ts가 구현과 함께 배치되지 않은 다른 경우)
2) 선택 항목 자체가 유형인 경우 유형 정의로 이동이 작동하지 않습니다. "유형 정의를 찾을 수 없음" 오류가 발생합니다.
3) 유형이 아닌 식별자에 대한 정의로 이동이 일관되지 않게 작동합니다. 때로는 구현으로 이동하지만 때로는 그렇지 않습니다. 이론상 이것은 (1)과 동일하지만 이 불일치를 그대로 두고 (1)을 푸는 것도 가능합니다.

사용자가 세 번째 "이동" 메뉴 옵션을 추가하지 않고_ 세 가지 문제를 모두 해결하는 것이 더 간단할 것이라고 생각합니다. 대신 두 가지 메뉴 항목만 유지하되 보다 일관되게 작동하도록 하는 것이 좋습니다.

• 정의로 이동은 로컬 코드, 통합된 .d.ts 파일이 있는 node_modules 패키지 또는 JS 패키지와 별도의 ConfirmlyTyped 정의 여부에 관계없이
• 유형 정의로 이동 은 선택 항목이 유형인지 유형이 아닌 식별자인지에 관계없이

세 번째 선택이 필요한 다른 일반적인 TS 사용 사례가 있습니까?

BTW, 구분을 더 명확하게 하려면 "정의로 이동"을 "구현으로 이동"으로 이름을 바꿀 수 있지만 IMHO는 선택 사항인 변경 사항인 것 같습니다. 일관성(이름에 관계없이)은 상위 비트입니다.

TS 유형이 DefinedTyped 패키지에서 선언된 경우 TS 유형의 JS 또는 TS 구현으로 쉽게 이동할 수 있는 방법은 없습니다. (또는 .d.ts가 구현과 함께 배치되지 않은 다른 경우)

_기술적으로_ DT 패키지와 함께 사용할 소스맵을 손으로 돌리고 싶다면 이미 잘 될 것입니다. 그러나 여기에는 자동화된 솔루션이 없습니다. 우리가 가지고 있는 모든 솔루션은 TS 컴파일러 출력과 관련된 개선된 시나리오를 기반으로 하며, 파일 간의 올바른 연결을 만드는 데 필요한 추가 메타데이터를 출력할 수 있는 유일한 경우입니다. 일부 패키지는 오늘 이것을 지원한다고 생각합니다. 저는 요전에 azure js sdk를 사용하고 일부 항목을 디버깅하고 있었고 일부 정의에 가서 원래 소스에 있다는 것을 발견했을 때 즐겁게 놀랐습니다. 예, 최신 --declarationMaps 출력이 번들로 제공되는 TS 소스에서 작동합니다.

선택 항목 자체가 유형인 경우 유형 정의로 이동이 작동하지 않습니다. "유형 정의를 찾을 수 없음" 오류가 발생합니다.

나는 여러분이 그것에 대해 새로운 문제를 열어야 한다고 생각합니다. 그것은 단지 expections/bug의 실패일 뿐입니다. 최소한 "선택은 유형이므로 해당 값과 연관된 유형 정의가 없습니다"와 같은 오류를 개선할 수 있습니다.

유형이 아닌 식별자의 정의로 이동이 일관되지 않게 작동합니다. 때로는 구현으로 이동하지만 때로는 그렇지 않습니다. 이론상 이것은 (1)과 동일하지만 이 불일치를 그대로 두고 (1)을 푸는 것도 가능합니다.

_first_ 정의로 이동합니다. 여기서 first는 매우 임의적이며 로드된 순서 파일과 같은 항목을 기반으로 합니다. peek 창은 모든 정의 사이트를 보여주기 때문에 확실히 더 유용합니다. "구현"은 작동하지 않습니다.

사용자로서 다음과 같이 작동하면 만족할 것입니다.

기호를 Ctrl+클릭(대부분 코드 탐색에만 사용)은 현재 구현(VS Code에서 편집 중인 패키지 내에 있는 경우) 또는 선언(종속성의 패키지인 경우)으로 가져옵니다. . 첫 번째는 고려할 필요가 없습니다. 두 번째, 선언으로 이동할 때 선언을 Ctrl+클릭하고 싶습니다. 그러면 구현으로 이동합니다. 찾아보고 다운로드하여 열 수 있는 경우입니다. 그렇지 않으면 어떤 문제로 인해 소스를 찾거나 열 수 없다는 메시지가 표시됩니다. 이대로 작동했다면 굉장했을 것입니다.

원본 소스 코드를 찾는 데 다음과 같은 시나리오가 있다고 생각합니다.

1. 패키지는 외부 저장소에 있는 typescript 및 원본 소스 코드로 작성되며
   a) 배포에는 d.ts 및 js 파일이 포함됩니다. 또는
   b) 배포에는 d.ts , js 및 ts 파일이 포함됩니다.
2. 패키지는 현재 저장소(모노 리포지토리의 경우)에 있는 타이프스크립트와 원본 소스 코드로 작성되고
   a) 배포에는 d.ts 및 js 파일이 포함됩니다.
3. 패키지는 외부 저장소에 있는 자바스크립트와 원본 소스 코드로 작성되며
   a) 배포에는 자체 d.ts 및 js 파일이 포함됩니다. 또는
   a) 배포에는 js 파일만 포함되며 외부 @types 정의가 사용됩니다.
4. 패키지는 현재 저장소(모노 리포지토리의 경우)에 자바스크립트와 원본 소스 코드로 작성되었으며
   a) 배포에는 자체 d.ts 및 js 파일이 포함됩니다.

1b) - 거의 사용되지 않으며 번들 공포증 및 npm 추세와 같은 리소스가 런타임에 실제로 크지 않은 거대한 패키지 크기를 보고하지만 사람들은 이러한 리소스를 기반으로 크기를 판단하므로 이 접근 방식이 마음에 들지 않습니다. 따라서 ts 파일을 배포판에 포함하도록 유지 관리자에게 의존하는 것은 좋은 생각이 아니지만 ts 파일이 포함되면 확실히 문제가 해결됩니다.

1a) - (대부분?) 빈번한 경우. 패키지는 컴파일 시 원본 소스가 있는 위치(예: microsoft pdb 기호 파일 선언) 또는 다운로드할 수 있는 위치(예: git+revision+를 통해)를 선언해야 합니다. 길. VS 코드는 로컬 파일로 이동하거나 git fetch 로컬 캐시로 이동하고 선언에서 구현으로 탐색 시 엽니다.

2a) - 모노 리포지토리의 경우를 자동으로 감지할 수 있는 경우(일부 휴리스틱 사용) 원래 Ctrl+Click 탐색이 구현을 직접 열 수 있습니다. 불가능한 경우 1a)로 대체하는 것으로 충분합니다.

3에 대해서는 덜 신경 쓰지만 3a)가 두 번째 Ctrl+Click 탐색에서 JS 구현을 열 수 있다면 좋을 것입니다. 3b)의 경우 @types 패키지는 주석을 추가하는 JS 패키지를 선언해야 하므로 VS 코드는 외부 패키지의 JS 구현으로 이동하기 위해 이 정보를 가질 수 있습니다.

나는 4에 대해 덜 신경 쓰지만 2a)와 동일한 동작을 가질 수 있습니다. 4a)에 대한 대체는 3a)입니다.

도움이 되기를 바랍니다.

1a) - (대부분?) 빈번한 경우.

네, 지금 지원 가능한 모든 도구가 준비되어 있습니다. .js.map 및 .d.ts.map 파일을 결합하여 .d.ts 에서 .js 로의 매핑을 생성할 수 있습니다(중간 .ts 제외). 하지만, 흠. 실제로 선언 파일로 이동한 다음 다시 상호 작용하여 연결된 js로 이동하시겠습니까? js로 바로 이동하고 싶지 않으신가요?

"정말로, 선언 파일로 이동한 다음 다시 상호 작용하여 연결된 js로 이동하시겠습니까? js로 바로 이동하고 싶지 않으신가요?"

1a)의 경우, 더블 점프나 싱글 점프가 나에게 좋다. 단일 점프가 "더 효율적인" 것으로 간주될 수 있지만 이중 점프는 "라이브러리 소비" 관점에서 사용자에게 두 번째 점프가 블랙박스로의 점프임을 "일깨워주는" 이점이 있습니다(즉, 소스가 탐색 중인 파일은 현재 프로젝트의 일부가 아닙니다. 이 동작을 구성할 수 있습니다.

3a), 3b), 4의 경우 반드시 더블 점프를 하고 싶습니다. 먼저 선언을 보고 이 후에만(디버깅과 같은 매우 드문 경우) 구현을 보고 싶습니다. TS 선언을 건너뛰고 JS로 바로 이동하면 선언의 모든 이점이 제거됩니다. 따라서 TS 선언을 먼저 보고 싶습니다.

(여러 게시물의 @weswigham 및 @avkonst에 대한 답장 결합)

첫 번째 정의로 이동합니다. 여기서 first는 매우 임의적이며 로드된 주문 파일과 같은 항목을 기반으로 합니다.

가져온 특정 기호에 대한 구현으로 이동하려는 가장 일반적인 경우에 여러 정의가 있는 이유는 무엇입니까? 이게 일반적인 상황인가요?

.d.ts에서 .js로의 매핑을 생성합니다(중간 .ts 제외).

"중간 TS 없이"를 이해하는지 잘 모르겠습니다. 원래 .ts 소스를 사용할 수 있는 경우에도 VSCode가 변환된 .js로 이동한다는 것을 의미합니까? 그것은 나쁜 생각인 것 같습니다. 원본 소스를 사용할 수 있는 경우 디버거가 소스 맵이 있는 트랜스파일된 코드로 들어갈 때와 마찬가지로 VSCode가 그곳으로 이동해야 합니다. 즉, 패키지 작성자가 사악하거나 게으르고 npm 배포판에 원래 TS 소스를 포함하지 않은 경우 VSCode가 트랜스파일된 JS로 폴백하고 아마도 사용자가 보고 있는 이유를 설명하는 경고 메시지를 표시하는 것이 합리적으로 보입니다. 그런 이상하고 읽을 수 없는 코드를 만들고 사용자가 패키지 작성자에게 패키지에 원본 소스를 포함하도록 잔소리를 하도록 권장합니다.

실제로 선언 파일로 이동한 다음 다시 상호 작용하여 연결된 js로 이동하시겠습니까? js로 바로 이동하고 싶지 않으신가요?

2단계가 가치를 더할 것이라고 생각하지 않습니다. 독특하고 일관된 UX를 갖는 것이 훨씬 낫다고 생각합니다. "유형 정의로 이동"을 사용하여 유형 정의로 이동하고 정의로 이동(또는 구현으로 이동-우리가 무엇이라고 부르든 간에)을 사용하여 원본으로 이동합니다. 소스 코드 또는 위의 내용에 따라 원본 소스를 사용할 수 없는 경우 트랜스파일된 JS로.

IMHO, 선택한 기호가 자신의 코드와 node_modules에 정의되어 있는지 여부에 따라 다른 동작을 갖는 것이 훨씬 더 혼란스럽습니다. 그것은 중요하지 않습니다. 유형을 보려면 VSCode에서 유형을 확인해야 합니다. 구현 코드를 보고 싶다면 VSCode가 저를 그곳으로 데려다 줄 것입니다. 대규모 조직에서 "내 코드"와 "라이브러리 코드"가 항상 명확한 것은 아니기 때문에 특히 그렇습니다. 다른 사람이 코드를 공유 내부 패키지로 리팩토링한 경우 해당 코드로 이동하는 방법을 변경할 필요가 없습니다.

먼저 선언을 보고 이 후에만(디버깅과 같은 매우 드문 경우) 구현을 보고 싶습니다.

개발자가 형식 선언을 볼 것인지 구현 코드를 볼 것인지를 명시적으로 선택하도록(하나의 메뉴 항목 또는 다른 항목을 선택하여) 요구하는 것이 더 명확한 것 같습니다. 코드의 출처에 따라 탐색이 일관성이 없다는 것은 불필요하게 혼란스러워 보입니다.

> 선택 항목 자체가 유형인 경우 유형 정의로 이동이 작동하지 않습니다.
나는 여러분이 그것에 대해 새로운 문제를 열어야 한다고 생각합니다. 그것은 단지 expections/bug의 실패일 뿐입니다.

예, 이것은 확실히 먼저 고칠 수 있습니다. 내가 선호하는 솔루션("정의로 이동은 항상 구현으로 이동")이 채택되면 사용자가 .d.t를 보고 싶을 때마다 유형 정의로 이동을 사용하는 습관을 갖게 되므로 여기에 포함시켰습니다. 유형에 대해 이 작업을 수행하는 것이 유형이 아닌 식별자에 대해 작동하는 방식과 일관되게 작동하지 않으면 이상할 것입니다.

"첫 번째 정의로 이동합니다. 여기서 first는 매우 임의적이며 로드된 순서 파일과 같은 항목을 기반으로 합니다."

나는 첫 번째 정의로 이동해야 한다고 답장에서 언급하지 않았습니다. 나는 기호를 Ctrl+Click할 때 무엇보다 먼저 정의로 이동해야 하고(지금 작동하므로) 후속 Ctrl+Click에서만 구현으로 이동해야 한다고 말했습니다.

"개발자가 유형 선언을 볼 것인지 구현 코드를 볼 것인지를 명시적으로 선택하도록 요구하는 것이 더 명확한 것 같습니다."

별도의 상황에 맞는 메뉴를 사용하는 것이 좋습니다. Ctrl+클릭 동작과 상호 배타적이지 않습니다.

이 치명적인 버그가 아직 해결되지 않은 이유가 궁금합니다. 타이프 스크립트 채택이 증가함에 따라 점점 더 골칫거리가 되고 있습니다.

기술적인 설명은 듣고 싶지 않습니다. 여러 사용자에 대한 설명이 많아도 이 문제가 인식되지 않는 이유를 알고 싶습니다.

@zjaml TypeScript 소스 파일 또는 JavaScript 소스 파일로 이동하시겠습니까? TypeScript 소스 파일이 지원됩니다. 이 문제가 현재 여전히 열려 있는 것은 JavaScript 소스 파일입니다.

접선 관련; npm에 게시된 공통 패키지가 있는 monorepo가 ​​있습니다. 이 공용 인터페이스 때문에 dist는 js + d.ts 파일입니다. 저장소에서 작업할 때 VSCode는 항상 소스 대신 d.ts로 이동합니다. 이 문제를 해결하는 방법을 알고 있습니까?

@0x80 방금 설명한 시나리오에 대해 이 문제가 여전히 열려 있다고 생각합니다. 이 문제를 해결할 수 있는 유일한 방법은 프로젝트가 오픈 소스이고 typescript 소스에서 컴파일한 경우입니다. 그런 다음 typescript 컴파일러에 대한 --declarationMaps 플래그를 켤 수 있으며 선언 맵을 지원하는 IDE는 d.ts 파일 대신 typescript 소스로 이동합니다.

이것은 정말 중요합니다. 간단한 것을 원합니다. 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/src/core/internal/abc.ts 있을 때 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 소스에 매핑하는 소스 맵입니다. 선언 맵을 구현하기 위해 의존하는 라이브러리를 확신할 수 있다면(이는 @types에 의존하는 것과 반대로 라이브러리 패키지 내부에 .d.ts를 효과적으로 게시해야 한다고 생각합니다) 클라이언트 코드에서 자동으로 점프할 수 있습니다. 원본 TS(또는 JS에서 TS 컴파일러를 사용하는 경우 JS?) 소스 코드.

내가 하고 있는 일은 가장 중요한 종속성(적어도 TS로 작성된 종속성)에 대해 점진적으로 PR을 제출하여 선언 맵을 추가하도록 하는 것입니다.

분명히 라이브러리를 변경할 필요가 없다면 더 좋을 것입니다.

다른 해결 방법(라이브러리 변경이 불가능한 경우)은 라이브러리가 패키지 내부에 .d.ts를 번들하지만 선언 맵이 없는 경우에 작동합니다. 이 경우 정의로 이동을 사용하여 형식 선언으로 이동한 다음 VSCode에서 탐색기 버튼을 클릭하여 폴더 사이드바를 표시하겠습니다. 그러면 일반적으로 패키지의 src 폴더에 매우 가까워지므로 모든 node_modules를 검색하는 대신 올바른 폴더를 찾아 올바른 파일을 열 수 있습니다. 이는 명확한 파일 이름 지정 등에 따라 달라지며 만병 통치약이 아닙니다.

100% 명확히 하자면-- 도서관을 위한 더 나은 솔루션을 보고 싶습니다. 특히. .d.ts는 패키지와 별도로 작성됩니다.

내가 놓쳤는지 확실하지 않지만 소스, 선언 및 선언 맵의 실제 최소 예가 있는 상황을 이해하는 데 정말 유용할 것입니다. Go to Definition, Go to Type Definition 또는 Go to Implementations가 실제로 트랜스파일된 TS에 대해 .d.ts 파일이 아닌 다른 곳으로 이동하는 것을 본 적이 없습니다. 방금 간단한 예제 를 만들려고 했지만 작동하지 않습니다. .d.ts.map 가 옆에 있어도 VS Code가 .d.ts 파일 이외의 파일로 이동하도록 할 수 없습니다. 나는 또한 무시당한 동일한 문제 를 을 찾았습니다.

@types 와 같은 외부 입력을 지원하는 것이 어려운 것은 이해할 수 있지만 "행복한 길"도 작동하지 않는다는 것은 무엇입니까?

선언 파일을 생성하지만 선언 맵은 생성하지 않는 라이브러리가 많이 있으며, 이를 활성화하기 위한 인수가 무엇인지 불분명합니다. 이 옵션은 최소한 내가 찾을 수 있는 명확한 설명 없이 추가되었습니다.

예, 선언 맵이 문제를 해결하지 못한다는 것을 확인합니다. 내 프로젝트에 선언 맵이 있지만 vscode는 .d.ts 파일을 넘어 탐색하지 않습니다.

이런 일이 발생하면 확실히 좋을 것입니다.

ms vscode devs에 대한 "방에 코끼리" 문제가 있다면 이것이 전부입니다.

이것에 대한 업데이트가 있습니까?
저는 큰 걸음을 내딛기로 결정했습니다. JS에서 TS로 이동하는 것입니다. 나는 "내가 뭘 잘못하고 있는 거지?"라고 생각했습니다. 그러나 실제로는 VSCode의 예기치 않은 동작입니다.

이것에 대한 업데이트가 있습니까?
저는 큰 걸음을 내딛기로 결정했습니다. JS에서 TS로 이동하는 것입니다. 나는 "내가 뭘 잘못하고 있는 거지?"라고 생각했습니다. 그러나 실제로는 VSCode의 예기치 않은 동작입니다.

이러한 행동이 제기된 것은 오랜 역사였습니다. 글쎄요, 아무 일도 일어나지 않습니다. 지금까지 계획이 없습니다.
저에게는 vscode를 그대로 편집기의 일종으로 계속 사용하고, 별로 좋아하지 않는 경우에도 코딩에 Intellij 제품(IDEA)을 사용합니다.

개통 5년, 2025년에 고쳐지기를 바랍니다.

#39426에서 실패한 테스트를 만들었지만 구현 방법을 모르겠습니다.

정의를 찾기 위해 매일 지옥을 겪고 있는 ts dev의 또 다른 비참한 코멘트

이건 미쳤어... 난 그냥 TS 멍청한 놈이라고 생각했는데, 이제 내가 얻는 행동이 실제로 "표준"임을 알 수 있습니다???? 너무 실망 스럽습니다. 내가 사용한 다른 모든 IDE/언어는 초기 릴리스에서 이것을 구현했습니다 ... :( VS 코드를 좋아하지만 정직하게 이것은 거래 차단기가 될 수 있습니다.

Python 확장이 포함된 VSCode의 go to definition/implementation 기능이 기본 내장 솔루션이 있는 JS보다 Python 언어가 더 잘 작동하는 이유(적어도 작동함)를 설명할 수 있습니까?

무슨 일이야?
CSS 모듈에 scss.d.ts를 사용하고 있으며 scss로 이동할 수 없습니다.

또한 간단한 .js와 그에 따른 d.ts를 만들 때 js로 바로 이동할 수 없습니다.

왜 웹스톰을 사용하지 않습니까?
이 문제를 해결할 수 있습니다!!!
내 버전 2020.1

왜 웹스톰을 사용하지 않습니까?
이 문제를 해결할 수 있습니다!!!
내 버전 2020.1

오픈 소스 솔루션이 아니며 무료가 아니기 때문에

이 문제를 해결하세요.

이 문제는 Microsoft의 일부 관리자가 인계받은 경우에만 고칠 수 있고, 이 문제를 관리하고 조정해야 하며, 관리자가 워크플로를 개발하고 작업을 코더에게 할당하는 경우에만 해결될 수 있다는 것은 절대적으로 분명합니다. ☝
이 문제는 인계받기 위해 경영진에게 보내져야 하고 그들은 그것을 구현하는 방법을 결정합니다.
따라서 여기에 Microsoft의 유능한 사람이 있다면 기회를 줄 수 있습니다. 😊