Typescript: Aktifkan Buka Implementasi di Editor TypeScript

Jadi Anda ingin fungsi ini melompat ke .js jika tersedia, asalkan definisinya ambient, benar?

@RyanCavanaugh @mousetraps @bowdenk7

Jadi Anda ingin fungsi ini melompat ke .js yang sesuai jika tersedia, asalkan definisinya ambient, benar?
Ya ini adalah skenario yang akan sangat berguna untuk produktivitas. Ini saja akan sangat berharga. Saya percaya penulis atom-TypeScript percaya lebih banyak kait di kompiler TypeScript akan membuatnya lebih mudah untuk mengimplementasikan ini. Saya tidak jelas apakah ini informasi tentang nomor baris implementasi js adalah informasi yang biasanya diketahui oleh kompiler TypeScript secara internal.

Selain itu, skenario lain akan memungkinkan lompatan ke definisi file .ts TypeScript asli di perpustakaan yang digunakan oleh aplikasi. Saya akan membayangkan informasi ini tersedia sebelum dikompilasi ke file d.ts dan .js. Kami sekarang memiliki seluruh set pustaka yang ditulis dalam file .ts sebagai sumber yang mengeluarkan sintaks ES5 js. Akan menyenangkan untuk mencapai kemampuan untuk melompat ke definisi implementasi TypeScript asli dalam file .ts.

Saya sadar ini meminta lebih banyak untuk melompat ke implementasi file .ts di perpustakaan yang diperlukan karena mungkin memerlukan penggunaan peta sumber atau distribusi sumber/tautan ke sumber ts asli. Tampaknya bagi saya bahwa kompiler TypeScript yang menghasilkan perpustakaan awal fungsi dan kelas akan mengetahui baris di mana implementasinya berada dan dapat mempertahankan nomor baris ketika perpustakaan didistribusikan entah bagaimana sehingga kompiler typscript dari aplikasi menggunakan kelas bisa tahu baris mana yang harus dilompati di perpustakaan.

Apakah informasi tentang nomor baris fungsi/kelas implementasi ini tersedia di peta sumber? Apakah ada sumber lain untuk informasi ini?

Mengingat bahwa kita akan menggunakan flag --allowJS , layanan bahasa harus dapat bekerja dengan file JS.

Saya tidak tahu bagaimana file .d.ts dan file .js saat ini bekerja bersama dalam hal itu. @sheetalkamat mungkin (pasti) tahu lebih banyak tentang ini daripada saya.

Membuka kembali, karena membuka file js belum didukung

Adakah pembaruan untuk yang satu ini? Keadaan TypeScript saat ini adalah Anda tidak dapat melompat ke implementasi kode di banyak perpustakaan terkemuka.

Masalah ini telah dipindahkan/ditutup/ditipu/ditipu beberapa kali dan memperbaiki bug ini bisa menjadi peningkatan produktivitas yang besar.

https://github.com/ubershmekel/vscode-ts-goto-source memiliki proyek yang mereproduksi masalah. Seperti yang dijelaskan di https://github.com/Microsoft/vscode/issues/26325 dan dirujuk di https://github.com/Microsoft/vscode/issues/10806 dan https://github.com/Microsoft/vscode/issues /18321

Catatan Saya harus menggunakan "typescript.disableAutomaticTypeAcquisition": true dari satu titik untuk menggunakan javascript "pergi ke definisi" karena tampaknya file .d.ts mengambil alih jika ditemukan.

@DanielRosenwasser Adakah pembaruan tentang ini? - Fitur tunggal yang paling dicari untuk saya.

Ini sangat mengganggu jika bekerja di monorepo yang seluruhnya ditulis dalam TypeScript. Saya memiliki beberapa kali ketika menambahkan bidang ke jenis atau perubahan kecil serupa yang digunakan "pergi ke definisi", menambahkannya dan kemudian menemukannya hilang lagi menyadari bahwa saya menambahkannya ke file .d.ts dan bukan .ts sebenarnya

@DanielRosenwasser Apakah ini berkembang? Saya akan sangat menyukai fitur ini

masalah yang sama. Ingin "Pergi ke implementasi" ke kode sumber, bukan xx.d.ts

Yap, beberapa kali sehari saya secara tidak sengaja mengedit file deklarasi setelah menggunakan cmd+klik dan akhirnya bingung ketika kode tidak berjalan dengan benar. Terutama karena src dan dec terlihat sangat mirip. Akan luar biasa jika ada beberapa cara untuk memilih apakah saya ingin pergi ke sumber deklarasi, atau bahkan lebih baik jika VSCode akan mengetahui ini karena pergi ke sumber selalu lebih disukai IMHO (jika tersedia).

pergi ke sumber selalu lebih disukai IMHO (jika tersedia)

Ketika sumbernya ada di TS. Jika sumbernya dalam JS, ada alasan bagus untuk pergi ke .d.ts

Ketika sumbernya ada di TS. Jika sumbernya dalam JS, ada alasan bagus untuk pergi ke .d.ts

Mengapa? Saya hanya bisa mengarahkan kursor untuk melihat definisi tipe. Bagaimanapun, harus ada perintah terpisah untuk definisi tipe vs implementasi.

Apakah ada alasan mengapa ini masih tertunda? Sebuah solusi, alternatif atau sesuatu? Terima kasih sebelumnya

Karena pengurai TypeScript sering menghasilkan file d.ts dari file implementasi .ts. Bisakah asosiasi antara file d.ts dan .ts dipertahankan (mungkin output dengan opsi kompiler TypeScript) sehingga editor TypeScript dapat membawa pengembang ke daftar kelas atau fungsi implementasi?

Saya memiliki cabang #21930 yang memungkinkan pembuatan dengan tepat peta sumber file deklarasi ini (dan akan mengeluarkannya untuk ditinjau baik berdasarkan permintaan atau setelah #21930 digabungkan), dan sedang berupaya menambahkan dukungan ke LS kami untuk mengikuti peta ini. Kami ingin mengirimkannya dalam 2.8.

Jadi ya, kami sudah mengerjakannya. Itu hanya membutuhkan banyak perubahan internal. 😄

Harapkan pembaruan tentang masalah ini untuk menghilangkan rasa sakit dalam menemukan implementasi melalui perluasan folder secara manual di bawah node_modules dan temukan file modul entri.

Apakah ada solusi untuk ini?
Karena kami memiliki modul besar untuk kueri db kami yang ditulis dalam ts, akan sangat menyenangkan untuk melihat kode sumber asli dengan satu perintah alih-alih mencari melalui node_modules.

@derN3rd Ada vscode-search-node-modules untuk menelusuri node_modules di panel perintah (dan saya juga memiliki garpu yang selalu membuka README vscode-open-node-modules )

Saya mengerti itu jauh dari ux yang sempurna untuk mengklik memerlukan/mengimpor dan membuka sumber file, tetapi jelas lebih baik daripada menggulir node_modules

@derN3rd kami akan mengirimkan flag --declaratrionMap di 2.9 (yang mungkin dirilis selama bulan depan), dan kami telah mengaktifkan pergi ke definisi di sumber asli TS melalui .d.ts menggunakan mereka (yang, jika Anda mengirim file deklarasi di folder modul node Anda mungkin mendapatkan banyak dari apa yang Anda inginkan). Kami juga sedang mencari untuk melompat ke/dari JS terkait juga, asalkan peta sumber normal juga aktif.

@weswigham terima kasih atas balasan cepatnya! Kedengarannya bagus
Bisakah Anda memposting pembaruan di sini jika fitur sudah siap atau siap untuk diuji?

--declarationMap (dan pengalihan LS terkait) telah ada di nightlies kami sejak setelah rilis 2.8. Satu-satunya hal yang belum kami lakukan adalah melompati file JS, karena itu mungkin memerlukan beberapa koordinasi editor tambahan.

Ada berita untuk itu di 3.0-rc?

Masalah yang sama dengan file .css dan .json . Pergi ke Definisi membawa saya ke file .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'

Pergi ke Definisi pada ./App.css membawa saya ke

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;
}

Kode VS sekarang dikirimkan dengan TypeScript 3.0.3. Ada berita tentang masalah ini?

Bekerja untuk saya (peta deklarasi dihasilkan dengan TS 2.9.2, menjalankan VSCode 1.27.0). Menavigasi dari konsumen API (diimplementasikan dalam JS) _Go to Definition_ membawa saya ke implementasi dalam file .ts.

@robsman _Go to Definition_ akan membawa Anda ke kode js yang dikompilasi, sedangkan _Go to Type Definition_ akan membawa Anda ke file .d.ts.

Bagaimana Anda menggunakan/menyertakan modul terkompilasi Anda, untuk membuka file sumber?

Masalah itu masih ada untuk saya di VSCode 1.27.0, karena kedua fungsi membawa saya ke file .d.ts

EDIT: Saya pikir saya salah memahami komentar Anda. Apakah itu membawa Anda ke kode sebenarnya? Jika demikian, apakah Anda menggunakan monorepo atau kode terkompilasi Anda dikirimkan dalam modul npm sendiri? Apakah Anda mengirimkan file sumber dengan kode yang dikompilasi?

@derN3rd diuji ulang, baik _Go to Definition_ dan _Go to Type Definition_ serta _Peek Definition_ membawa saya ke kode sebenarnya di file _.ts_.

Deklarasi dan implementasi API keduanya berada di modul terpisah yang dirujuk oleh paket panggilan sebagai ketergantungan _git+ssh..._.

@robsman Saya pikir Go to Definition harus merujuk saya ke sumber kelas atau fungsi "ini" dalam file js sumber (jika itu javascript) di dalam node_modules bukan .d.ts . Seperti itu berfungsi di Sublime Text 3 maksud saya. Pokoknya saya tidak mengerti untuk apa VSCode fitur ini dalam keadaan saat ini

Harapan dapat memprioritaskan masalah ini, itu benar-benar sakit besar, dari begitu banyak komentar dan masalah terkait.

Tolong tambahkan saya ke daftar panjang orang yang mencoba menggunakan perintah-klik untuk menavigasi kode. Saya tidak memiliki TS dalam proyek saya dan paket npm yang saya navigasikan tidak menggunakan TS, namun perintah-klik pada require('co-body') membawa saya ke definisi TS yang dibuat secara internal. Saya pengguna IntelliJ lama dan masih, karena ini, saya kembali ke IntelliJ.

itu permintaan yang panjang

Saya sangat menyukai VS Code dan saya baru saja memulai proyek Node baru dan memutuskan untuk menggunakan TypeScript untuk pertama kalinya. Sejauh ini sebagian besar baik, tetapi masalah ini telah menjadi titik nyeri. Bekerja di sumber terbuka, kemampuan untuk mengklik ke kode sumber nyata dalam dependensi sangat penting untuk alur kerja. Saya bekerja di file sumber TypeScript dan menggunakan modul JS NPM dengan modul @types/xxx terkait yang tidak memiliki dokumentasi terkait. IntelliSense dengan TypeScript sangat bagus, tetapi tidak selalu memberikan informasi yang cukup. Paling tidak, dapat mengklik langsung ke sumber modul dari pernyataan import akan menyenangkan. Saya percaya pada beberapa perpustakaan yang berfungsi, dan pada yang lain, misalnya Paspor, saya tidak dapat melewati stub TypeScript tambahan dalam modul @types .

Ini harus diberi label _Bug_, bukan _Saran_.

Kurangnya navigasi kode benar-benar merusak pengalaman VSCode untuk pengembang JavaScript.

maaf untuk mengirim spam ke utas tetapi @promaty saya menggunakan ekstensi modul pencarian-node untuk saat ini

WebStorm memiliki perilaku yang sama: StackOverflow , BugTracker

• VSCode memiliki tindakan "Go to Definition" dan "Go to Type Definition"

• WebStorm memiliki tindakan "Go To Declaration" dan "Go To Type Declaration"

Tetapi saat menggunakan TypeScript, kedua IDE melakukan hal yang sama: selalu masuk ke definisi tipe!

"Go to Definition" dan "Go to Type Definition", ketika digunakan pada perpustakaan node_modules/ , keduanya membawa saya ke file .d.ts . Saya menggunakan Kode VS terbaru pada saat penulisan (1.34.0).

Misalnya: npm package @angular/[email protected] , ketika saya mengimpor TestBed dari @angular/core/testing dan mencoba melihat definisi TestBed.createComponent , saya mendapatkan dua hal berbeda:

• "Pergi ke Definisi" -> node_modules/@angular/core/testing/src/test_bed_common.d.ts baris 117
• "Pergi ke Definisi Jenis" -> node_modules/@angular/core/testing/src/component_fixture.d.ts baris 14

Ini pada dasarnya berarti bahwa kode sumber Angular disembunyikan dari saya di Kode VS Saya tidak yakin apakah itu gejala bagaimana perpustakaan Angular ditulis, atau bagaimana TypeScript/VS Code menemukan implementasi sumber.

Yang saya tahu adalah saya hanya dapat menggunakan "Go to Definition" dan "Go to Type Definition" dengan andal pada kode saya sendiri, dalam hal ini saya langsung dibawa ke sumbernya; Saya tidak pernah diperlihatkan file .d.ts untuk kode saya sendiri.

Kita harus mencari kode sumber secara manual untuk saat ini :/

Ah, saya baru tahu bahwa entah bagaimana Intellij IDEA memiliki fungsi ini bekerja dengan sangat baik, bahkan saya berada di proyek yang sama, menggunakan TypeScript 3.0.1

Saya pikir prioritas masalah ini harus ditingkatkan.

Kita harus memerintahkan + , untuk membuka pengaturan ruang kerja -> hapus centang Use Ignore Files -> delete Search: Exclude: **/node_modules , dan cari kode sumber secara manual.

SETIAP HARI!

Jadi itu sebabnya flow masih berguna.

Bisakah seseorang dari tim TypeScript menyarankan di mana dalam kode ini berpotensi diperbaiki?

Yang lucu adalah jika beberapa paket tidak memiliki tipe yang tersedia, "Go To Type Definition" sebenarnya berfungsi lebih baik untuk itu. Artinya tidak menggunakan pengetikan lebih baik jika Anda menyukai fitur "Go To"

Berikut screencast yang menunjukkan bahwa saya dapat masuk ke definisi paket device yang tidak memiliki pengetikan, tetapi compression membawa saya ke beberapa file pengetikan acak:

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh Saya harus setuju dengan orang lain, ini harus diberi label sebagai bug, bukan saran..

dalam kasus saya, jika saya memiliki sesuatu seperti ini yang didefinisikan dalam kode saya sendiri

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

jika T berasal dari modul npm, ketika saya mencoba masuk ke definisi, itu akan menunjukkan kepada saya 2 definisi. Kode saya sendiri dan definisi pengetikan. Jika saya pergi untuk mengetik definisi itu langsung menuju ke file definisi.
Dalam kasus pertama, itu harus langsung ke definisi.
Untuk mengatasinya, saya mengubah editor --> goto location: multiple menjadi goto alih-alih peek

Saya membutuhkan fitur ini. Bagaimana saya bisa membantu implementasinya?

+1 untuk ini tolong!

sejak 2015 dan tidak ada solusi :(

OP menanyakan apakah kami dapat membuka file .ts ketika kami menemukan file .d.ts - jika Anda mengirimkan file .ts dengan file .d.ts dan deklarasi peta yang dihasilkan oleh --declarationMaps , itulah perilaku kami saat ini (jadi cukup selesai). Permintaan _second_ di utas ini, yang sekarang kami lacak di sini, adalah opsi untuk membuka file .js keluaran (yang dapat berguna jika, misalnya, sumber .ts ' t dikirim). Dari segi implementasi, itu hanya masalah menggabungkan peta sumber deklarasi dan peta sumber javascript yang telah kami pancarkan, namun apa yang belum kami putuskan adalah bagaimana fitur tersebut harus muncul. Go to implementation dalam kode ts sudah memiliki arti yang berguna untuk sebagian besar kode (yang masuk ke definisi, tetapi lebih suka deklarasi implementasi/nilai) ... file, coba selesaikan ke file js saja), atau apakah kita menambahkan titik akhir baru? Jika nanti, kita perlu membicarakan bagaimana kita ingin memunculkannya dengan tim vscode.

@DanielRosenwasser jujur, apa yang benar-benar kita butuhkan di sini hanyalah deskripsi yang lebih lengkap tentang bagaimana kita ingin mengekspos hal seperti ini - alat untuk melakukannya sekarang sudah tersedia.

Pembuat kode dari tim vscode dapat mengajukan ide tentang bagaimana ini harus diterapkan, misalnya Go to js implementation atau sesuatu seperti itu, langkah pertama yang baik adalah membuat tiket pada pelacak masalah vscode dan referensi silang tiket ini sehingga komunikasi dapat dilakukan mulai.

Pemahaman saya adalah bahwa ada beberapa masalah terkait di sini. (1) adalah yang besar, tetapi kita harus mengingat yang lain juga:
1) Tidak ada cara mudah untuk menavigasi ke implementasi JS atau TS dari tipe TS jika tipe itu dideklarasikan dalam paket PastiTyped. (atau kasus lain di mana .d.ts tidak ditempatkan dengan implementasi)
2) Go To Type Definition tidak berfungsi ketika seleksi itu sendiri merupakan tipe. Anda akan mendapatkan kesalahan "tidak ada definisi tipe yang ditemukan".
3) Go To Definition pada pengidentifikasi non-tipe berperilaku tidak konsisten. Terkadang itu akan menavigasi ke implementasi, terkadang tidak. Secara teori ini sama dengan (1), tetapi juga memungkinkan untuk menyelesaikan (1) sambil membiarkan inkonsistensi ini tetap pada tempatnya.

Saya pikir akan lebih mudah bagi pengguna untuk menyelesaikan ketiga masalah _tanpa_ menambahkan opsi menu "Pergi Ke" ketiga. Sebagai gantinya, saran saya adalah mempertahankan hanya dua item menu tetapi membuatnya berperilaku lebih konsisten:

• Go To Definition harus selalu menavigasi ke implementasi , terlepas dari apakah itu kode lokal, paket node_modules dengan file .d.ts terintegrasi, atau definisi PastiTyped yang terpisah dari paket JS.
• Go To Type Definition harus selalu menavigasi ke deklarasi TS , terlepas dari apakah pilihannya adalah pengidentifikasi tipe atau non-tipe.

Apakah ada kasus penggunaan TS umum lainnya yang memerlukan pilihan ketiga?

BTW, saya kira kita bisa mengganti nama "Go To Definition" menjadi "Go To Implementation" jika kita ingin membuat perbedaannya lebih jelas, tetapi IMHO ini sepertinya perubahan opsional. Konsistensi (terlepas dari namanya) adalah bit tingkat tinggi.

Tidak ada cara mudah untuk menavigasi ke implementasi JS atau TS dari tipe TS jika tipe tersebut dideklarasikan dalam paket PastiTyped. (atau kasus lain di mana .d.ts tidak ditempatkan dengan implementasi)

_Secara teknis_ jika Anda ingin memutar beberapa peta sumber untuk pergi dengan paket DT, itu sudah bisa berhasil. Tapi jelas tidak ada solusi otomatis di sini. Solusi apa pun yang kami miliki didasarkan pada peningkatan skenario yang melibatkan keluaran kompiler TS, pada saat itulah kami dapat menghasilkan metadata tambahan yang diperlukan untuk membuat asosiasi yang benar antara file. Beberapa paket mendukung ini hari ini, saya percaya - saya menggunakan Azure js sdk tempo hari dan men-debug beberapa hal, dan sangat terkejut ketika saya pergi ke beberapa definisi dan menemukan mereka berada di sumber aslinya. Jadi ya, ini berfungsi dengan sumber TS yang memiliki keluaran --declarationMaps terkini yang dibundel dengan mereka.

Go To Type Definition tidak berfungsi ketika seleksi itu sendiri adalah sebuah tipe. Anda akan mendapatkan kesalahan "tidak ada definisi tipe yang ditemukan".

Saya pikir kalian harus membuka masalah baru tentang itu. Itu hanya kegagalan exepections/bug, imo. Minimal, kesalahan dapat dibuat lebih baik - sesuatu seperti "seleksi hanya tipe dan tidak memiliki definisi tipe yang terkait dengan nilainya".

Go To Definition pada pengidentifikasi non-tipe berperilaku tidak konsisten. Terkadang itu akan menavigasi ke implementasi, terkadang tidak. Secara teori ini sama dengan (1), tetapi juga memungkinkan untuk menyelesaikan (1) sambil membiarkan inkonsistensi ini tetap pada tempatnya.

Ini mengarah ke definisi _first_, di mana first cukup arbitrer, dan berdasarkan hal-hal seperti file pesanan dimuat masuk. Jendela peek diakui lebih berguna, karena menunjukkan semua situs definisi. "Implementasi" tidak ikut bermain.

Sebagai pengguna, saya akan puas, jika berhasil seperti ini:

Ctrl + Klik pada simbol (saya kebanyakan hanya menggunakan ini untuk menavigasi kode) membawa saat ini ke implementasi (jika ada di dalam paket yang sedang diedit dalam Kode VS) atau ke deklarasi (jika itu adalah paket dari dependensi) . Yang pertama tidak memerlukan pertimbangan. Yang kedua, ketika menuju ke deklarasi, saya ingin Ctrl+Klik pada deklarasi dan itu menavigasi saya ke implementasi, jika itu dapat menemukan, mengunduh, dan membukanya untuk saya. Jika tidak, ini menunjukkan pesan masalah apa yang mencegah sumber ditemukan/dibuka. Jika berhasil seperti ini, itu akan luar biasa.

Saya percaya ada skenario berikut dengan menemukan kode sumber asli:

1. Sebuah paket ditulis dalam TypeScript dan kode sumber asli di repositori eksternal dan juga
   a) distribusi termasuk file d.ts dan js ATAU
   b) distribusi termasuk file d.ts , js dan ts
2. Sebuah paket ditulis dalam TypeScript dan kode sumber asli di repositori saat ini (kasus mono repo) dan
   a) distribusi termasuk file d.ts dan js
3. Sebuah paket ditulis dalam javascript dan kode sumber asli di repositori eksternal dan keduanya
   a) distribusi termasuk file d.ts dan js miliknya sendiri ATAU
   a) distribusi mencakup hanya js file dan eksternal @types definisi yang digunakan
4. Sebuah paket ditulis dalam javascript dan kode sumber asli di repositori saat ini (kasus mono repo) dan
   a) distribusi termasuk file d.ts dan js miliknya sendiri

1b) - jarang digunakan, dan saya tidak suka pendekatan ini karena sumber daya seperti bundlephobia dan tren npm akan melaporkan ukuran paket yang sangat besar, yang sebenarnya tidak terlalu besar dalam runtime, tetapi orang menilai ukuran berdasarkan sumber daya ini. Jadi, mengandalkan pengelola untuk menyertakan file ts dengan distribusi bukanlah ide yang baik, tetapi tentu saja jika file ts disertakan, kasusnya terpecahkan.

1a) - (paling sering?) kasus yang sering terjadi. Paket harus beberapa cara mendeklarasikan (melalui package.json atau peta sumber?) di mana sumber asli berada ketika dikompilasi (seperti microsoft pdb file simbol mendeklarasikan) ATAU dari mana dapat diunduh, misalnya git+revision+ jalur. Kode VS akan menavigasi ke file lokal atau git fetch ke cache lokal dan membukanya di navigasi dari deklarasi hingga implementasi

2a) - jika dimungkinkan untuk mendeteksi kasus mono repo secara otomatis (menggunakan beberapa heuristik), navigasi Ctrl+Klik asli dapat membuka implementasi secara langsung. Jika tidak mungkin, mundur ke 1a) sudah cukup baik

Saya kurang peduli dengan 3, tetapi alangkah baiknya jika 3a) dapat membuka implementasi JS pada navigasi Ctrl+Klik kedua. Dalam kasus 3b) paket @types harus mendeklarasikan paket JS apa yang dianotasi, sehingga kode VS dapat memiliki informasi ini untuk menavigasi ke implementasi JS dalam paket eksternal.

Saya bahkan kurang peduli tentang 4, tetapi itu bisa memiliki perilaku yang sama dengan 2a) - mundur untuk 4a) adalah 3a)

Semoga membantu.

1a) - (paling sering?) kasus yang sering terjadi.

Ya, itulah yang saya katakan kita memiliki semua alat untuk mendukung sekarang. Kita dapat menggabungkan file .js.map dan .d.ts.map untuk menghasilkan pemetaan dari .d.ts hingga .js (tanpa perantara .ts ). Tapi, hm. Sungguh, Anda lebih suka pergi ke file deklarasi, dan kemudian berinteraksi lagi untuk pergi ke js terkait? Anda tidak ingin langsung melompat ke js?

"Sungguh, Anda lebih suka pergi ke file deklarasi, dan kemudian berinteraksi lagi untuk pergi ke js terkait? Anda tidak ingin langsung melompat ke js?"

Dalam kasus 1a), lompat ganda atau lompat tunggal keduanya baik untuk saya. Meskipun lompatan tunggal dapat dianggap "lebih efisien", lompatan ganda memiliki manfaat "mengingatkan" pengguna bahwa lompatan kedua adalah lompatan ke kotak hitam dari sudut pandang "konsumsi perpustakaan" (yaitu pengingat bahwa sumber file yang sedang dinavigasi bukan bagian dari proyek saat ini). Mungkin perilaku ini dapat dibuat dapat dikonfigurasi.

Dalam kasus 3a), 3b) atau 4, saya pasti ingin lompat ganda. Saya pertama kali ingin melihat deklarasi dan hanya setelah ini (dalam kasus yang sangat jarang, seperti debugging) implementasinya. Melompat langsung ke JS melewatkan deklarasi TS menghilangkan semua manfaat dari deklarasi. Jadi, saya pasti ingin melihat deklarasi TS terlebih dahulu.

(menggabungkan balasan ke @weswigham dan @avkonst dari beberapa pos)

Ini mengarah ke definisi pertama, di mana yang pertama cukup sewenang-wenang, dan berdasarkan hal-hal seperti file pesanan dimuat.

Dalam kasus paling umum di mana Anda ingin pergi ke implementasi untuk simbol yang diimpor tertentu, mengapa ada banyak definisi? Apakah ini situasi yang umum?

menghasilkan pemetaan dari .d.ts ke .js (tanpa perantara .ts).

Tidak yakin saya mengerti "tanpa TS perantara". Apakah maksud Anda bahwa meskipun sumber .ts asli tersedia, VSCode akan menavigasi ke .js yang ditranspilasikan? Itu sepertinya ide yang buruk. Jika sumber asli tersedia, maka VSCode harus menavigasi ke sana-- seperti halnya ketika debugger melangkah ke kode transpilasi yang memiliki peta sumber. Yang mengatakan, jika pembuat paket itu jahat atau malas dan tidak memasukkan sumber TS asli di distro npm mereka, maka tampaknya masuk akal bagi VSCode untuk kembali ke JS yang ditranskripsi dan mungkin menampilkan pesan peringatan yang menjelaskan mengapa pengguna melihat kode yang aneh dan tidak dapat dibaca seperti itu dan untuk mendorong pengguna mengomeli pembuat paket untuk memasukkan sumber asli ke dalam paket mereka.

Sungguh, Anda lebih suka pergi ke file deklarasi, dan kemudian berinteraksi lagi untuk pergi ke js terkait? Anda tidak ingin langsung melompat ke js?

Saya tidak berpikir dua langkah akan menambah nilai. Saya pikir jauh lebih baik untuk memiliki UX yang berbeda dan konsisten: gunakan "Go To Type Definition" untuk menavigasi ke definisi tipe, dan gunakan Go To Definition (atau Go To Implementation-- apa pun yang kami pilih untuk menyebutnya) untuk pergi ke aslinya kode sumber atau, sesuai di atas, ke JS yang ditranskripsikan jika sumber asli tidak tersedia.

IMHO, itu jauh lebih membingungkan untuk memiliki perilaku yang berbeda tergantung pada apakah simbol yang dipilih didefinisikan dalam kode Anda sendiri vs di node_modules. Seharusnya tidak masalah. Jika saya ingin melihat tipenya, VSCode harus membawa saya ke tipenya. Jika saya ingin melihat kode implementasi, VSCode harus membawa saya ke sana. Ini terutama benar karena, dalam organisasi besar, apa itu "kode saya" dan apa itu "kode perpustakaan" tidak selalu merupakan garis yang cerah. Jika orang lain memfaktorkan ulang kode menjadi paket internal bersama, saya tidak perlu mengubah cara saya menavigasi ke kode itu.

Saya pertama kali ingin melihat deklarasi dan hanya setelah ini (dalam kasus yang sangat jarang, seperti debugging) implementasinya.

Sepertinya lebih jelas untuk meminta pengembang untuk memilih secara eksplisit (dengan memilih satu item menu atau lainnya) apakah mereka ingin melihat deklarasi tipe atau melihat kode implementasi. Memiliki navigasi yang tidak konsisten tergantung dari mana kode itu berasal tampaknya tidak perlu membingungkan.

> Go To Type Definition tidak bekerja ketika seleksi itu sendiri adalah sebuah tipe.
Saya pikir kalian harus membuka masalah baru tentang itu. Itu hanya kegagalan exepections/bug, imo.

Ya, ini pasti bisa diperbaiki dulu. Saya memasukkannya di sini karena jika solusi pilihan saya ("Go to Definition selalu menavigasi ke implementasi") diadopsi, maka pengguna akan terbiasa menggunakan Go To Type Definition kapan pun mereka ingin melihat .d.ts, jadi itu akan aneh jika melakukan ini pada suatu tipe tidak bertindak secara konsisten dengan cara kerjanya untuk pengidentifikasi non-tipe.

"Ini mengacu pada definisi pertama, di mana yang pertama cukup sewenang-wenang, dan berdasarkan hal-hal seperti file pesanan dimuat."

Saya belum menyebutkan dalam balasan saya bahwa itu harus mengarah ke definisi pertama. Saya mengatakan pada Ctrl+Klik pada simbol itu harus pergi pertama-tama ke definisi (seperti yang berfungsi sekarang) dan hanya pada Ctrl+Klik berikutnya ke implementasi.

"Sepertinya lebih jelas untuk meminta pengembang secara eksplisit memilih (dengan memilih satu item menu atau lainnya) apakah mereka ingin melihat deklarasi tipe atau melihat kode implementasi."

Menu konteks terpisah baik-baik saja dan ide bagus untuk dimiliki. Mereka tidak saling eksklusif dengan perilaku Ctrl+Klik.

Bertanya-tanya mengapa bug kritis ini belum dikerjakan. Itu hanya menjadi semakin menyakitkan ketika adopsi TypeScript meningkat.

Saya tidak ingin mendengar penjelasan teknis, saya ingin tahu mengapa masalah ini bahkan tidak diakui setelah begitu banyak deskripsi pada pengguna yang berbeda.

@zjaml apakah Anda ingin pergi ke file sumber TypeScript atau file sumber JavaScript? File sumber TypeScript didukung. Ini adalah file sumber JavaScript yang saat ini masih terbuka untuk masalah ini.

Terkait tangensial; Saya memiliki monorepo dengan paket umum yang dipublikasikan ke npm. Karena antarmuka publik ini, dist adalah file js + d.ts. Ketika saya bekerja di repo VSCode selalu melompat ke d.ts alih-alih sumbernya. Apakah Anda tahu cara mengatasi ini?

@0x80 Saya yakin masalah ini masih terbuka untuk skenario yang baru saja Anda jelaskan. Satu-satunya cara saya pikir Anda bisa menyiasatinya adalah jika proyek tersebut open source dan Anda mengkompilasinya dari sumber TypeScript. Kemudian Anda dapat mengaktifkan flag --declarationMaps untuk kompiler TypeScript dan IDE yang mendukung peta deklarasi akan menuju ke sumber TypeScript alih-alih file d.ts.

Ini sangat penting. Saya ingin hal sederhana: CTLR+Klik dan arahkan ke node_modules/library/source.js atau file source.ts. Proyek opensource dengan 60 dependensi node_modules dan Anda kembali menggunakan notepad dengan explorer.

Ketika saya mengklik kanan pada sebuah komponen saya melihat: "Go to Definition" dan "Go to Type Definition". Saya pikir "Bagus, ini telah dirancang dengan baik, solusi untuk masalah saya ada di sini!". Kemudian saya mengklik "Go to Definition" dan... mendarat di Type Definition.

Ini sangat penting. Saya ingin hal sederhana: CTLR+Klik dan arahkan ke node_modules/library/source.js atau file source.ts. Proyek opensource dengan 60 dependensi node_modules dan Anda kembali menggunakan notepad dengan explorer.

+1
Kebutuhan yang sama.

Dengan segala hormat, fakta bahwa ini tidak diterapkan sungguh luar biasa. Dasar seperti itu, relatif mudah untuk
membangun fitur yang akan menghemat banyak waktu orang.

Dengan segala hormat, fakta bahwa ini tidak diterapkan sungguh luar biasa. Dasar seperti itu, relatif mudah untuk
membangun fitur yang akan menghemat banyak waktu orang.

+1

Nah, sementara fitur ini belum tersedia, apakah ada solusi yang lebih baik selain mencari seluruh node_modules ? Sungguh merepotkan...
Misalnya, saya pergi ke definisi dan itu membawa saya ke node_modules/@com.abc/sample/lib/core/internal/abc.d.ts ketika yang saya inginkan sebenarnya terletak di node_modules/@com.abc/sample/src/core/internal/abc.ts

@Happin3ss

apakah ada solusi yang lebih baik selain mencari seluruh node_modules ?

Solusi AFAIK saat ini adalah peta deklarasi . Ini adalah peta sumber yang memetakan file .d.ts ke sumber TS yang sesuai. Jika Anda dapat meyakinkan perpustakaan yang Anda andalkan untuk mengimplementasikan peta deklarasi (yang menurut saya secara efektif memerlukan penerbitan .d.ts di dalam paket perpustakaan daripada mengandalkan @types) maka Anda akan dapat secara otomatis melompat dari kode klien Anda ke TS asli (atau bahkan JS jika menggunakan kompiler TS pada JS?) kode sumber.

Apa yang saya lakukan adalah secara bertahap mengajukan PR terhadap dependensi saya yang paling penting (setidaknya yang ditulis dalam TS) untuk membuatnya menambahkan peta deklarasi.

Jelas akan lebih baik jika mengubah perpustakaan tidak diperlukan.

Solusi lain (jika mengubah perpustakaan tidak memungkinkan) bekerja dalam kasus di mana perpustakaan membundel .d.ts di dalam paket tetapi tidak memiliki peta deklarasi. Dalam hal ini, saya akan menggunakan Go To Definition untuk mendapatkan deklarasi tipe, lalu saya akan mengklik tombol Explorer di VSCode untuk menampilkan sidebar folder. Itu biasanya membuat saya sangat dekat dengan folder src untuk paket tersebut, jadi alih-alih harus mencari melalui semua node_modules, saya cukup menelusuri folder yang tepat dan membuka file yang benar. Ini tergantung pada penamaan file yang jelas, dll. dan bukan obat mujarab.

Agar 100% jelas-- Saya ingin melihat solusi yang lebih baik untuk perpustakaan, khususnya. mereka di mana .d.ts ditulis secara terpisah dari paket.

Tidak yakin apakah saya melewatkannya, tetapi akan sangat berguna untuk memahami apa yang terjadi dengan memiliki contoh minimal sumber, deklarasi, dan peta deklarasi. Saya belum pernah melihat Go to Definition, Go to Type Definition, atau Go to Implementations benar-benar pergi ke apa pun selain file .d.ts untuk TS yang ditranspilasikan. Saya baru saja mencoba membuat contoh sederhana , dan tidak berhasil; Saya tidak bisa mendapatkan Kode VS untuk membuka apa pun selain file .d.ts , meskipun .d.ts.map ada di sebelahnya. Saya juga menemukan orang lain dengan masalah yang

Dapat dimengerti bahwa mendukung pengetikan eksternal seperti @types akan sulit, tetapi apa yang dikatakan bahwa bahkan "jalur bahagia" tidak dapat dibuat berfungsi?

Ada banyak perpustakaan yang menghasilkan file deklarasi tetapi bukan peta deklarasi, dan tidak jelas argumen apa yang akan digunakan untuk mengaktifkannya. Opsi ini telah ditambahkan tanpa penjelasan yang jelas, setidaknya satu yang dapat saya temukan.

Ya, saya mengonfirmasi bahwa peta deklarasi tidak menyelesaikan masalah. Proyek saya telah mendapatkan peta deklarasi tetapi vscode tidak menavigasi di luar file .d.ts.

Pasti akan sangat bagus jika ini terjadi.

jika ada "gajah di ruangan" masalah untuk ms vscode devs, ini dia.

Adakah pembaruan untuk yang satu ini?
Saya baru saja memutuskan untuk membuat langkah besar: pindah dari JS ke TS. Saya pikir - "apa yang saya lakukan salah?" tetapi sebenarnya, itu adalah perilaku VSCode yang tidak terduga

Adakah pembaruan untuk yang satu ini?
Saya baru saja memutuskan untuk membuat langkah besar: pindah dari JS ke TS. Saya pikir - "apa yang saya lakukan salah?" tetapi sebenarnya, itu adalah perilaku VSCode yang tidak terduga

Itu adalah sejarah panjang sejak perilaku ini dimunculkan. Yah, tidak ada yang terjadi di sini. Tidak ada rencana sejauh ini.
Bagi saya, saya tetap menggunakan vscode sebagai semacam editor apa adanya, dan produk Intellij (IDEA) untuk bahan pengkodean saya bahkan saya tidak begitu menyukainya.

Dibuka selama 5 tahun, semoga diperbaiki pada 2025

Saya telah membuat tes yang gagal di #39426 tetapi saya tidak tahu bagaimana menerapkannya

Hanya komentar menyedihkan lainnya dari ts dev yang melalui neraka setiap hari untuk menemukan definisi

Ini gila... Saya pikir saya hanya seorang TS noob, tetapi sekarang saya melihat bahwa perilaku yang saya dapatkan sebenarnya "standar"???? Sangat membuat frustrasi, setiap IDE/bahasa lain yang saya gunakan telah menerapkan ini pada rilis awal ... :( Saya suka kode VS tapi jujur ​​ini bisa menjadi pemecah kesepakatan

Adakah yang bisa menjelaskan mengapa fitur go to definition/implementation di VSCode dengan ekstensi Python untuk, ya, bahasa Python berfungsi lebih baik (setidaknya berfungsi) kemudian untuk JS yang memiliki solusi bawaan bawaan?

Jadi apa yang terjadi?
Saya menggunakan scss.d.ts untuk modul css dan tidak dapat melompat ke scss.

Juga saat membuat .js dan d.ts sederhana, saya tidak bisa langsung melompat ke js

mengapa tidak menggunakan webstorm?
itu bisa menyelesaikan masalah ini!!!
versi saya 2020.1

mengapa tidak menggunakan webstorm?
itu bisa menyelesaikan masalah ini!!!
versi saya 2020.1

Karena itu bukan solusi open-source dan tidak gratis

Tolong perbaiki ini.

Sangat jelas, bahwa masalah ini dapat diperbaiki hanya jika beberapa manajer dari Microsoft mengambil alih, masalah ini harus dikelola dan dikoordinasikan, seorang manajer mengembangkan alur kerja dan menugaskan pekerjaan ke pembuat kode. ☝
Masalah ini harus dikirim ke manajemen untuk mengambil alih dan mereka memutuskan bagaimana hal itu akan dilaksanakan.
Jadi jika di sini ada seseorang yang kompeten dari Microsoft, dia bisa mencobanya. 😊