Vscode: Tambahkan dukungan untuk membuka beberapa folder proyek di jendela yang sama

setuju, tapi mungkin ini adalah solusi yang mengoptimalkan untuk memori

+1

Saya tidak yakin saya mengerti pertanyaannya; ini adalah editor kode yang ringan, bukan IDE ... mengapa Anda perlu membuka beberapa folder "proyek" yang tidak hierarkis (di mana Anda dapat mengatur jalur kerja ke induk bersama)?

Jika Anda sedang mengerjakan modul yang disimpan secara terpisah pada disk yang entah bagaimana berinteraksi satu sama lain sejauh itu, maka mereka terlalu erat untuk memulai dengan ... apakah proyek Anda saudara? Jika demikian, buka saja folder induk, atau folder induk / induk ... di mana pun root "solusi" Anda berada.

Nah, jika Anda memiliki sejumlah modul (yang semuanya ada di repositori gitnya sendiri) yang tidak bergantung satu sama lain tetapi Anda memiliki satu repositori yang menggunakan dependensi tersebut, masuk akal untuk dapat membuka folder independen ini dan membuat perubahan yang akan direfleksikan sehingga Anda dapat mengujinya secara lokal. Itu masih akan menjadi editor kode yang ringan tetapi lebih berguna imho!

Masalah utama dengan menetapkan proyek sebagai induk adalah integrasi git hilang, ada kasus penggunaan valid lainnya selain memiliki induk bersama juga.

@stoffeastrom terdengar seperti kasus penggunaan untuk submodul; Saya tidak yakin bagaimana proyek Anda akan mereferensikan yang lain, kecuali Anda aliasing dengan beberapa mekanisme, seperti npm menghubungkan, dll. Masalah ini adalah apa yang sebagian besar ingin dipecahkan oleh manajer paket. Jika modul-modul tersebut digabungkan dengan erat, maka mereka sebenarnya bukan modul yang terisolasi. Anda tidak akan dapat melakukan perubahan dengan andal untuk mendukung satu proyek tanpa mengkhawatirkan perubahan tersebut akan berdampak pada konsumen lain di masa mendatang. Bahkan dengan submodul, mereka hanya-baca secara default karena alasan itu.

Bagaimanapun, apa yang baru saja disebutkan

Jika saya menggunakan integrasi git untuk melakukan, apakah saya melakukan proyek A atau proyek B?
Jika saya melakukan refactor nama kelas di TypeScript, haruskah itu refactor di proyek A atau proyek B, atau keduanya? Bagaimana jika nama kelas yang sama ada di kedua proyek dengan arti yang berbeda? Bagaimana jika yang satu secara longgar mereferensikan yang lain?

Ini hanyalah beberapa contoh bagaimana sesuatu yang tampaknya sederhana bisa menjadi sangat rumit, dengan sangat cepat. Saya pikir itu akan jauh lebih membingungkan dan, terus terang, kurang berguna daripada tab alt-tab / cmd + antara beberapa contoh VSCode terpisah, masing-masing dengan senang hati mengelola jalur kerja terisolasi mereka sendiri tanpa semua upaya ekstra dan masalah kasus tepi.

Saya tidak mengatakan bahwa itu tidak dapat diselesaikan, tetapi saya tidak begitu mengerti mengapa beralih di antara banyak jendela dan / atau contoh adalah suatu masalah. Mungkin aku melewatkan sesuatu ...

Sublime, Atom, Webstorm - mereka juga editor kode "ringan" (kecuali mungkin Webstorm) dan memungkinkan pembukaan beberapa folder root dari lokasi berbeda. Editor ini mungkin 99% dari apa yang digunakan pengembang web.
Kode dapat bersaing dengan mereka dengan dukungan Typecript yang jauh lebih baik (dan ini akan sangat populer mengingat Angular 2 akan segera hadir) tetapi hanya jika itu akan memberi pengembang apa yang mereka gunakan sekarang sebagai fungsi dasar.

+1

+1

Sebagai pengembang Go, saya menemukan fitur ini sangat berguna di Sublime atau IntelliJ Idea. Misalnya, proyek kecil saya mengimpor kode dari perpustakaan inti Go atau mungkin mengimpor beberapa perpustakaan pihak ketiga. Jadi saya harus dapat dengan cepat menavigasi ke sana dan membaca kode itu.

+1. Solusi layanan mikro multi-git repo sangat menyakitkan di VS Code saat ini, berpikir untuk mencari IDE berkemampuan Typecript lainnya.

Kami pasti membutuhkan semacam 'solusi'. Saya seorang pengembang asli, dan ini hampir selalu melibatkan pembuatan satu set libs / dll dan kemudian merujuknya dari beberapa proyek aplikasi host.
Setelah kami memiliki banyak proyek, kami juga memerlukan 'proyek startup' untuk saat kami menekan 'jalankan'.

Saya juga menginginkan dukungan untuk proyek dan beberapa akar git. Kode yang sering saya gunakan ditemukan di beberapa repo git dan tidak dapat beralih di antara mereka tanpa menutup ruang kerja saya saat ini dan membuka yang lain hanya untuk membalik dan menutup yang sebelumnya untuk membuka yang sebelumnya sangat melelahkan. Jika saya menambahkan folder induk tempat semua repo saya disimpan maka saya mendapatkan kemampuan untuk menavigasi dan mencari di antara file saya tetapi saya kehilangan integrasi git. Benar-benar mengecewakan.

Garis antara "editor teks" dan "IDE" cukup kabur dan saya tidak terlalu peduli dengan label VS Code. Yang saya pedulikan adalah apa yang dapat dilakukan sebuah alat dan betapa mudahnya menggunakannya. Saya pikir menambahkan dukungan proyek akan mengurangi banyak gesekan bagi orang-orang seperti saya.

Saya juga ingin melihat integrasi git berfungsi ketika ruang kerja Anda berisi banyak repo, tetapi saya hanya ingin memastikan orang-orang seperti @ Loren-Johnson menyadari bahwa mereka dapat membuka beberapa jendela kode vs secara bersamaan.

Ini sebagai tanggapan untuk: "tidak dapat beralih di antara mereka tanpa menutup ruang kerja saya saat ini"

Maksud Anda # 2686 adalah duplikat dari ini?

Maaf, saya salah membaca deskripsinya dan membuka kembali yang ini.

+1

Apakah ada kemajuan dalam masalah ini, atau setidaknya beberapa pernyataan jika ini akan diterapkan? Apakah ada beberapa keputusan tingkat rendah dalam kode yang mencegah banyak akar dalam satu proyek?

Ini adalah satu-satunya alasan saya tidak pindah dari ST3 ke VSCode.

+1

+1

+1

+1 ini akan sangat membantu. Saran untuk menggunakan submodul git sangat merepotkan. Ingin sekali memiliki fitur ini.

Pendekatan ringan awal akan menjadi sesuatu yang mirip dengan apa yang dilakukan ekstensi git-project-manager . Pendekatannya pada dasarnya bisa dengan mengganti konteks / root untuk apa yang dilihat git sebagai perubahan, tetapi tanpa mengubah konteks / root untuk apa yang dilihat oleh browser file. Ekstensi ini bekerja dengan sempurna, hanya membutuhkan integrasi yang lebih erat untuk mempercepat peralihan.

+1

+1 - Saya mulai menggunakan cara menggunakan submodul git, tetapi rasanya lebih seperti retasan daripada solusi sebenarnya.

+1

+1

Saya menggunakan ekstensi git-project-manager untuk beralih antar folder, tetapi sangat ingin memiliki opsi untuk membuka beberapa folder sekaligus.
+1

Hanya ingin mengatakan bahwa pemilik ekstensi Manajer Proyek sedang menunggu Masalah ini juga.

Berkenaan dengan beberapa komentar (di atas), saya hanya ingin mengatakan bahwa kita semua berbeda, kita semua memiliki cara khusus untuk melaksanakan pekerjaan kita pada proyek khusus kita. Fakta itu membuat UX lebih penting dari sebelumnya.

Kita semua tahu bahwa "Open folder ..." hanyalah langkah awal untuk memiliki manajemen proyek dalam vscode dengan hal-hal seperti "Open project ...", dan seterusnya. Sama seperti semua editor lain di luar sana, terutama SublimeText (dari mana saya berasal).

Bagi saya, masalah ini adalah peningkatan UX produk. Dan kita semua tahu bahwa UX adalah rajanya.

Saya hampir merasa hal semacam ini harus sesuai hukum, dan oleh karena itu tag "permintaan fitur" seharusnya menjadi "pengingat fitur".

Masalah ini harus menjadi prioritas utama di atas masalah lain di vscode. Bukan hanya karena UX adalah raja, tetapi karena saya tidak mengalami masalah lain dengan vscode saat ini selain yang ini ... secara teknis.

Saya awalnya menjelajah untuk meminta agar Microsoft mengambil alih ekstensi seperti proyek ini dan mengintegrasikan ke dalam VSCode secara langsung, dan meningkatkan UX-nya, misalnya dengan menambahkan "Proyek ..." ke menu.

Terima kasih,
+1

+1

Kasus penggunaan saya untuk fitur ini dijelaskan di sini: # 9515. (Itu ditutup sebagai duplikat dari masalah ini.)

Saya harap fitur ini terjadi!

+1

@ poidl, @ mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius & @brusbilis :
Beberapa waktu yang lalu GitHub memperkenalkan fitur "Tambahkan reaksi Anda" yang menarik (lihat smiley di setiap sudut kanan atas komentar atau masalah itu sendiri?).
Mereka melayani tujuan memberi tahu tim VSCode tentang minat Anda tetapi mencegah komentar +1 . Ini juga mencegah orang lain yang berlangganan masalah atau MR tertentu untuk mendapatkan pemberitahuan dan karenanya menghemat waktu yang berharga. Bonus lainnya adalah bahwa masalah / MR dapat diurutkan berdasarkan most reaction yang membuatnya langsung terlihat oleh tim VSCode apa yang relevan dengan pengguna. Selain itu, bahkan ada Uservoice for VSCode .

Komentar ini sendiri adalah meta dan karena itu juga tidak berarti. Saya minta maaf tapi saya pikir itu perlu untuk tujuan pendidikan. Setiap balasan langsung untuk komentar ini (= lebih banyak meta) akan mengakibatkan saya memblokir pengguna tersebut.
Mari berolahraga dengan hanya bereaksi terhadap komentar ini dengan menggunakan fitur reaction !

Untuk jawaban @poidl s: Kalau begitu jangan balas sama sekali!

Saya tidak melihat smiley itu. Setidaknya di perangkat seluler. Selamat memblokir!

@poidl ya fitur reaksi tidak tersedia di situs seluler GitHub sayangnya (bersama dengan banyak fitur lainnya). Anda bisa mendapatkannya di perangkat seluler dengan menekan tombol "Versi desktop" di bagian bawah situs.

Namun saran @ dj-hedgehog tepat, reaksi GitHub memungkinkan kami mengukur minat komunitas pada sesuatu yang lebih efektif daripada jumlah komentar. Selain itu, kami berencana menghentikan Suara Pengguna sehingga masalah dan reaksi GitHub adalah sumber kebenaran kami untuk permintaan fitur.

+1

+1

Solusi saya untuk masalah ini: buat tautan simbolis ke root proyek saya.
Jadi jika saya memiliki:
project/modules/gitmodule

Saya masuk ke folder gitmodule saya dan melakukan:
ln -s ../../../project .project

Sekarang saya dapat membuka folder gitmodule saya di vscode dan masih memiliki akses ke folder proyek induk.
Saya menggunakan titik di nama file sehingga diurutkan ke atas daftar saya di explorer.
Jelas, saya lebih suka tidak melakukan ini, tetapi saya pikir ini mungkin berguna bagi sebagian dari Anda.

Hampir lupa: jangan lupa untuk menambahkan symbolic link ke .gitignore Anda

+1

Ini adalah fitur yang sangat penting untuk editor teks modern. Tolong selesaikan "masalah" itu.
Untuk sementara, saya harus menyalin dan menempel semua direktori yang digunakan ke folder kerja saya yang sebenarnya dan ini di Sublime Text sangat sepele.

Proyek> Tambahkan Folder ke Proyek di Sublime Text menambah jalur baru ke struktur Json.

Lihat di bawah:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

Saat bekerja dengan chef misalnya, sering kali melihat struktur folder seperti:

└── cookbooks
    ├── cookbook1
    ├── cookbook2
    ├── cookbook3
    └── cookbook4

Dimana buku masak (buku masak1 misalnya) di bawah folder root (buku masak) adalah repo git independen. Ini sangat umum. Sekarang Anda harus mengerjakan buku masak4 tetapi itu termasuk buku masak2 dan buku masak3. Anda akan sering perlu membuka ketiganya, baik untuk sekadar merujuk ke kode atau untuk benar-benar mengedit atau memfaktor ulang kode di ketiganya.

2 opsi normal (bukan peretasan symlink) menghadirkan masalah yang tidak diinginkan pengembang:

1. Seperti yang disebutkan di atas berkali-kali, Anda sekarang harus membuka banyak jendela (tidak bagus)
2. Jika Anda membuka buku masak sebagai root untuk melihat ketiganya, Anda kehilangan integrasi git karena folder buku masak tidak memiliki repo (juga tidak bagus)

+1, pengguna Eclipse IDE di sini yang memiliki fitur kontrol 'ruang kerja' penuh.

Kode Visual Studio bukanlah IDE. Ini adalah editor lintas platform ringan, seperti Atom atau Sublime. Eclipse, Xcode, Visual Studio, et. semuanya adalah raksasa dibandingkan.

Maaf, saya tidak yakin apakah Anda memperdebatkan atau untuk fitur ini ... Atom, Sublime, VIM, Emacs memungkinkan Anda membuka beberapa folder sekaligus. Ringan atau tidak itu fitur yang bagus, IntelliJ IDEA - sebuah IDE - misalnya tidak memungkinkan Anda untuk tetap membuka banyak proyek.

@dmccaffery fitur yang diminta di sini bukan hanya fitur IDE, Fitur yang diminta adalah umum untuk semua _editors_ yang Anda katakan Visual Studio Code adalah _like_.

Atom, Sublime, dan editor ringan lainnya semuanya dapat membuka banyak folder.

Saya, secara pribadi, tidak peduli apakah fitur ini ada di produk atau tidak - saya mengerti mengapa beberapa orang menginginkannya, tetapi saya akan menunjukkan bahwa itu membuat semuanya sedikit lebih berbelit-belit. Misalnya: saat mencari menggunakan ekspresi regex - ruang kerja mana yang saya cari? satu? semua?

Bagaimana jika saya memiliki satu folder yang berisi proyek nodejs di mana lebar tab saya biasanya 2 spasi, dan satu folder adalah proyek dotnet dengan lebar tab saya 4 spasi? Kode perlu mengetahui pengaturan ruang kerja untuk setiap folder dan mempertahankan konteks di seluruh.

Ini hanyalah beberapa contoh di mana beberapa ruang kerja dalam satu instance bisa menjadi sulit. Yang saya katakan adalah, fitur ini jauh lebih terlibat daripada hanya memiliki banyak jalur yang muncul di penjelajah.

@dmccfery tidak lebih berbelit-belit daripada luhur dan atom. Ini semua harus dapat dikonfigurasi, bahkan lebar tab per ruang kerja. Pencarian di atom dan sublime dapat dilakukan di file saat ini saja, di ruang kerja ini, dll ... terserah Anda.

Inilah fakta, suka atau tidak dan itu tidak ada hubungannya dengan apa yang Anda atau saya inginkan. Jika perangkat lunak lain yang serupa dengan harga yang sama (gratis dalam hal ini) memiliki fitur yang lebih baik atau lebih banyak, dan pengembang mengabaikan fakta ini, .. perangkat lunak ini akan tertinggal.

Saya sendiri tidak ingin melihat hal itu terjadi pada editor ini. Saya pikir editor ini memiliki potensi yang sangat bagus dan dapat tetap relevan untuk beberapa waktu _ jika pengembang mendengarkan keinginan / kebutuhan basis penggunanya.

Lagi; Saya tidak mendukung atau menentang - perlu diingat bahwa ini adalah editor yang sangat baru dengan konteks yang jauh lebih di luar kotak daripada pesaingnya - berikan waktu.

Bahkan dalam contoh Anda dengan chef dan integrasi git - bagaimana Anda mempertahankan konteks tentang repo mana yang Anda janjikan? UI saat ini perlu beradaptasi dengan peralihan konteks konstan - sama untuk OmniSharp, yang menggunakan server dan roslyn untuk menyediakan penyorotan sintaks, dll. Untuk proyek CoreCLR. Implikasinya jauh jangkauannya dan perlu dipikirkan dengan sangat matang.

Tidak ada argumen tentang gagasan bahwa fitur perlu direncanakan dan dipikirkan dengan baik. Itu adalah pemberian saya pikir. Saya pikir semua pengguna akan senang jika jawaban di sini adalah "itu ada di peta jalan" atau "kami bekerja untuk mencapai tujuan itu". Yang ingin saya katakan adalah bahwa "tidak" mungkin akan membunuh beberapa pengguna dalam semalam.

Mengenai peralihan konteks dan repo git di chef, ya setuju ... ini semua benar dan semua sudah dicapai di editor open source lainnya. Anda tahu hal hebat tentang open source ,,, itu terbuka! Lihatlah kodenya, dapatkan ide, bahkan gunakan sebagian (pastikan untuk menyertakan lisensi sesuai kebutuhan). Itulah salah satu hal hebat tentang fosil (perangkat lunak sumber terbuka gratis), kolaborasi, dan berbagi pengetahuan. Karena editor ini sudah menggunakan kode atom ... Saya pikir ini juga akan diberikan.

Saya menemukan ini disebutkan di https://github.com/Microsoft/vscode/wiki/Roadmap

VS Code adalah produk muda dan masih ada fitur dan pengalaman yang Anda minta dan yang ingin kami sampaikan masih kurang.
....
....

• Beberapa folder di dalam satu ruang kerja

Saya rasa tidak ada yang mengatakan bahwa fitur ini sederhana (karena kita semua adalah pengembang, kita dapat mengetahui apa yang perlu diubah) dan saya, orang-orang yang mengomentari tiket ini hanya ingin menunjukkan betapa pentingnya, bagaimana seharusnya prioritasnya, dan bagaimana membandingkan fitur ini vs beberapa saudara VS Code (Atom, Sublime misalnya).

Tetapi karena ini sudah ada di peta jalan (siapa pun dapat memastikan bahwa halaman wiki masih benar) kita harus membahas tentang bagaimana menerapkan ini daripada hanya mengatakan bagaimana kita membutuhkan dan betapa pentingnya itu (seperti sekali lagi, saya kira tim inti VS Code sudah tahu bagaimana kami membutuhkannya dan betapa pentingnya fitur ini).

Saya tidak terbiasa dengan kode sumber VS Code, dapatkah seseorang memberi tahu saya jika saya ingin menerapkan fitur ini, di mana saya harus melihat dulu? Pada langkah pertama saya hanya ingin membuka banyak folder dan menampilkannya di bilah kiri.

@nvcnvn tidak

Saya ingat ketika Atom keluar, dengan batasan _ satu folder_ yang sama. Keluhannya juga sama, khususnya perbandingan dengan Sublime. Kemudian, ketika _multiple folder_ support dirilis, beberapa paket (ekstensi) rusak, karena API baru. Yang lainnya tidak rusak tetapi juga tidak mendukungnya. Butuh beberapa waktu hingga menjadi _stable_ di seluruh ekosistem.

Seperti yang dikatakan @Tyriar , akan ada beberapa UX dan dampak API ekstensi, dan mungkin akan menjadi rilis _Insider_ yang sibuk untuk pengembang inti dan ekstensi, untuk mengadopsi API baru.

Jadi apa sebenarnya yang diperdebatkan di sini?
Maksud saya yang saya lihat adalah "jangan melakukan perbaikan karena itu bisa merusak sesuatu" ...

Petunjuk:
SEMUA PENINGKATAN KODE DAPAT MENGHANCURKAN SESUATU!

Itulah inti dari debugging, refactoring, pre-release (alpha, beta, rc, dll ...)
Ayolah, serius? Saya tidak pernah bertemu dengan programmer serius yang takut memperbaiki kode karena dapat merusak sesuatu. Berhati-hatilah ya, luangkan waktumu dan berhati-hatilah ya, tapi jangan pernah berkata "tidak, itu bisa merusak barang" lol

@ddreggors Saya tidak berdebat, saya hanya menyatakan beberapa informasi tentang masalah ini. Saya mengatakan apa yang saya katakan sehingga @nvcnvn tidak berusaha membangun PR untuk ini karena ini perlu dilakukan oleh tim karena daftar pemangku kepentingan.

Seperti yang ditunjukkan oleh @nvcnvn , masalah ini ada di peta jalan yang berarti tim akan segera memeriksanya. Kami adalah tim yang relatif kecil dengan banyak hal yang harus dibahas sehingga beberapa hal perlu ditunda.

@Tyriar Understood, saya terus melihat komentar-komentar ini dari beberapa orang yang sepertinya menyarankan yang terbaik untuk tidak menambahkan fitur ini karena satu dan lain alasan. Yang terburuk adalah karena fakta bahwa kode bukanlah IDE, ketika orang lain dengan jelas membandingkan editor lain bukan IDE. Itu membuat saya ingin sampai ke akar ketakutan akan perubahan ini untuk melewatinya jika memungkinkan.

Saya dapat memahami kekhawatiran bahwa PR tidak lengkap, namun ini bisa menjadi awal yang baik ... menggabungkan perubahan itu ke cabang dan menggunakannya sebagai basis. Gunakan itu untuk melihat kerusakan dan memperbaikinya.

@ddreggors akan sia-sia upaya bagi siapa pun untuk menyentuhnya sebelum dibahas dalam salah satu rapat UX kami

Cukup adil, Anda akan tahu yang terbaik pada akhirnya. Senang mengetahui bahwa ini sedang dibahas. :-)

Terima kasih atas usahanya, dan apa yang tampak seperti awal dari editor yang sangat baik.

Tampaknya juga merupakan upaya yang sia-sia untuk menyarankan topik ini untuk rapat UX Anda :–)

Saya sementara beralih kembali ke Atom karena telah menjadi jauh lebih stabil pada rilis 1.9. Dulu crash ketika file besar apa pun dibuka dan itulah alasan utama saat mulai memeriksa VSCode di beberapa titik. Benar-benar berharap untuk melihat banyak proyek dalam satu jendela - sepertinya saya tidak punya apa-apa selain mengikuti utas ini sampai saat itu.

Mengapa orang Microsoft tidak berkonsentrasi pada ini?

+1

+1

Saya sangat menyukai VS Code. Ini menjadi editor utama saya, tetapi kesulitan bekerja di lebih dari 2 proyek sekaligus menjadi membingungkan. Ada pukulan ganda pada dua masalah terbuka ini: yang satu ini, dan mengonfigurasi informasi bilah judul .

Salah satu dari fitur ini akan menyelesaikan masalah (meskipun idealnya, saya suka keduanya!). Saya tidak keberatan meletakkan semua yang saya kerjakan di bawah satu folder dan membukanya - tetapi kemudian integrasi git tidak berfungsi, dan tidak ada cara mudah untuk mencari hanya dalam satu proyek atau mengatur hasil berdasarkan proyek.

Saya tidak keberatan membuka setiap proyek di jendela VS Code fisik yang berbeda dan membiarkan OS saya mengelola instance - tetapi karena bilah judul menunjukkan nama file yang terbuka terlebih dahulu, daripada beberapa folder root / pengidentifikasi proyek, tidak mungkin untuk beralih ke proyek terbuka spesifik lainnya tanpa membuka dan melihat setiap instance aktif. Itu membuat sesuatu yang seharusnya mudah menjadi gangguan konstan.

Mohon - adakah cara menambahkan salah satu dari dua fitur ini dapat menjadi prioritas? Saya telah mencoba semua yang dapat saya pikirkan untuk mengatasinya, saya bahkan menghabiskan satu jam mencari beberapa alternatif bilah tugas Windows yang memungkinkan saya memilih jendela dari daftar yang dapat menampilkan lebih banyak teks di bilah judul tetapi saya tidak dapat menemukannya apa pun.

Jika ada yang punya saran tentang bagaimana mengelola beberapa proyek VS Code terbuka secara efektif, saya akan senang mendengarnya.

Hal penting yang berfungsi dengan baik di Atom adalah plugin, seperti eslint, harus tetap berfungsi di level proyek. Jadi jika Proyek A memiliki aturan eslint sendiri, Proyek B tidak akan terpengaruh oleh aturan tersebut dan sebaliknya. Tidak sabar untuk memiliki UX seperti itu dalam Kode. Ini jelas salah satu, jika bukan hambatan adopsi terbesar saat ini.

Inilah satu-satunya hal yang menahan saya untuk mengadopsinya.

Saya tahu bahwa Anda mungkin memiliki banyak masalah lain untuk diperbaiki dan fitur lain untuk diterapkan, tetapi, setidaknya beberapa dukungan dasar untuk memulai akan luar biasa.

Terima kasih atas kerja kerasnya di VSCode!

+1

Sampai fitur ini diimplementasikan (jika ada), saya sarankan Anda menambahkan kemampuan untuk mengkonfigurasi bilah judul untuk menampilkan nama proyek sebelum nama file. Dengan cara ini setidaknya mungkin untuk membedakan antara jendela vscode berbeda yang terbuka untuk proyek yang berbeda. Lihat # 1723 .

Ini adalah show stopper untuk saya juga. Saya melihat beberapa pengembang bertanya-tanya mengapa Anda memiliki banyak repo git sekaligus. Ini terjadi dengan hampir semua bahasa yang menggunakan modul bagian ketiga. Lihat saja php - composer, js - bower, node - npm, golang dll. Sangat umum untuk memulai sebuah proyek yang menggunakan beberapa modul Anda dan Anda ingin mengedit dan mengkomit perubahan dalam lingkup proyek.

Apakah setidaknya ada dukungan untuk mengenali .vscode/settings.json dalam direktori bertingkat. Saat mengerjakan satu proyek, mungkin ada subpohon dengan set pengaturan berbeda dan yang datang dari repositori (git) berbeda. misalnya

root/
    server/
        .vscode/
            settings.json // <== affects all files in the server/ directory
        code/
            tsconfig.json
            foo.ts
    client/
        .vscode/
            settings.json // <== affects all files in the client/ directory
        code/
            tsconfig.json
            foo.ts
    .vscode/
        settings.json // for any file not in server/ or client/

Saya berharap vscode akan mengambil (dan mungkin menggabungkan) pengaturan direktori induk terdekat seperti banyak file konfigurasi ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'package.json` ....).

Jadi, ketika saya membuka /root , maka file apa pun di root/server/ harus ditangani seolah-olah saya akan membuka root/server/ secara langsung. Solusi paling sederhana adalah berhenti mencari pengaturan di direktori induk satu file .vscode/settings.json ditemukan.

Ini sangat dibutuhkan.

+1. Dealbreaker untuk saya.

Ini sangat dibutuhkan. +1

ada solusi untuk menumpuk folder di bawah ruang kerja vscode. hanya untuk membuat tautan simbol ke folder ruang kerja, seperti ini mklink /d link target

Saya setuju - menurut saya permintaan ini adalah persyaratan yang pasti.
Anda tidak selalu memiliki proyek dalam satu folder - Anda dapat memiliki folder tambahan dan saudara kandung dan tidak memiliki fitur ini adalah pemecah masalah nyata untuk saya sekarang - itulah mengapa saya harus menggunakan sublim.
Tolong tambahkan!

Di sisi kiri Anda menunjukkan folder tempat Anda berada sebagai proyek. Ini bisa berfungsi jika Anda memilikinya di mana Anda dapat melihat setiap area folder (proyek) terbuka di sana. Anda dapat memperluas dan menciutkannya seperti yang Anda lakukan sekarang (tetapi untuk beberapa area folder).

Editor yang luar biasa jika saja saya bisa beralih di antara dua proyek. Dealbreaker nyata.

Halo semuanya, Saya merekomendasikan ekstensi Manajer Proyek Git jika Anda melakukan banyak peralihan antar proyek untuk sementara. Ini memindai direktori untuk direktori yang berisi folder .git dan memungkinkan peralihan cepat ke sana, saya telah menggunakannya selama beberapa minggu dan tentu saja membuatnya lebih mudah.

Ketika saya beralih proyek, saya pergi:

1. ctrl + alt + p
2. Jenis awal proyek, mis. "vsc" untuk vscode
3. memasukkan

Atau jika saya ingin membuka proyek di jendela lain, saya menekan ctrl + shift + n sebelumnya. Anda dapat mengonfigurasi ekstensi untuk selalu terbuka di jendela baru jika itu juga milik Anda.

Ini adalah cuplikan layar tentang bagaimana Anda dapat dengan mudah memiliki banyak proyek.

@ soljohnston777 masalahnya adalah bahwa integrasi git (atau jenis konfigurasi kode VS lainnya) tidak didukung pada tingkat folder.

masalahnya adalah integrasi git (atau jenis konfigurasi kode VS lainnya) tidak didukung pada level folder.

Benarkah? Apakah VSCode mengulangi kesalahan yang dibuat gerhana dalam hal konsep ruang kerja? Itu akan mengejutkan, mengetahui bahwa beberapa anggota tim VSCode telah menjadi bagian dari tim inti gerhana ....

Apakah VSCode mengulangi kesalahan yang dibuat gerhana ketika datang ke konsep ruang kerja

Saya tidak dapat berbicara dengan filosofi arsitek di sini, tetapi fakta ini (konfigurasi itu per-instance dan bukan per folder) adalah seluruh alasan untuk masalah dan diskusi ini.

Anda dapat menggunakan jendela VScode terpisah untuk proyek. Mengapa tidak menerapkannya seperti itu di dalam VSCode? (Jendela terpisah per tombol proyek sisi - cukup rujuk di dalam). Ini akan menghemat kerumitan pengkodean di dalam program, namun proyek muncul di dalamnya, dan membuatnya mudah untuk diintegrasikan dan dikembangkan.

Git dapat ditempatkan secara independen untuk setiap area folder untuk beberapa proyek ... Saya merasa git membingungkan dengan VSCode, jadi saya cenderung hanya melakukan baris perintah (yang sepertinya Anda harus dapat melakukannya di VSCode).

Memiliki folder induk yang menampung subfolder yang merupakan repositori git independen sangat membantu ketika semuanya termasuk dalam proyek yang sama. Ingin melihat ini tersedia, setidaknya dengan flag konfigurasi opsional di pengaturan.

Saya juga ingin mengungkapkan minat kuat saya untuk memiliki dukungan git untuk banyak repo git.

+1. Ini adalah fitur utama yang mencegah saya mengadopsi VSCode sebagai editor utama saya.

+1

+1 - terutama untuk orang yang bekerja dengan layanan mikro / basis kode banyak repo, ini adalah kuncinya. (Kunci: tidak membuka semuanya sekaligus, tetapi beralih di antara mereka, dan meminta editor mengingat file mana yang dibuka dan di ruang kerja mana.)

+1
Penyiapan kami adalah seperti kode inti di repo GIT, beberapa kode regional di repo lain, dan kode khusus proyek di repo lain jadi saat Anda mengerjakan proyek, Anda perlu membuat kode dari ketiga (atau lebih) repo. Tidak dapat memiliki "proyek" dengan pengaturan spesifiknya sendiri dan kemampuan untuk menambahkan banyak folder dari berbagai sumber, itu adalah raja pemblokir.

@danechitoaie bagaimana Anda tahu bahwa perubahan yang Anda buat pada repo inti Anda tidak merusak orang lain yang mengandalkannya untuk wilayah atau basis kode proyek yang berbeda? Sepertinya cara yang berbahaya untuk bekerja; harus ada manajemen rilis terpisah menggunakan beberapa jenis sistem manajemen paket atau sejenisnya.

Tidak memperdebatkan beberapa implementasi ruang kerja, tetapi sistem proyek lengkap menambahkan cukup banyak kerumitan.

Setuju, itu benar dan mereka seharusnya / dapat melakukan banyak hal dengan lebih baik tetapi ... itu di luar kendali "pengguna fana" kita atau kemampuan untuk membuat keputusan ...

Dimengerti. Saya senang jika hal semacam itu terjadi.

Bagaimana dengan ini?

Bagi saya tombol sakelar sederhana seperti itu saja tidak cukup. Jika kita perlu sesederhana itu, buka 2 instance (ctrl shift N) lalu gunakan hotkey OS Anda untuk beralih antar windows / workspaces yang hampir sama.
Saya suka memiliki sesuatu yang memudahkan untuk membandingkan file, struktur proyek, sesuatu yang membantu saya dengan cepat melakukan perubahan kecil dan membangun dan menyimpan semua perbedaan di layar yang sama, dapat mengembalikan perubahan untuk semua proyek yang saya kerjakan.

+1

+1

Jenis solusi untuk macOS Sierra.

Satu tab per proyek di dalam satu jendela dengan menyetel Prefer tabs when opening documents menjadi Always di setelan dok. Tapi itu akan mempengaruhi perilaku aplikasi lain juga ..

+1

Ini menjadi pembunuh bagiku. Saya suka program ini, tetapi saya tidak suka program yang hanya memiliki satu jendela ...

Sejujurnya, saya harus berhenti menggunakan Code karena sesuka saya, itu menjadi terlalu rumit untuk berpindah jendela.

Jika ini diperbaiki di masa mendatang, saya akan mencobanya lagi, sampai saat itu ini adalah penghenti acara untuk saya dan setiap orang yang pernah saya uji.

+1

+1

Harap lebih suka: +1: reaksi pada komentar masalah asli karena itu membantu kami dalam memprioritaskan dan tidak mengirim pemberitahuan kepada semua orang yang mendengarkan masalah untuk pembaruan.

+1

Saya saat ini menggunakan Sublime, dan mencoba Kode. Terlihat dan terasa bagus, tetapi integrasi Git proyek tunggal adalah pemecah kesepakatan. Saya memiliki proyek Hadoop / Oozie, dan memiliki satu repo kode, dan catatan kerja lainnya. Di Sublime, saya membuka keduanya di jendela yang sama, dan dapat berkomitmen ke repo Git yang sesuai untuk masing-masing

jadi, itu bagus untuk ditambahkan

+1 ya, kritis di dunia microservice biasanya memiliki 3..4 repo yang terbuka pada waktu yang sama

Pengingat Mingguan: Berhenti memposting komentar dengan +1. Sebaliknya, beri acungan jempol ke masalah awal, yang sebenarnya dihitung.

Aku tahu kalian semua bermaksud baik. Jadi jangan ragu untuk menghapus komentar +1 Anda agar tidak menghabiskan ruang dalam catatan sejarah penting ini juga!

@jamietre Saya sudah mencoba ... keras:

Mungkin alternatif lain adalah mengunci masalah ini tetapi tetap terbuka sampai terselesaikan? Dengan cara ini, kami mengetahui pentingnya masalah tersebut (menurut saya kami sudah mendapatkan cukup +1 untuk itu), tetapi tidak dapat menambah kekacauan / redundansi (misalnya, tidak boleh ada komentar lagi).

Meskipun itu adalah fitur yang jarang digunakan menurut saya, saya hanya menemukan penguncian pada satu proyek / repo publik di Github.

Penguncian dapat dibuka jika dianggap perlu, jika pernah.

@daluu ini adalah cara kerja repo / aspnet / pengumuman; setiap masalah segera dikunci. Karena itu, GitHub harus melakukan sesuatu di UI untuk setidaknya mengarahkan orang ke alternatif selain "+1" karena reaksi sekarang ada. 👍

Sangat membantu untuk menempatkan fungsi multi-jendela secara keseluruhan, ketika melihat dokumen lebih dari dua proyek,

pendekatan yang menarik untuk masalah ini. Saya adalah seorang programmer VB / .net selama bertahun-tahun, menyukai bahasa dan alatnya, tetapi telah pergi selama beberapa tahun di Hadoop / Spark / Scala / Intellij / Sublime-land. Saya masih mendengarkan DotNetRocks, ingin mengikuti perkembangan terbaru, dan tertarik untuk mendengar tentang aplikasi Kode ini. Sisi positifnya, ini adalah editor yang sangat bagus, dengan beberapa fitur Git yang tampak bagus, tapi sayangnya itu sama sekali tidak relevan. Karena tidak menangani Git untuk banyak proyek di ruang kerja yang sama, seperti yang dilakukan Sublime dengan sangat elegan, maka saya tidak bisa menggunakannya

Yang terjadi. Yang paling mengejutkan saya adalah reaksinya di sini, pertama mengklaim bahwa ini bukan fitur yang diperlukan, lalu sebagian besar diskusi sekarang tampaknya seputar "bagaimana kita bisa menghentikan orang memposting +1"

Saya akan memberi tahu Anda bagaimana Anda melakukannya - Anda memperbaiki masalah dasar yang pertama kali diangkat setahun yang lalu! Ini disebut "mendengarkan umpan balik". Hanya karena Anda tidak terpengaruh secara pribadi oleh suatu masalah, bukan berarti masalah itu tidak ada. Jika Anda tidak ingin sekelompok pengguna tertentu menggunakan aplikasi ini, baiklah, tetapi jangan beri kami mekanisme umpan balik, maka perselisihkan masalah kami dan kemudian jengkel dengan kami karena terus memintanya.

Saya kembali menggunakan Sublime

Masalah "+ 1" dapat diperbaiki dengan kode berikut: if (post_message == "+1") {add_smiley_reaction (); delete_post_message (); }

Dear GitHub, saya tersedia untuk disewa.

ya, ini tidak akan pernah bisa diperbaiki, bukan. Jauh lebih mudah untuk mengejek dan mengabaikan komentar "+1" daripada benar-benar mengatasi masalah inti, perangkat lunak dipasarkan ke bagian pengembang tertentu yang tidak melakukan apa yang diperlukan agar mereka menjadi produktif ...

baca saja yang ini "Setiap balasan langsung ke komentar ini (= lebih banyak meta) akan mengakibatkan saya memblokir pengguna." - sekarang, begitulah cara mengelola umpan balik! Tempelkan jari Anda ke telinga dan katakan "tidak bisa mendengarmu!"

yatuhan

@ kryps1 maka orang akan menambahkan "+ 1" atau "++ 1" atau "1+" atau "bump" atau "Ya, tolong. +1". Apapun yang akan Anda lakukan, orang akan menemukan jalan keluarnya. Tidak semudah yang Anda pikirkan.

Hentikan dengan debat yang tidak berguna tentang +1 's please ... Fokus pada apa yang dibutuhkan di sini, yaitu beberapa proyek di penjelajah.

Untuk masalah git , itu hanya harus dipecah dengan cara yang sama seperti explorer (yaitu dengan cwd).

Mari kita tidak memulai perang api atas barang +1. Alangkah baiknya jika masalah ini menjadi prioritas.

Tetapi saya ingin menyampaikan kepada komunitas, saya menganggap PR dan kontribusi diterima ;-) seseorang dapat menambal / memperbaiki kode jika pengembang inti tidak mendapatkannya. Saya memiliki beberapa proyek saya yang diperbaiki (dengan garpu) karena pengguna / pengembang lebih suka melakukannya sendiri daripada menunggu saya untuk melakukan perbaikan yang ingin mereka sarankan kepada saya. Jadi siapa saja yang merasa terganggu dengan masalah ini dan cukup mampu / terampil, tolong perbaiki (kemudian ajukan PR)? lol

Dan kembali ke topik +1, membahas masalah dan menambahkan pendapat Anda itu bagus, tetapi +1 adalah cara yang payah untuk melakukannya jika ada metode lain yang tersedia seperti fitur jempol. Pertimbangkan posting Facebook, atau posting Google+ asli, dan pengguna / pembaca menambahkan komentar +1 daripada mengklik Suka (atau salah satu reaksi baru Facebook), atau +1 untuk Google+. Seiring waktu, itu adalah utas komentar panjang +1 yang lumpuh, di mana ketika saya membaca, saya mungkin menggulir untuk melihat komentar yang menarik tetapi saya akhirnya melihat banyak +1. Inilah yang terjadi di sini, saya memilih untuk tidak melihat / membaca +1 ini, baik saya seorang pengembang proyek atau hanya pengguna (atau meneliti proyek ini untuk potensi penggunaan).

Pada catatan terkait, inilah penggunaan masalah GH yang konyol (tapi niat baik), alhamdulillah, orang-orang tidak semuanya memberi +1 padanya: https://github.com/sinatra/sinatra/issues/920

Saya menganggap PR dan kontribusi diterima

Tidak juga. Lihat komentar ini dari Agustus: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

Tampaknya masalah ini sudah ada di Peta Jalan setidaknya sejak saat itu, tetapi belum ada kemajuan. Senang mendengar pembaruan status dari tim VSCode.

Bagi saya, dan ini mencoba mengembalikan topik ke jalurnya, diperlukan beberapa folder proyek.

Di Atom, ini mendukung GIT, dan satu-satunya cara saya menggunakannya adalah dengan mencatat file mana yang berubah. Saya memiliki server Rackspace yang tidak mengizinkan SSH jadi saya melakukan pengunggahan manual. Namun, saya dapat memiliki beberapa folder proyek di bilah sisi, dan itu membuatnya lebih mudah untuk merujuk kode yang saya gunakan dalam proyek sebelumnya. Atau ganti persneling ke proyek lain jika saya butuh istirahat.

Dengan VSCode, masalah yang mencegah saya melakukan swtiching, dan saya ingin beralih, adalah kurangnya beberapa folder proyek di bilah samping.

Maksud saya, saya kira saya bisa membuka folder root untuk menyelesaikannya sementara, tetapi jika saya hanya membutuhkan 3/20 folder, dan saya tidak ingin melihat file yang hilang, maka ini akan menjadi implementasi yang mudah, bukan?

Pembaruan: Pembaruan meja kerja besar segera hadir adalah hot exit (# 101), saat mengerjakan hot exit, kami secara aktif mendiskusikan masalah ini untuk memastikan desain mempertimbangkan banyak folder.

Masalah ini saat ini nomor 2 dalam hal: +1: reaksi dari semua masalah (nomor 1 dengan tag meja kerja yang panjang), karena itu kemungkinan besar ini adalah pekerjaan besar berikutnya untuk meja kerja setelah keluar panas.

Aktif: +1: komentar; mereka hanya berfungsi untuk mengganggu 80+ orang yang berlangganan masalah tersebut. Namun, memberikan suara pada masalah dengan reaksi adalah salah satu hal paling kuat yang dapat Anda lakukan untuk memengaruhi proyek.

Perlu diingat juga bahwa kami adalah tim yang relatif kecil dan kebersihan basis kode serta kinerja vscode sangat penting, jadi perlu waktu lama untuk melakukannya dengan benar. Khususnya untuk sesuatu seperti ini yang merupakan perubahan mendasar tentang bagaimana vscode telah dibuat hingga saat ini, ada cukup banyak pekerjaan dalam masalah ini.

+1

Memang itu akan menjadi fitur yang berguna.

Saya beralih dari Atom dan sangat menyukainya, tetapi saya bekerja pada dua aplikasi UI dan 2 SDK lainnya, tetapi ketidakmampuan untuk mengubah antara proyek (atau folder) dengan cepat adalah kekurangan yang penting, saya rasa saya harus kembali ke Atom sampai ini terselesaikan

Saya sangat menantikan fitur ini ~~~

Saya seorang develper golang menggunakan vscode, semoga ini ada implementasinya, terima kasih!

Saya mencoba untuk beralih dari Sublime ke VScode. Dan segera saya menemukan VScode tidak mendukung banyak folder dalam konsep "proyek" sebenarnya adalah masalah yang memblokir formulir saya melakukannya.

Sangat menyukai fitur lain dari editor "ringan" ini. Sementara itu, saya percaya mendukung banyak folder dalam sebuah "proyek" tidak akan membuat VScode "kelebihan berat badan" atau "seperti IDE". Itu hanya akan membuatnya lebih nyaman bagi pengembang yang menggunakan editor lain untuk membuat transisi yang tidak terlalu menyakitkan.

Harapan untuk mengalami peningkatan ini. Terima kasih!

Juga jika tim dapat menambahkan kemampuan untuk menyimpan pengaturan berbasis proyek yang menggantikan pengaturan default yang akan sangat bagus. Kasus penggunaannya adalah jika saya dapat memiliki penerjemah yang berbeda untuk proyek yang berbeda. Demikian pula memiliki ukuran tab yang berbeda dll juga akan membantu. Tolong beri tahu saya jika ini sudah dapat dicapai dengan beberapa cara.

Sebagai pengembang, kami selalu mengerjakan banyak proyek dan kami memiliki proyek sampingan sendiri. Menyesuaikan pengaturan proyek (pengaturan ruang kerja untuk vscode) setiap kali saya beralih proyek sangat merepotkan.

@bajubullet Anda harus mencoba https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig Tidak yakin apakah ini mencakup semua yang Anda butuhkan, tetapi ini adalah permulaan.

@danechitoaie terima kasih atas tanggapannya. EditorConfig tidak membantu, saya dapat menentukan properti per jenis file tetapi jika saya dapat menyimpannya sebagai pengaturan proyek, itu akan lebih mudah dan saya tidak suka memiliki .editorconfig untuk setiap proyek. Juga dalam kasus ekstensi seperti ekstensi python yang memungkinkan kami menyediakan penerjemah untuk digunakan, ini tidak akan membantu karena python.pythonPath tidak didukung melalui editorconfig. Tolong beri tahu saya jika saya melewatkan sesuatu di sini. Ada saran dipersilahkan.

Saya setuju, saya juga sangat menantikan beberapa jenis pengaturan khusus proyek dan dapat membuka beberapa folder "root". Itu satu-satunya hal yang saya lewatkan dari Sublime.

Ini sedang Diimplementasikan segera!

Jadi tidak perlu terus menambah postingan ini. Jika Anda memiliki masalah lain, buat utas baru. Terima kasih!

Ini adalah utas yang cukup panjang dan saya membaca mungkin sepertiganya, tetapi hanya ingin menyuarakan dukungan saya. Saya baru saja menginstal VS Code dengan https://github.com/JuliaEditorSupport/julia-vscode sebagai kemungkinan pengganti Atom / Juno. Cantiknya! 😍

Namun, ketika mengembangkan kode Julia, saya merasa cukup penting untuk dapat membuka banyak paket di folder yang berbeda. Pada prinsipnya, saya dapat membuka folder di atas, tetapi itu akan mengekspos 100-an paket Julia yang telah saya instal. Saya juga dapat mengubah LOAD_PATH saya, tetapi saya lebih memilih solusi VS Code.

Saya sangat berharap bisa membuka banyak folder. Terima kasih atas usahanya 👍

Halo semuanya, seperti yang Anda ketahui, kami sedang mempelajari implementasi masalah ini selama pengulangan ini.

Dari https://github.com/Microsoft/vscode/issues/17608

Selidiki ruang kerja multi root di berbagai komponen @team

Saya ingin mengobrol dengan 3-5 orang dari Anda tentang kasus penggunaan Anda saat kami memikirkan detail penerapan. Silakan mendaftar untuk slot waktu 15 menit Selasa depan jika Anda bisa. Saya ingin mengobrol.

beralih antara api dan ui saya membuat saya gila ... :-(

@ehartford ada alasan khusus mereka tidak berbagi orang tua yang sama?

Iya. Integrasi Git tidak berfungsi jika saya hanya membuka direktori induk.

@ehartford alasan bagus: senyum:

@waderyan, apakah Anda mencari kasus penggunaan _end user_ saja, atau _extension developer_ juga?

Sebagai pengguna _end_, dukungan multi folder sering kali berguna untuk _tujuan pencarian_. Saya biasa membuat Proyek dengan menambahkan folder berbeda dari API yang berbeda, hanya untuk membuat pencarian lebih mudah (terpadu). Saya akan mengatakan saya tidak terlalu merindukan hari ini, dan tidak mengganggu saya untuk memiliki beberapa jendela VSCode hari ini, khususnya setelah Switch Window perintah ditambahkan: +1:

Sebagai _extension developer_ saya memiliki beberapa ekstensi yang didasarkan pada _Project Context_, seperti context.workspaceState , activationEvents/workspaceContains . Dan juga Project Manager , yang omong-omong saya sudah mulai refactoring internal untuk mendukung multi folder. Saya ingin mengetahui bagaimana hal ini akan memengaruhi ekstensi

Terima kasih

Untuk menambah apa yang saya katakan di atas (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), saya sebenarnya menggunakan submodul Git, jadi ketika saya mengerjakan paket saya sendiri (pribadi), itu masuk akal untuk menggabungkannya, tetapi karena Julia masih cukup muda (secara relatif), saya sering perlu mengerjakan paket lain bersama paket saya. Saya tidak merasakan alasan kuat untuk menambahkan paket lain ini sebagai submodul (walaupun saya bisa).

Secara umum, untuk pengembangan paket Julia, saya terus berpindah-pindah paket sehingga memiliki beberapa folder proyek akan sangat bagus: +1:

PS: MS, mohon perhatikan Julia;)

Kasus penggunaan paling sederhana: layanan mikro

Ha ha. Ya @saada 👍

@saada pasti ada di radar. Dapatkah Anda menjawab pertanyaan-pertanyaan ini untuk membantu saya lebih memahami persyaratannya?

1. Apakah layanan mikro Anda berbagi folder induk? Mengapa atau mengapa tidak?
2. Apakah setiap layanan mikro dipisahkan ke dalam repositori gitnya sendiri? Mengapa atau mengapa tidak?

1. Apakah setiap layanan mikro dipisahkan ke dalam repositori gitnya sendiri? Mengapa atau mengapa tidak?

@waderyan satu kemungkinan alasannya adalah bahwa beberapa platform PaaS populer seperti Heroku mengharuskan setiap aplikasi (layanan mikro) berada dalam repo Git yang terpisah. Deploy-via-git-push telah menjadi strategi yang populer.

@waderyan Saya mendaftar untuk slot besok & menantikannya - tetapi di sepanjang garis kasus penggunaan seperti ini, milik kami serupa.

Kami adalah organisasi besar, kami memiliki registri npm pribadi, dan menerbitkan modul kami sendiri yang dibagikan di dalam organisasi. Kami memiliki aplikasi react dengan basis kode klien yang merupakan aplikasi besar yang menggunakan beberapa modul umum (seperti lib utilitas, komponen bersama), dan basis kode server yang terdiri dari beberapa modul juga (aplikasi server ekspres, komponen layanan data backend yang digunakan oleh lapisan layanan, dan layanan aktual yang diekspos ke klien). Pengembangan aktif melibatkan minimal dua (lapisan klien dan layanan) tetapi pemecahan masalah dapat dengan mudah melibatkan setengah lusin modul.

Bahkan saat menggunakan modul npm publik, terkadang berguna untuk menghubungkan kode sumbernya secara langsung dan terbuka dalam contoh VS Code terpisah untuk memecahkan masalah yang sulit, atau bahkan bug dalam modul pihak ketiga, tetapi kebanyakan itu adalah kode kita sendiri.

Masing-masing adalah repo git yang terpisah. Tidak ada masalah menyimpannya di sistem file saya di bawah satu folder root (saya akan tetap melakukannya). Tetapi saya perlu memiliki instance terpisah dari VS Code yang terbuka untuk masing-masing, dan beralih bolak-balik itu menyakitkan karena Anda hanya dapat melihat nama file - bukan nama aplikasi itu sendiri. Tidak ada cara untuk dengan mudah mengetahui aplikasi / modul / proyek mana yang terbuka di jendela mana. Nama file itu sendiri memberikan sedikit informasi yang berguna dalam membedakan antara beberapa contoh VS Code.

Ada masalah terbuka lainnya terkait dengan mengizinkan informasi bilah judul dapat dikonfigurasi yang juga banyak saya komentari - dan juga tetap belum terpecahkan. Jika dimungkinkan untuk memiliki nama folder root flush-left di bilah judul, masalah membuka banyak proyek akan jauh lebih sedikit dari masalah, karena saya setidaknya bisa melihat contoh terbuka mana yang ada di dalam Windows saat beralih tugas. Ini sepertinya akan sangat sepele untuk membuat konfigurasi dan setidaknya akan mengurangi rasa sakit karena tidak dapat membuka banyak repo git dalam satu waktu banyak sementara ini diketahui ...

@weryan

1. Proyek web saya dikelola oleh satu folder induk. Ini diatur dengan cara ini untuk organisasi, dan tautan cepat untuk folder repositori saya. Saya juga melakukan ini, karena mudah bagi saya untuk menukar ke proyek sebelumnya / saat ini untuk menarik sampel kode ketika akan digunakan kembali. Dibandingkan membuka jendela lain, lebih mudah untuk membuka tab lain, dan lebih efisien waktu dalam kasus saya.

2. Setiap proyek web memiliki integrasi gitnya sendiri, namun bagi saya pribadi, saya tidak memerlukan .git untuk diintegrasikan ke editor kode saya. Ini pilihan yang bagus untuk saya, tetapi bukan persyaratan. Mereka memiliki integrasi .git sendiri karena ingin memisahkan setiap proyek web di host repo saya.

@nickmak @jamietre @pesho terima kasih telah membagikan pemikiran Anda. Ini berguna dan saya berharap dapat mengobrol dengan Anda lebih banyak lagi besok.

@alefragnani Saya fokus pada skenario pengguna akhir. Kami telah menangani masalah ini dengan hati-hati karena pengaruhnya terhadap ekstensi. Kami akan melangkah dengan hati-hati dan mengkomunikasikan perubahan api apa pun. Ping saya di Twitter jika Anda mau dan kita dapat menelepon untuk berdiskusi lebih lanjut.

bahkan notepad ++ mendukung multi folder. Itu alasannya tidak bisa meninggalkan notepad ++.
hari ini bekerja dengan javascript perlu membuka banyak proyek.

Saya melakukan pekerjaan perangkat lunak tertanam dan biasanya ada beberapa folder yang saya kerjakan di seluruh sistem. Misalnya kode aplikasi, pustaka vendor, dan kode sistem operasi.

Saya ingin menambahkan kasus penggunaan saya di sini untuk beberapa folder di jendela yang sama.

Saya seorang pengembang game dan, untuk game kami saat ini, kami telah menerapkan dukungan mod. Game kami memiliki proyek klien, server, dan server master. Saat mengedit file mod, biasanya hanya bekerja di level mod game (alih-alih apa yang kami sebut level inti atau native dari kode game sebenarnya. Mis. Bekerja hanya di file Lua alih-alih file C ++ dan C # untuk server dan klien masing-masing). Folder seringkali tidak dapat ditemukan di dalam folder induk yang sama.

Dalam kasus penggunaan ini, ketika hanya bekerja dalam file mod, di masa lalu kami telah menggunakan fungsionalitas multifolder Sublime untuk membuat tampilan proyek hanya folder mod tingkat atas dari Klien dan Server. Ini memungkinkan kita untuk menghindari file asli (C # dan C ++) dan dengan cepat mengedit file Lua di kedua proyek yang sangat terkait satu sama lain.

Memiliki dukungan multifolder di VSCode akan memungkinkan kami melakukan hal yang sama dan sangat memudahkan adopsi VSCode kami (yang sangat kami sukai).

Apa yang datang dari panggilan yang diadakan minggu lalu? Saya menggunakan mac dan sepertinya tidak dapat membuka banyak contoh VSCode, yang menurut saya akan menjadi solusi.

Terima kasih!

Saya mendapat telepon minggu lalu dengan Wade, jelas dan adil bahwa ini bukan
prioritas awal, mereka telah membangun editor yang sangat bagus, dan sekarang mudah-mudahan
mereka mengembangkannya untuk memenuhi kebutuhan pengembang yang berbeda. Tim Pengembang adalah
mendengarkan, saya tidak sabar untuk melihat bagaimana mereka melakukannya

On Sun, 15 Jan 2017 21:20 nowherenearithaca, [email protected]
menulis:

Apa yang datang dari panggilan yang diadakan minggu lalu? Saya menggunakan Mac dan sepertinya tidak bisa
untuk membuka beberapa contoh VSCode, yang menurut saya akan menjadi solusi.

Terima kasih!

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

dalam permintaan besar
menandai

@nowherenearithaca Saya mendapatkan panggilan telepon yang bagus dengan sejumlah pengguna dan membagikan apa yang saya pelajari dengan anggota tim lainnya. Kami masih memikirkan langkah selanjutnya, tetapi saya berharap kami akan segera melakukan sesuatu di area ini.

@waderyan , maaf atas tanggapan yang terlambat:

Apakah layanan mikro Anda berbagi folder induk? Mengapa atau mengapa tidak?

Ya, demi kenyamanan. Ini mempermudah untuk menemukan layanan terkait saat mereka berada di direktori yang sama.

Apakah setiap layanan mikro dipisahkan ke dalam repositori gitnya sendiri? Mengapa atau mengapa tidak?

Iya. Mereka tidak hanya memiliki repo yang berbeda, mereka juga memiliki konfigurasi linting dan debugging yang berbeda. Selain itu, menggunakan Cmd + P untuk beralih file antar proyek sangat berguna. Pencarian global di seluruh proyek terkait, ...

Menantikan untuk melihat ini beraksi!

Salah satu solusinya adalah membuat tautan ke folder tempat file yang ingin Anda akses berada.
Ini tidak ideal tapi bisa membantu.

_Contoh:_

/home/myprojet
/home/mylibs
cd /home/myproject
ln -s /home/mylibs
code /home/myprojet

Saya memiliki 3 monitor dan saya ingin menggunakan VSCode di ketiganya. Jika saya tidak dapat membuka beberapa contoh, setidaknya mendukung melepas tab dan menyeretnya ke jendela lain (mirip dengan Visual Studio 2015).

Setuju.

Semua editor teks lainnya melakukannya. Mengapa Microsoft tidak memikirkan sesuatu yang begitu sederhana dan perlu?

@calloncampbell Fitur itu ada dalam masalah ini: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring Saya tidak tahu apa yang saya lakukan salah tetapi dengan menggunakan code -n saya dapat membuka sebanyak mungkin editor yang saya inginkan.

Jika saya memahaminya dengan benar, ini akan diselidiki dalam Rencana Iterasi Februari sebagai "Penyelidikan awal dalam menerapkan 'ruang kerja multi root', ruang kerja 'multi folder'" :)

+1 ...
Bukankah ini mungkin dengan VSCode versi lama atau apakah saya hanya menggunakan Sublime? lupa ...
tapi sangat berguna.
Sekarang Mac saya dikotori dengan 6 jendela di semua tempat ...

Dan tidak, saya tidak akan membuka folder root dari semua 6 folder yang telah saya buka, karena penjelajah adalah gulir vertikal dan akan butuh waktu lama bagi saya untuk menelusuri file ...

@edmundtfy itu mungkin dalam luhur. Kode Visual Studio tidak pernah memiliki dukungan untuk fungsionalitas ini.

@ solusi

@DeeJaVu mempertimbangkan bahwa ... VSCode memiliki mouseover-tooltip dan control + klik untuk menuju ke definisi. Saya mengunduh beberapa ekstensi untuk Sublime tetapi hal-hal gerakan mouse dan kontrol + klik tidak berfungsi dengan baik .. ada rekomendasi?

Saya sangat merindukan ini setelah menggunakan Sublime selama bertahun-tahun. Saat ini saya bekerja dengan Intershop (sebagai front-end) dengan ratusan ribu file per cardridge. Jika saya harus memuat toko web lengkap, sangat lambat ketika Anda ingin membuka CTRL + P untuk segera beralih ke file atau ketika Anda harus mencari.

Selain itu, saya tidak ingin setiap folder proyek ada di editor saya. Saya tidak membutuhkan segalanya sebagai pengembang front-end. Folder yang saya butuhkan saja sudah cukup.

Contoh lain: membuat situs Wordpress dan pluginnya secara bersamaan. Mengapa saya perlu menyertakan situs Wordpress lengkap? Itu hanya memperlambat efisiensi Anda.

Masalah lain yang kami miliki: kerangka kerja front-end kami terbagi dalam repo git yang berbeda. Memiliki lebih dari 4 jendela terbuka adalah rasa sakit yang nyata. Dan SCSS intellisense tidak berfungsi saat itu (Yaitu variabel dari inti> paket)

TLDR; VScode tidak dapat digunakan untuk proyek besar / besar

+1, bayangkan Anda mengembangkan wordpress atau drupal dengan beberapa modul khusus.

Akar proyek Anda adalah akar dari situs web Anda, tetapi Anda tidak ingin situs web lengkap menjadi repo, Anda hanya ingin beberapa modul atau tema Anda masing-masing sebagai repo independen.

Kasus penggunaan yang sangat umum dalam pengembangan web yang harus dicakup, bahkan oleh IDE terkecil / teringan.

+1

+1, akan membuat saya dapat mengedit proyek dan mengerjakan submodulnya dengan mulus

+1

Ini satu-satunya masalah yang menghentikan kami untuk memindahkan seluruh tim pengembang 32 orang kami ke VS.

Pengembangan layanan mikro tidak memungkinkan, itu menyakitkan.

+1

+1, pasti berguna, saya memutuskan untuk beralih ke vscode dari sublime, tetapi, karena fitur ini hilang, saya rasa saya akan tetap menggunakan sublime sampai suatu hari nanti ..

Ini adalah fitur yang sangat penting dan mendasar. Saya tidak percaya kenapa pengembang editor hebat ini mengabaikannya. Tidak ada gunanya tanpa fitur ini. Ini menghentikan saya untuk beralih ke VSCode dari Atom.

Harap tambahkan fitur ini. Setelah menggunakan Sublime dan kemudian Atom, ini bagi saya fitur editor yang diperlukan. Tentu saja tidak semudah itu karena integrasi git, tetapi itu adalah sesuatu yang saya butuhkan dalam editor favorit saya.

+1

+1 kebutuhan mendesak

+1 Seperti yang saya katakan sebelumnya, untuk berpindah dari Atom ke VSCode kita sangat membutuhkan fitur ini.

PERHATIAN SEBELUM KOMENTAR
* HARAP !!!! Hentikan komentar dengan "+1"

Setiap komentar tidak berguna Anda mengalihkan perhatian lebih dari seratus orang hanya dengan utas ini !!!
Jika Anda ingin mendukung fitur ini - ada emosi di pesan pertama!
Jika Anda ingin berlangganan pembaruan - untuk ini adalah tombol "Berlangganan" di sebelah kanan topik
Hormati anggota lain, yang dipaksa untuk membaca "+1", "sangat dibutuhkan", dll

Sebagai referensi, cara Sublime Text (sebagai contoh) mengatur proyeknya adalah dengan "menyertakan" pohon folder, dengan opsi unik per "folder" yang disertakan dalam proyek Anda.

Untuk memvisualisasikannya, JSON dari file proyek Sublime Text terlihat seperti ini:

{
    "folders":
    [
        {
            "name": "Front-End (web-forms)",
            "path": "source/www/forms",
            "file_exclude_patterns":
            [
                "*.sublime-*",
                ".gitignore"
            ],
            "folder_exclude_patterns":
            [
                "node_modules",
                ".idea",
                "bin",
                "fonts"
            ]
        },
        {
            "name": "CORE C# Server Components",
            "path": "Source/Server",
            "file_exclude_patterns":
            [
                ".gitignore",
                "*.resx",
                "*.designer.cs",
                "*.StyleCop",
                "*.testsettings",
                "*.cache",
                "*.user",
                "*.vsmdi"
            ],
            "folder_exclude_patterns":
            [
                "bin",
                "obj",
                "TestResults",
                "Service References"
            ]
        },
        {
            "name": "DB schemas & utility scripts",
            "path": "Source/Database"
        },
        {
            "name": "Grunt Build source",
            "path": "Build",
            "folder_exclude_patterns":
            [
                "dist",
                "node_modules",
                "TestResults"
            ]
        }
    ],
}

Seperti yang Anda lihat, setiap folder yang disertakan relatif terhadap jalur proyek (dalam kasus teks luhur, ini adalah jalur dari file *.sublime-project ). Selain itu, setiap folder memiliki bagian untuk mengecualikan pola file dan folder dengan wildcard. Bagus untuk mengabaikan (seperti yang bisa dilihat di atas) hasil tes, pustaka yang tidak boleh Anda edit, karya seni, dan banyak hal lainnya.

Ini adalah alasan terakhir saya tidak beralih.

Ini sangat berguna!

+1
Contoh: perlu memeriksa apakah beberapa fungsionalitas belum diterapkan di modul lain yang direferensikan oleh aplikasi sehingga saya tidak menduplikasi fungsionalitas

Tentunya modul disimpan di tempat lain di jalur file, bukan di aplikasi itu sendiri, dan menggunakan banyak jendela menyakitkan hanya dengan satu layar, ketika Anda hanya ingin mengakses file dengan cepat dan membaca kodenya
Saya berbicara tentang aplikasi AngularJS, yang tidak memerlukan penerapan atau apa pun, hanya server yang berjalan.
Mengapa saya harus repot-repot mengembangkan struktur file lain, ketika saya bisa membuka folder Aplikasi langsung dari Tomcat dan perubahan saya diterapkan secara real time.

Dan tidak, tidak ada folder induk, kecuali jika Anda menyarankan untuk membuka folder server Tomcat sebagai proyek (yang seperti menyarankan saya membuka seluruh HDD saya sebagai proyek, karena saya akan dapat membuka semua file nanti).

Wow, saya mencopot atom untuk mencoba VS, dan fitur ini belum ditambahkan sejak 2015.

stoffeastrom membuka edisi ini pada 21 Nov 2015

Itu menyedihkan. :kecewa:

PS: Membuka folder master, sebenarnya bukan solusi karena membuka semua file yang tidak diinginkan juga, mengalahkan seluruh tujuan tiket ini.

Itu memang menyedihkan. Tapi sekali lagi tidak menekan sebagai orang-orang masih mengeluh tentang menakjubkan, bebas, Editor opensource (yang secara konsisten menambahkan beberapa fitur baru month_ _every). Tidak sesederhana mengirim spam ke semua orang yang menonton utas ini dengan komentar tentang depresi seseorang.

_{(Sekarang saya adalah salah satu pengirim spam, saya kira: senyum :)}

Pembaruan: Rencana saat ini adalah melihat ini di iterasi Maret / April.

Lihat https://github.com/Microsoft/vscode/issues/21923 untuk rencana iterasi bulan Maret:

Selidiki ruang kerja multi-root, multi-folder # 396 @bpasero @Tyriar

+1

Untuk membagikan contoh dunia nyata yang menyempurnakan deskripsi fitur: Contoh, WordPress Theme / Plugin dev.

Di editor lain, saya menyiapkan beberapa folder sebagai "bookmark", untuk mendapatkan pohon file yang cukup besar dan kompleks sedikit lebih mudah untuk dikelola. Salah satunya adalah untuk webroot, yang merupakan root yang saya lebih suka fungsi debug dan penyelesaian kode apa pun untuk memulai (lingkungan). Kedua adalah proyek sebenarnya, folder tema atau folder plugin yang, dalam alur kerja saya, adalah root kontrol versi. Kadang-kadang, saya menyiapkan folder tambahan sebagai referensi, seperti tema induk, atau tema template, atau plugin yang saya integrasikan dengan dan saya perlu sering merujuk / membaca.

Jadi fitur yang ditetapkan di sini adalah, 1. kemampuan untuk mengatur git root dan pencarian root ke lokasi yang berbeda. 2. Sistem bookmark folder yang murni visual untuk mendeklarasikan panel pohon file.

Untuk beberapa di thread, di mana git root, dan project root sama, tampaknya mempelajari dan menggunakan submodul sudah cukup, lalu hanya sekitar 2. untuk mendapatkan tampilan folder bersarang yang tidak berantakan.

Saya yakin bahwa beberapa di utas sebenarnya meminta dukungan multi-proyek literal, tetapi saya berasumsi sebagian besar hanya meminta ide bookmark folder yang lebih sederhana.

Saya juga meminta cara untuk mendefinisikan satu sebagai root proyek (search / debug), dan yang lainnya sebagai root git. (Jangan ragu untuk mengabaikan penamaan buruk saya.)

Solusi saya untuk ini hanyalah membuat folder induk dan di dalam membuat tautan simbolik dengan semua proyek yang saya inginkan.
_misalnya._

Saya memiliki proyek ini

1. api-aplikasi-saya
2. klien-aplikasi-saya

Saya membuat folder bernama _my-app-all_ (namanya tidak relevan di sini) dan di dalamnya, saya membuat dua tautan simbolis yang mengarah ke my-app-api dan my-app-client lalu di VSCode saya hanya perlu membuka aplikasi-saya- semua

Langkah

1. mkdir my-app-all
2. cd my-app-all
3. ls -s ../my-app-api
4. ls -s ../my-app-client

Catatan:
Integrasi git tidak akan berfungsi

@DannyFeliz ini harus ditandai sebagai jawaban untuk masalah ini dan diposting di atas untuk dilihat semua orang ... Saya telah menguji ini di Windows juga, menggunakan perintah MKLINK.
Contoh penggunaan:

1. Buka Command Prompt dengan hak istimewa Administrator
2. Buka folder proyek Anda
   3. [opsional] buat folder tautan
3. gunakan jalur MKLINK / D "link_name" "ke folder yang ingin Anda rujuk"

Ketika Anda membuka proyek dalam kode VS, Anda akan melihat folder yang direferensikan dan semua file / folder di dalamnya.

Selamat coding guys!

Ini tidak memungkinkan integrasi Git berfungsi.

Pada hari Senin, 20 Maret 2017 jam 14:42, poparazvandragos [email protected]
menulis:

@DannyFeliz https://github.com/DannyFeliz ini harus ditandai sebagai
menjawab masalah ini dan diposting di bagian atas untuk dilihat semua orang ... Saya telah menguji
ini di Windows juga, menggunakan perintah MKLINK.
Contoh penggunaan:

1. Buka Command Prompt dengan hak istimewa Administrator
2. Buka folder proyek Anda
   3. [opsional] buat folder tautan
3. gunakan jalur MKLINK / D "link_name" "ke folder yang ingin Anda rujuk"

Ketika Anda membuka proyek dalam kode VS, Anda akan melihat folder yang direferensikan
dan semua file / folder di dalamnya.

Selamat coding guys!

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford Saya mengatakan sebuah jawaban, bukan jawaban THE, karena kebanyakan dari kita hanya mencari hal yang tepat ini, menampilkan beberapa direktori di jendela VSCode yang sama, yang berada di lokasi yang berbeda.
Symbolic Links melakukan hal itu, tetapi ketika bekerja pada Windows ini bukanlah solusi yang muncul dalam pikiran.
Itu harus melewati 2 tahun dan untuk pengembang Linux / OSX datang dan menunjukkan kepada kami solusi yang paling sederhana.
Saya senang saya memutuskan untuk akhirnya memberikan komentar saya tentang masalah ini karena saya punya solusi untuk apa yang saya inginkan
hanya setelah 12 hari, saat saya sangat membutuhkannya.

Masalah ini tidak boleh dihentikan, karena masih banyak yang bisa dilakukan jika pengembang memilih untuk ikut campur dalam masalah ini.
Tetapi bagi sebagian besar dari kita ini memuaskan. Saya hanya menyarankan untuk memindahkan ini ke atas, sehingga orang tidak membuang waktu membaca semua komentar lainnya, sampai mereka mencapai komentar ini. Beberapa mungkin mengabaikannya karena ukuran utasnya.

Saya hanya akan mengedit ini karena saya melihat orang-orang sudah melompat di punggung saya karena saya menemukan cara mencapai apa yang saya inginkan dan mencoba mempermudah orang lain untuk melihat alternatif meskipun tidak sempurna. BTW: Anda selalu dapat menggunakan command prompt yang diintegrasikan ke dalam VSCode untuk menarik / melakukan / mendorong file di folder tertaut individual tetapi mengapa menyelesaikan penyelesaiannya.

Tanpa integrasi Git, ini adalah nonstarter total. Saya tidak menganggap ini solusi yang dapat diterima dengan cara apa pun. Menantikan solusi yang sebenarnya. Salam Hormat.

Jika membantu - klien google appengine nodejs terstruktur seperti ini:

https://github.com/GoogleCloudPlatform/google-cloud-node

Saya ingin sekali dapat membuka / men-debug / bekerja dalam solusi seperti ini (meskipun itu satu paket dalam satu waktu). Saya ingin sekali bisa menulis proyek / libs berbasis Ketikan dalam gaya ini.

Terima kasih atas semua kerja bagusnya!

Suka VSCode, tapi itu omong kosong dalam menangani banyak proyek. Tapi saya bisa mengerti mengapa fitur ini ditunda, karena itu membuat banyak hal seperti kontrol sumber lebih rumit karena bersarang dll.

Saya akan senang untuk fitur 'proyek quick switch' ATAU kemampuan untuk 'tab' beberapa contoh vscode dalam satu jendela.

Setuju sepenuhnya, dukung pembukaan beberapa folder proyek di jendela yang sama. Fungsi ini sangat penting.

@replete Ini bukan solusi sempurna untuk masalah Anda. Tapi cobalah Manajer Proyek , ini sebagian membantu saya sekarang.

@dariusrosendahl Ya, saya menemukan pagi ini dengan cukup

Bilah sisi hanya memiliki 5 ikon, Tidak perlu banyak menambahkan bilah sisi 'Proyek'. Tetapi tampaknya pemilik produk vscode sangat cerewet tentang betapa minimalnya itu. IMO terlalu minim karena sekarang menjadi IDE.

@replete senang mengetahui ini berguna 😄

Bahkan, ada _experimental API_ untuk membuat apa yang disebut _Tree Explorer Contribution_ (seperti panel Symbols - https://github.com/Microsoft/vscode/issues/15485). Dengan itu, ekstensi dapat menambahkan ikon ke Bilah Aktivitas.

Saya akan menambahkan masalah ke ekstensi saya dengan saran Anda, terima kasih 👍

+1

@tokopedia

Saya, secara pribadi, tidak peduli apakah fitur ini ada di produk atau tidak - saya mengerti mengapa beberapa orang menginginkannya, tetapi saya akan menunjukkan bahwa itu membuat semuanya sedikit lebih berbelit-belit.

Maka mungkin jangan mendominasi percakapan dengan komentar negatif terhadap fitur tersebut dan tentang bagaimana VSC bukan IDE? Saya pikir satu tanggapan / pemungutan suara negatif sudah cukup, atau paling buruk dua, jika seseorang perlu memperjelas posisi lebih lanjut.

Selain itu, argumen "bukan IDE" diperdebatkan. Non-IDE lainnya juga memungkinkan untuk itu.

Misalnya: saat mencari menggunakan ekspresi regex - ruang kerja mana yang saya cari? satu? semua?

Bukan masalah besar. Cari semua, atau minta pemilih untuk menelusuri pencarian ke salah satu ruang kerja terbuka. Sekali lagi, "non IDE" lain (serta IDE) sudah menangani kasus ini (dan lainnya).

Saya memperbaiki masalah ini di pengaturan saya sendiri dengan membuat dir untuk setiap "ruang kerja" dan menghubungkan ke proyek yang ingin saya lihat di ruang kerja tersebut.

saya melihat bahwa

Penyelidikan awal ke dalam ruang kerja multi-root dan multi-folder # 396 @bpasero @Tyriar

dilakukan menurut https://github.com/Microsoft/vscode/issues/21923 pembaruan apa pun tentang ini? :)

Kami (bagian dari tim) melakukan penyelidikan awal mengenai jumlah pekerjaan yang terlibat dan tantangan yang kami lihat dan langkah selanjutnya adalah mendiskusikan hasilnya dengan tim dan merencanakannya. Kami melakukan perencanaan untuk rilis April selama minggu ini jadi saya mengharapkan lebih banyak item rencana berbutir halus karena pekerjaan ini segera muncul.

Jika saya tidak terlambat ke pesta, inilah cara yang bagus untuk menerapkannya.
Saat Anda membuka "Explorer", kami sudah memiliki dua bagian. Satu untuk file yang dibuka dan satu untuk pohon penjelajah dari folder yang dibuka saat ini.

Idealnya kita bisa membuka lebih banyak folder di jendela yang sama dan mereka akan ditambahkan di sini di bagiannya sendiri yang dapat diperluas untuk melihat pohon penjelajah.

Hal yang sama dapat dilakukan untuk bagian Kontrol Sumber. Satu subbagian untuk setiap folder yang dibuka di "explorer". Jadi relasi 1to1.

Dengan cara ini mungkin kita bisa membuat semua orang bahagia. Kami memiliki dukungan untuk membuka banyak folder di jendela yang sama jika kami mau, dan juga integrasi GIT masih berfungsi dan dapat menangani setiap "akar proyek" secara terpisah.

Buka lebih dari satu proyek di jendela yang sama, itu adalah fitur penting bagi saya juga. Biasanya, saya juga membuka proyek untuk menyalin beberapa aplikasi dasar. Saya baru saja menginstal Visual Studio Code dan saya akan kembali ke Atom karena alasan ini

+1 Saya ingin menunjukkan nilai VSCode dev lainnya, tetapi tidak dapat membuka dua folder di jendela yang sama adalah dealbreaker. Saya berharap ini mendapat prioritas yang lebih tinggi.

Hanya dua sen saya:

Sejauh ini kata "monorepo" tidak muncul di thread ini

Monorepo saya memusatkan masalah konfigurasi di antara beberapa root, di mana setiap root ditandai dengan file ".root" di folder yang berisi root.

Tidak setiap root adalah repositori git eksternal, tetapi mereka mengizinkan penggantian sebagian dari konfigurasi global.

Masalah utama saya adalah bahwa pencarian file dan / atau simbol tidak memprioritaskan konten root saya

Saya pikir persyaratan dapat dibagi menjadi ~ 4 yang terpisah, yang mungkin atau mungkin tidak terkait langsung satu sama lain (dan mungkin diterapkan secara independen):

• mendukung banyak folder di penjelajah
• mendukung banyak folder dalam pencarian
• mendukung banyak folder dalam kontrol sumber
• mendukung banyak folder di debug

Dari apa yang telah saya lihat di utas ini, memisahkan ini dapat mendukung beragam skenario. Tentu saja masih ada beberapa folder "utama", yang mempengaruhi bagaimana folder yang dikonfigurasi / dipilih disimpan.

Saya tidak mengerti mengapa sebagian besar komentar berbicara tentang solusi penjelajah multi-root atau multi-folder. Sebenarnya saya pikir sangat buruk untuk mencoba menerapkannya dengan cara IDE. Ini menambah kompleksitas dan pasti berdampak pada kinerja (waktu buka, git refresh ....).

Menurut saya fitur ini sangat penting, pada dasarnya kebutuhannya adalah memiliki visual tentang semua proyek terkait dan untuk beralih antar jendela proyek dengan cepat!

Kami memiliki dua pilihan:

• Implementasi dalam satu jendela : Dalam pengertian saya ini memperkenalkan banyak masalah lain, banyak proyek berakar untuk git, cari ..... INI SANGAT BURUK untuk UX dan berpotensi memperkenalkan bug dan kompleksitas ke editor.
• Terapkan mekanisme sakelar Visual dan pertahankan satu jendela per proyek : ini adalah pilihan yang paling aman dan nyaman dengan biaya yang sangat rendah! @ min20 memposting visual tentang tombol sakelar kendur antar grup yang menurut saya sempurna untuk kebutuhan tersebut!

Saya harap fitur ini akan mendarat, tetapi tidak sebagai solusi multi-root! salah satu manfaat utama editor kecil adalah kesederhanaan dan kecepatannya, muti-root != simplicity & speed

Saya harus sepenuhnya tidak setuju dengan Anda @ g13013, pernahkah Anda melihat implementasi Sublime? Ini sangat sederhana dan masih jauh lebih cepat daripada Visual Studio Code. Bahkan dengan semua plugin GIT diaktifkan.

Kami tidak berbicara tentang menggunakan banyak proyek dalam 1 editor. Kami berbicara tentang hanya menggunakan folder proyek yang Anda butuhkan.

Saya sedang mengerjakan toko Intershop misalnya. Ada banyak yang tidak saya butuhkan, hanya kartrid yang harus saya edit. 80% folder dan file tidak berguna bagi saya dan hanya membuat editor lebih berat (percayalah, ini sangat melambat).

Menggunakan "Buka Cepat" di Visual Studio juga tidak dapat digunakan jika ada banyak file duplikat. Anda sering tidak yakin apakah Anda akan membuka yang benar dan lagi, itu melambat dengan BANYAK file.

Saya mengerti, tetapi, setelah menggunakan sublim dan atom di masa lalu, saya akhirnya menyimpulkan bahwa tidak satupun dari mereka dengan fitur "muti-root" telah memecahkan apa pun selain menjelajahi file proyek, berbicara tentang luhur, pohon folder luhur sangat lambat di proyek besar dan bahkan berhenti saat menemukan, sublime tidak memiliki integrasi fitur "git" dan "debug" di luar kotak .... memperkenalkan muti-root akan memperkenalkan banyak masalah terkait integrasi git, mencari tanpa berdampak pada kinerja ... bahkan UX terpengaruh, seperti menjelajahi masalah srcoll dalam proyek besar.

Aneh, bagi saya justru sebaliknya.

Mungkin karena 99% dari waktu saya hanya memasukkan apa yang saya butuhkan ke Sublime atau Atom :) dan itulah yang kami inginkan.

Mungkin hanya cara Anda menggunakan editor. Saya terbiasa menggunakan CMD / CTR + P dan mengetik file persis seperti yang saya inginkan. Ini tidak mungkin jika Anda harus menyertakan root proyek dengan banyak file duplikat. (kartrid / file tertinggal di sana untuk membandingkan apa yang asli :)) atau sesuatu seperti wordpress di mana ada banyak file dengan nama yang sama.

Halo,
Ya, ide beberapa folder baik-baik saja tanpa merusak banyak hal. Setiap folder tambahan bisa menjadi subbagian baru dengan awalan untuk menunjukkan bahwa itu asing untuk folder utama. Primer digunakan untuk debugging dan Git. Seorang pengguna dapat mengklik kanan pada folder asing mana pun dan menjadikannya sebagai folder utama . Apa yang Anda dapatkan:
1) dapat melihat semua folder dan file Anda dan membukanya sesuai kebutuhan.
2) memikirkan kembali apa yang utama untuk dikerjakan.

Sekarang jika seseorang ingin membuka beberapa proyek sekaligus, mereka harus membuka permintaan masalah baru. Itu menambah kompleksitas signifikan yang diuraikan oleh banyak orang. Plugin tidak sama dengan bawaan. Jika ada editor yang memiliki fitur built-in yang cocok, itu harus diarahkan agar pengembang lain dapat memeriksa bagaimana alur kerja mereka sesuai dengan fitur tersebut. Terima kasih. Selamat siang.

Tambahkan saya ke daftar pengguna yang menganggap ini satu-satunya pemecah kesepakatan yang mencegah saya pindah ke VSC. Saya menemukan implementasi Sublime Proyek tepat. Jika saya perlu mengerjakan aplikasi "Volunteer Hours" misalnya, saya membuka proyek yang telah saya isi dengan folder berbeda (folder proyek utama serta folder lain yang berisi gambar). Itu adalah perangkat kerja saya untuk proyek itu. Jika saya perlu beralih ke aplikasi "Exchange Calculator", saya dapat menukar seluruh rangkaian kerja ke proyek itu atau membuka jendela baru dengan proyek itu di dalamnya.
Kasus penggunaan lainnya adalah saat menggunakan CMS. Jika saya mengerjakan plugin untuk CMS, saya dapat memiliki satu project untuk plugin tersebut yang merupakan repositori Git dan satu lagi untuk seluruh CMS, yang bukan Gitified. Saya dapat beralih di antara keduanya sesuai kebutuhan dan memisahkan masalah Git saya.
VSC tampak seperti masa depan bagi saya, tetapi bukan tanpa kemampuan untuk memisahkan kumpulan folder yang berfungsi.

Halo,
Saya hanya melihat bahwa Sublime Text memiliki dukungan untuk proyek dengan file proyek . Apa persamaannya dengan apa yang diminta di sini? Kedengarannya seperti permintaan vscode untuk mendukung file proyek dalam ruang kerja. Ada komentar sebelumnya tentang ekstensi yang dapat menangani hal-hal yang berkaitan dengan manajer proyek .

Sejujurnya saya juga menggunakan Atom dan saya menggunakan fungsi multi folder (built-in) yang memungkinkan saya memiliki folder dokumentasi dan folder proyek saya saat ini terbuka pada saat yang bersamaan. Ini benar-benar tampak seperti buah gantung yang lebih rendah untuk hanya mengaktifkan primer dan sekumpulan sekunder. Mungkin panah sederhana atau mulai menunjukkan yang utama. Terima kasih. Selamat siang.

Untuk apa nilainya, inilah kasus penggunaan saya. Saya mengerjakan game yang dibagi menjadi tiga repositori; satu repo Git untuk mesin, satu repo hg untuk kode game + konten dan satu hg untuk kode game yang umum di banyak proyek. Ada juga satu repo hg untuk plugin Sublime Text perusahaan. Repo generik adalah subrepo dari game-repo.

Di tempat kerja saya berikutnya, saya berharap dapat bekerja dengan banyak repositori lagi.

Sangat mudah untuk memiliki semua ini dalam contoh editor yang sama, dan saya pikir akan masuk akal jika semua ini mendapatkan SCM yang tepat di VS Code.

Saya mengharapkan pencarian untuk mencari melalui semua folder yang dipetakan secara default. Bonus yang bagus adalah dapat mengaktifkan / menonaktifkan folder mana yang akan dicari, untuk sementara. (Misalnya, ketika saya hanya tertarik untuk menemukan sesuatu di mesin game)

Ada banyak orang yang mengatakan bahwa VS Code seharusnya tidak mendukung ini karena A) Mereka tidak membutuhkannya dan B) VS Code adalah editor teks sederhana. Alasan pertama tidak bagus - hanya ada sedikit fitur yang digunakan oleh semua orang. Alasan kedua ... VS Code bukan hanya editor teks sederhana, ia memiliki debugging, SCM, plugin. "Editor teks sederhana" lainnya seperti Sublime memiliki dukungan banyak folder. Dan sebagai seseorang yang bersikukuh tentang kinerja, saya tidak dapat melihat bagaimana menambahkan fitur ini akan memengaruhi kinerja dengan cara yang berarti, terutama bagi orang yang hanya menggunakan satu folder. Bisakah kita memfokuskan diskusi pada bagaimana kita ingin fitur itu bekerja daripada mengapa kita tidak menginginkannya.

@Srekel dapatkah Anda menyertakan tangkapan layar tentang cara Anda bekerja seperti ini di editor Anda saat ini? Kedengarannya seperti campuran folder dan proyek yang menggunakan built-in dan plugin. Mudah-mudahan orang-orang di kamp A itu tidak akan menyadari perubahan untuk memasukkan fitur semacam ini. Bagi orang-orang kamp B , mereka benar. Anda dapat melakukan berbagai hal dengan cepat menggunakan aplikasi di luar kotak jika Anda tidak perlu macet. Memegang dekat dengan itu mungkin membantu memiliki siklus pembaruan yang cepat dan elemen antarmuka yang tidak berantakan.

Beberapa hal tentang bagaimana melakukannya meliputi:

• memahami hubungan ruang lingkup, konteks, sesi, pandangan dan saat ini .
• batas atas (lebih dari 256 folder?)
• area yang terkena dampak utama (tab editor, pengaturan, scm, git, ekstensi).
• penggantian pengaturan ruang kerja atau konflik.

Akan menyenangkan di sini tentang beberapa hal yang VSCode terima begitu saja di area ini yang membutuhkan kompensasi. Terima kasih. Selamat siang.

+1

+1. Saya memiliki 30+ modul masing-masing dengan repositori git sendiri yang ingin saya akses dan kerjakan dalam satu lingkungan. Saya pikir itulah yang dilakukan kebanyakan pengembang js / node. Dengan VSCode ini tidak mungkin, bagi saya pemecah kesepakatan dengan menyesal.

+1

Sudah buka sejak 2015 dan masih belum diperbaiki. Ini adalah fitur yang paling dicari di editor mana pun, tetapi sayangnya vscode tidak memilikinya.

+1

Saya terus-menerus membingungkan satu jendela VS Code dengan yang lain ketika perintah tabbing.

Setiap editor lain yang saya tahu memiliki ini (Atom, Sublime, Brackets ...)

Menambahkan symlink ke proyek saya adalah sebuah retasan dan mengharuskan saya memperbarui .gitignore saya. Membuka direktori induk mengganggu karena panel file saya dibanjiri dengan proyek lain yang tidak saya pedulikan.

Rencana iterasi bulan April menampilkan tugas "Selidiki ke ruang kerja multi-root, multi-folder" sebagai selesai. Apa hasil penyelidikannya?
@bpasero @tyriar

+1

Maaf jika saya terlalu bersemangat. Kalian sibuk merilis kode sekarang.

Halo,
Dialog Open Folder harus dianggap sebagai Open Folders. Jadi jika saya berada di bawah folder induk tertentu, saya bisa dalam dialog menyorot dua atau lebih sub foldernya untuk dibuka pada saat yang sama. Itu akan menjadi tambahan yang disambut dengan memasukkan fitur ini. Terima kasih. Selamat siang.

+ satu sama lain

Belum pernah melihat begitu banyak komentar dengan upaya rendah di utas GitHub sebelumnya, terutama pasca-emoji. Astaga.

Saya sangat menyukai fitur ini. Seperti orang lain akan katakan, banyak proyek modern yang modular misalnya frontend di satu repo / proyek dan backend / api di yang lain. Anda akan sering ingin mengerjakannya bersama sebagai satu kesatuan.

Inilah satu-satunya alasan saya belum menyerah pada Atom.

Layanan mikro dan platform tanpa server, dikombinasikan dengan mantra lama "repo adalah murah", adalah mengapa ini harus dimiliki. Bukan hal yang aneh untuk memiliki ~ 30 repositori [kecil] yang terbuka dan mengerjakan file dari beberapa proyek secara bersamaan; mengharapkan orang untuk beralih di antara banyak jendela itu, atau memindahkan pengaturan tampilan file ke pengelola jendela lingkungan desktop tidak akan berfungsi.

Halo,
Bagaimana Anda mengelola 30 repo Anda sekarang @martellaj ? Kedengarannya mengerikan bekerja langsung dengan banyak file yang terbuka. Saya cenderung memiliki banyak pustaka yang saya kerjakan tetapi saya mendapatkan kebutuhan yang signifikan untuk mengerjakan backport fitur yang berguna untuk dibagikan, saya sengaja menutup semua jendela edit saya yang lain. Saya membuat tes, memperbarui file konfigurasi dan opsi proyek untuk membuat saya berfungsi, lalu saya kembali ke tampilan sebelumnya. Itu mungkin masih 3 atau 4 jendela lainnya.
Apakah Anda melakukan ini karena keterbatasan lain di lingkungan Anda? mungkin bahasa pemogramannya tidak memiliki intellisense? Mungkin ekstensi yang dapat membaca API untuk memberi Anda tanda tangan fungsional akan membantu?
Bahasa seperti F # memiliki fitur yang disebut penyedia tipe, salah satunya dapat melakukan hal itu dan membuat pemrograman web lebih mudah. Ini bukan untuk mengurangi kebutuhan Anda akan banyak folder, hanya saja Anda mungkin masih memiliki setidaknya beberapa masalah lain dengan ruang kerja aktif yang begitu besar. Terima kasih. Selamat siang.

@ pr-yemibedu, menurut saya yang dikatakan @martinjco adalah dia tidak membuka file tetapi dia akan memiliki akses cepat ke repo jika kami memiliki struktur multi-root. Bayangkan, cukup CMD + P ke file apa pun yang Anda butuhkan;)

Masalah dengan situasi saat ini adalah bahwa kita HARUS membuka file atau setidaknya beralih di antara 30 jendela yang berbeda karena VScode tidak mendukungnya.

Saya sebenarnya beralih kembali ke Atom baru-baru ini karena fitur yang hilang. Saya sedang mengerjakan proyek dengan 9 repo saat ini. Saya tidak ingin 9 janda VScode terbuka pada saat yang sama, tetapi saya hanya ingin menggunakan pintasan untuk membuka file yang saya butuhkan.

Setuju dengan Komentar oleh @dariusrosendahl. Saya seorang pembuat kode pemula dan saya harus merujuk proyek lama untuk menulis yang baru. Mudah-mudahan, itu akan segera berubah tetapi secara luhur saya dapat dengan mudah memiliki tiga hingga empat folder proyek dan membandingkannya agar terbuka di sesi yang sama

Jika kita bisa mendapatkannya di studio visual, itu akan bagus

Halo,
Saya setuju dengan poin yang dibuat karena Anda dapat melihat posting saya sebelumnya menyukai fitur ini. Ada pernyataan persis yang saya komentari oleh martinjco:

Bukan hal yang aneh untuk memiliki ~ 30 repositori [kecil] yang terbuka dan mengerjakan file dari beberapa proyek secara bersamaan;

Apa yang nuno1895 tunjukkan adalah bagaimana saya menggunakan Atom hari ini ketika saya perlu bekerja pada banyak folder tetapi proyek fokus utama yang sederhana. Saya sebenarnya menggunakan baik VS2015, gedit, vim, notepad, dan notepad ++ untuk pengembangan aktif. Ada kekuatan di masing-masing yang belum ada padanannya di rekan-rekan mereka.

Saya hanya mencoba memahami jika ada poin inti yang bisa diperjelas. Kami semua ingin ini dikerjakan dan disukai oleh pengembang yang akan menghabiskan waktu untuk itu. Itulah mengapa saya bertanya bagaimana ini ditangani hari ini. 9 vs 30 mungkin tidak akan menarik minat saya untuk merespons tetapi saya ingin tahu apa yang orang bandingkan dengan vscode dan apakah itu layak untuk saya bahkan melihat alat lain.

Saya hanya melihat Atom dan SublimeText dibicarakan sebagai dasar perbandingan dan dengan screenshot yang berguna. Lebih banyak diskusi, jempol, dan umpan balik disambut untuk menerima dan menerapkan ini. Terima kasih. Selamat siang.

Satu hal yang mungkin belum cukup ditekankan adalah kemampuan untuk dengan cepat "beralih" di antara kumpulan folder (proyek). Ini disebut "Proyek Peralihan Cepat" di Sublime. Ketika Anda mengklik item menu itu, Anda mendapatkan pop-up dengan daftar semua proyek Anda, ketika Anda memilih salah satu proyek, editor menampilkan folder (s) dan semua file terbuka Anda saat terakhir meninggalkannya.
Misalnya, jika saya bekerja di Proyek A dan membuka file app.js dan index.html dan kemudian beralih ke Proyek B, itu akan menutup Proyek A dan menampilkan Proyek B. Jika saya kemudian beralih kembali ke Proyek A, itu akan tunjukkan folder dan app.js serta index.html seperti yang saya tinggalkan (bahkan hasil edit yang belum disimpan ada di sana).
Jika saya perlu membuka kedua proyek pada saat yang sama, saya bisa membuka dua editor.
Kuncinya adalah saya bisa menyimpan semua barang saya di ember terpisah dan saya bisa beralih di antara mereka dengan cepat.

+1

Halo,
Saya membaca tentang fitur itu. Beralih proyek tanpa menjelajah di Sublime Text menunjukkan beberapa hal yang baik dan buruk. Alangkah baiknya mungkin menyandikan beberapa folder yang terbuka di file pengaturan ruang kerja. Jika file tersebut tampaknya berada di tempat yang salah, maka sesuatu seperti folder.json dapat dibuat untuk mempertahankan status saat ini dari folder dan file apa yang tersedia dan terbuka untuk set kerja saat ini. Terima kasih. Selamat siang.

Saya mulai menggunakan VSCode beberapa bulan yang lalu dan, secara umum, saya sangat puas. Saya akan menambahkan suara saya ke paduan suara dan mengatakan bahwa fitur yang hilang ini adalah penggaruk kepala besar bagi saya. Apakah ada _any_ editor layak lainnya yang memiliki batasan ini? Bagaimanapun, itu harus diperbaiki. :)

Inilah pengaturan di pekerjaan baru saya:
Satu repo untuk teknologi inti. Katakanlah pathnya adalah C: / mygamengine /
Satu repo untuk kode game. Ini disinkronkan ke C: / mygamengine / mygame
Satu repo untuk konten game (tekstur dll): C: / mygamengine / mygame_data

Ketiganya git. Mereka tidak diatur sebagai sub repo, mereka hanya disinkronkan ke folder tersebut.

Lebih disukai saya hanya ingin membuka folder root di VS Code dan membuatnya secara otomatis mengetahui bahwa itu pada dasarnya adalah tiga proyek yang berbeda, dan bahwa file di bawah mygame adalah milik repositori git dan bukan yang ada di mygameengine.

Saya ingin dapat menyetel pengaturan untuk ruang kerja ini yang berbeda untuk setiap repositori (misalnya, saya mungkin ingin menjalankan linter pada proyek mesin tetapi tidak pada kode permainan). Akan lebih baik jika pengaturan ruang kerja secara default ditetapkan pada ketiga proyek.

Wah, ini masih belum terselesaikan? Saya berharap untuk mengganti Atom dengan VS Code karena, menurut review, ini jauh lebih cepat dan tidak ketinggalan seperti Atom.
Proyek utama saya adalah dua repo Git, satu ujung belakang dan yang lainnya ujung depan. Secara lokal keduanya berada dalam folder yang sama tetapi jika kode Atom atau VS membuka folder induk tersebut maka tidak ada status Git yang dikenali.
Di Atom saya hanya menambahkan kedua folder ke ruang kerja saya dan berfungsi.

: sparkles: Pembaruan: sparkles:

Sudah lama sejak pembaruan terakhir kami, jadi saya pikir saya akan mempercepat semua orang. Saya sendiri, @bpasero dan anggota tim lainnya telah mengidentifikasi sebagian besar masalah dengan penerapan multi-root dan saat ini sedang mengerjakan beberapa mock up dan mencari tahu lebih banyak tentang UX secara spesifik.

Mengapa begitu lama?

Butuh waktu lama karena fitur ini bukan satu-satunya tanggung jawab kami dan pekerjaan yang terlibat dalam mewujudkan multi-root cukup besar. Sebagai permulaan, semua komponen dalam VS Code dirancang dengan asumsi bahwa hanya ada satu folder atau tidak ada folder yang dibuka pada waktu tertentu. Ketika Anda memiliki basis kode sebesar milik kami dengan asumsi seperti ini, dibutuhkan banyak usaha untuk membuatnya lebih fleksibel.

Untuk memberikan beberapa contoh, berikut adalah beberapa poin masalah terbesar yang telah kami identifikasi sejauh ini:

• API ekstensi memperlihatkan satu workspace.rootPath , ini tidak cukup ketika kami menambahkan dukungan untuk folder multi-root. Kami ingin menghindari pemutusan ekstensi ini dan menyediakan jalur migrasi jika perlu.
• Cara pengaturan ruang kerja berinteraksi di dunia multi-root sedikit berbeda. Ambil workbench.statusBar.visible sebagai contoh yang saat ini diperbolehkan dalam pengaturan ruang kerja. Kami tidak dapat lagi mendukung ini karena akan menyebabkan perilaku aneh / bermasalah jika ditentukan dalam 2 folder. Kami sedang mencari cara untuk menangani kasus-kasus semacam ini.
• Penyedia SCM (git) mungkin membutuhkan jumlah kerja UX terbesar untuk mendukung banyak folder: Apakah kita perlu memperkenalkan konsep "proyek aktif"? Haruskah diatur secara eksplisit (klik kanan folder dan setel) atau harus implisit (lihat folder file yang aktif)? Haruskah itu konsep global atau terbatas pada fitur khusus itu? dll.

Kami tidak ingin terburu-buru dengan solusi yang dipikirkan dengan buruk, jadi kami meluangkan waktu kami dan benar-benar memikirkan masalah potensial dan implikasinya dengan bagaimana hal ini akan memengaruhi setiap komponen. Ini akan datang jika sudah siap.

Ringkasan komentar sampai saat ini

Saya hanya menghabiskan beberapa jam menelusuri utas yang sangat besar untuk menyusun umpan balik sejauh ini. Agak sulit untuk mengkategorikan beberapa hal ini, tapi inilah yang orang-orang cari secara umum (saya parafrase).

• Saya ingin integrasi git di beberapa folder
• Peralihan folder saat ini dan / atau manajemen jendela OS UX tidak praktis
• Saya ingin mencari di beberapa folder
• Saya ingin men-debug di beberapa folder

Kekhawatiran

• Apakah refactoring bekerja di seluruh proyek atau pada satu proyek?
• Proyek apa yang saya lakukan di Git?
• Di folder mana pencarian saya akan berjalan?
• Jangan merusak pengaturan ruang kerja
• Jangan merusak ekstensi - peringatkan pengembang ekstensi tentang API baru
• UX tab bergaya Slack tidak cukup bagi saya, itu pada dasarnya hanya memindahkan manajemen jendela dari OS ke VS Code - Saya ingin dapat mengakses semua file dari proyek dalam satu Jendela (mis. Kumpulan grup editor)
• "Dalam pengertian saya, ini memperkenalkan banyak masalah lain, banyak proyek berakar untuk git, cari ..... INI SANGAT BURUK untuk UX dan berpotensi memperkenalkan bug dan kompleksitas ke editor."

Komentar lain

• Saya hanya ingin membuka subset repo di "folder git" saya
• Saya ingin cara yang bagus untuk mencari dalam satu folder atau mengatur hasil pencarian berdasarkan proyek
• Saya ingin dapat menavigasi ke kode ketergantungan untuk membaca dengan cepat
• Saya ingin menjalankan versi TypeScript yang berbeda untuk folder yang berbeda
• VS Code terlalu lambat dengan repo raksasa
• Saya ingin membuat beberapa proyek selalu terbuka untuk digunakan sebagai referensi (mis. Tema / template)
• Saya ingin VS Code mengenali file .vscode / settings.json di direktori mana pun (ini akan membantu mengatasinya)
• Biarkan saya mendefinisikan root proyek (pencarian / debug) dan root git
• Sublime menangani integrasi git multi-folder dengan elegan
• Folder bertab yang mirip dengan UI Slack (mis. Beberapa paradigma proyek aktif)
• Bagian terpisah di penjelajah untuk setiap folder
• Gunakan folder sebagai primer dan sisanya sebagai link / sub-folder
• Saya ingin proyek sakelar cepat seperti di sublim (sakelar cepat + mempertahankan tata letak ruang kerja)
• Gaya manajemen ruang kerja ini sangat berguna untuk yang berikut: modul npm, julia, heroku PaaS, wordpress, drupal

Solusi saat ini

Berikut adalah solusi utama saat ini:

• Membuka orang tua bersama
• Manajer Proyek Git
• Manajer proyek
• Symlink folder sebagai sub direktori dari "folder master"

Kapan berkomentar?

Harap hindari: +1: atau komentar "Saya ingin ini". Ketika sebuah komentar dibuat tentang masalah ini, 153 orang yang mengomentari dan terus bertambah akan diberitahu selain banyak lagi yang menekan tombol berlangganan. Berkomentar juga akan mengubur pembaruan tim, jadi cobalah untuk memperhatikannya. Bagaimanapun juga, beri komentar jika itu menambah percakapan.

Sebuah fitur yang akan memiliki lebih banyak kegunaan daripada memiliki banyak root adalah menambahkan kemampuan untuk memiliki set kerja yang dapat dikonfigurasi. Ini akan memungkinkan Anda untuk membuka orang tua bersama, tetapi memiliki banyak kombinasi folder dalam proyek ini.

Umumnya ini akan berguna untuk proyek apa pun karena dapat "fokus" pada file / folder tertentu pada satu waktu dalam basis kode yang lebih besar tanpa harus mengubah konfigurasi untuk seluruh root setiap saat.

TIDAK ada rencana tentang fitur ini?

Anda dapat melihat rencana fitur ini di komentar @Tyriar dan di tautan terkait ini:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

Kami ingin membagikan desain kami untuk ini dan mendapatkan tanggapan Anda. Untuk melakukan ini, kami akan menyiapkan sejumlah panggilan konferensi di mana kami akan membahas desain kami dan mendiskusikan reaksi Anda terhadap desain.

Jika Anda ingin ikut serta dalam diskusi ini dan membantu kami mendapatkan desain yang benar, silakan hubungi saya (kirimi saya email - stevencl di microsoft dot com) dan saya akan menyiapkannya.

Kami berharap untuk menjadwalkan diskusi ini untuk Kamis 1 Juni dan Jumat 2 Juni.

@Tyriar @stevencl Terima kasih teman-teman! :tepuk:

Terima kasih semuanya telah bergabung dengan sesi hari ini. Rekaman sesi telah diposting di sini

• grup 1 - https://youtu.be/48Y6tB3DN1g
• grup 2 - https://youtu.be/kHL6Rt-dLm0

Silakan tonton video dan bagikan komentar tambahan yang Anda miliki tentang desain.

@stevencl terima kasih telah menjalankan studi dan menyediakannya!

Video bagus, terima kasih! Beberapa umpan balik:

• 👍👍👍 untuk keseluruhan desain sederhana dan perluasan alami tentang cara kerja VSCode saat ini. Kalian menangani banyak situasi kompleks dengan cara yang sederhana dan elegan. Pujian untuk itu!
• Saya suka notifikasi SCM teragregasi di pojok kiri bawah, tidak ada perubahan yang diperlukan dari sudut pandang saya dengan satu pengecualian: Saya akan melewati popup setelah mengklik notifikasi SCM dan langsung menuju ke panel SCM. Lebih sedikit klik = selalu lebih baik bagi saya.
• Akar pengkodean warna seperti yang disarankan Alexey adalah ide yang menarik, dapat membantu.
• Pencarian: pelingkupan ke folder akan menjadi penting bagi saya, saya kira bidang "file untuk disertakan" saat ini dapat digunakan untuk itu dengan baik, hanya ingin memastikan.
• Satu-satunya hal yang saya tidak yakin adalah ketekunan dan membuka semua additionalFolders ketika saya membuka path . Agak masuk akal dengan contoh terakhir di mana express-project jelas merupakan "proyek utama" tetapi saya tidak yakin tentang contoh sebelumnya: express dan express-plugin terasa sama, seperti saudara kandung sejati, dan saya tidak yakin saya berharap membuka express juga akan membuka express-plugin .
  
  
  
  • Di satu sisi, struktur data di balik ini terasa seperti hanya berupa daftar jalur datar, bukan satu "jalur" lalu "folder tambahan".
  
  
  • Saya tidak yakin apakah konsep satu jalur utama bisa berguna. Dalam proyek saya, mungkin tidak.
  
  
  • Untuk membuka ruang kerja multi-root, saya mengharapkan perintah tingkat atas seperti _File> Buka ruang kerja_ selain _File> Buka folder_ saat ini.
  
  
  • Secara keseluruhan, saya tidak terlalu yakin tentang ini. Maaf, saya tidak punya saran yang lebih konkret.
  
  

Sekali lagi terima kasih, dengan ini, VSCode akan mendapatkan kekuatan super baru 😄.

Terima kasih telah membagikan videonya. Saya ingin mendukung desain "satu bagian per folder root":

Pada awalnya, saya mengharapkan desain lain (seperti teks luhur), tetapi setelah melihat alternatif "satu bagian per folder root", menjadi jelas bagi saya bahwa pendekatan ini memiliki keuntungan sebagai berikut:

• Perbedaan yang jelas dan tidak ambigu dan pemisahan antar folder (terutama jika saya memiliki lebih dari 2 atau 3 folder, yang sering terjadi saat saya menggunakan editor dan IDE lain)
• Menerapkan anggapan bahwa folder root adalah (sub) proyek terpisah
• Akses cepat ke perintah sub-proyek (seperti "file baru", "segarkan" ... dan, mungkin di masa mendatang, mengklik kanan untuk meluncurkan tugas (misalnya "membangun kembali") pada sub-proyek tertentu;))
• Seperti yang disebutkan oleh grup ke-2, dengan desain ini, kecil kemungkinannya untuk mengalami masalah pemotongan nama folder

Mengenai konsep "satu bagian per folder root" ... Saya benar-benar tidak yakin ini akan bekerja dengan baik untuk saya dan sebagian besar kasus penggunaan saya. Kapan pun saya memiliki situasi multi-root, biasanya saya memiliki banyak ; bukan hanya 2 atau 3.
Saya tidak yakin bagaimana pendekatan ini akan berkembang?

Juga beberapa argumen untuk tata letak seperti folder saat ini adalah bahwa itu konsisten dengan bagaimana monorepo akan ditampilkan. Misalnya, bandingkan:

monorepo/      <- contains .git
  project1
  project2

vs.

microservices/
  project1      <- contains .git
  project2      <- contains .git

Keduanya harus diperlakukan sangat mirip dengan VSCode: monorepo sudah (melakukan: natural, cari: "file untuk disertakan", beberapa README: folder mereka ditampilkan di tab editor; dll.). Multi-root harus mengikuti ini sedekat mungkin, IMO, yang dapat dilakukan dengan sangat baik oleh desain saat ini.

@stevencl Satu hal yang tidak sepenuhnya saya mengerti: akankah solusi tersebut membawa perlakuan .vscode ? Misalnya, jika saya memiliki .vscode per folder level teratas, apakah pengaturan tersebut akan diterapkan secara individual? Apakah mereka akan dikumpulkan di root proyek? Atau akankah hanya .vscode "utama" yang dihitung?

Saya lebih suka desain "satu bagian per folder root", karena alasan yang sama yang dicantumkan oleh @maddouri. Selain itu, setelah menggunakan alternatif lain (di Atom), secara visual lebih sulit untuk menemukan di mana folder root baru dimulai ketika beberapa folder dengan hierarki tinggi terbuka dan diperluas.

Terima kasih atas pembaruan desainnya, terlihat sangat bagus!

Apakah ada kemungkinan untuk memiliki beberapa ruang kerja yang tersedia sekaligus di UI? Sehingga Anda dapat dengan mudah beralih di antara keduanya. Misalnya, Anda memiliki sesuatu seperti:

EXPRESS, EXPRESS-PLUGIN
  express/
    lib/
    test/
    package.json
  express-plugin/
    lib/
    test/
    package.json
CONNECT, CONNECT-PLUGIN

Dan kemudian mengklik / mengklik dua kali pada pembagi CONNECT, CONNECT-PLUGIN akan beralih menjadikannya sebagai ruang kerja aktif. Ini akan memungkinkan peralihan yang mudah antar ruang kerja bagi orang-orang yang harus menangani banyak rangkaian proyek. Saya tidak menyarankan bahwa semuanya tersedia untuk pencarian dan SCM dan yang lainnya, yang akan tetap dengan ruang kerja saat ini yang saat ini diperluas.

Itu kemudian bisa bekerja dengan memiliki folder root yang disorot seperti yang disarankan di grup pertama, dan mungkin memiliki ikon file / folder baru tersedia saat mengarahkan kursor ke folder tersebut.

Beberapa umpan balik tentang pengaturan JSON, mungkin berguna untuk pengaturan ruang kerja menjadi seperti:

workspaces: [
    {
        name: "Express Project",
        root: "file://C:/workspace/",
        folders: [
            "./express/",
            "./express-plugin/"
        ]
    }
]

Jadi root menjadi sumber untuk membuka folder, bukan jalur, tetapi root itu sendiri tidak dibuka, hanya setiap folder. Anda kemudian tidak memiliki "folder utama", tetapi masih mempertahankan jalur file relatif. Ini mengasumsikan bahwa Anda dapat membuka ruang kerja yang telah ditentukan sebelumnya melalui UI, bukan membuka folder root dan semua folder tambahan dengannya. Nama tersebut kemudian dapat digunakan sebagai pemisah yang mencegah sejumlah besar nama folder menjadi terlalu panjang, atau disingkat tanpa bantuan.

Jika solusi "satu bagian per folder root" dipilih, saya ingin menyarankan agar folder root yang saat ini terlihat "menempel" ke bagian atas bilah sisi, alih-alih menggulir keluar dari tampilan. Itu hanya akan menggulir ke atas setelah folder root berikutnya mencapai bagian atas sidebar.

Pada 4 Juni 2017, pukul 06.47, Peter Petrov [email protected] menulis:

Saya lebih suka desain "satu bagian per folder root", karena alasan yang sama yang dicantumkan oleh @maddouri. Selain itu, setelah menggunakan alternatif lain (di Atom), secara visual lebih sulit untuk menemukan di mana folder root baru dimulai ketika beberapa folder dengan hierarki tinggi terbuka dan diperluas.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Atau kita dapat mengikuti Sublime, pendekatan Atom, tetapi mengubah warna atau menunjukkan folder mana yang merupakan root dan / atau menempelkannya di atas. Tentu saja kedua pendekatan itu bagus, tetapi memiliki banyak folder yang terbuka mengurangi ruang, karena bilah dengan penyegaran, buat file baru, dll. Akan terlihat, itulah mengapa lebih baik tidak memuat bilah, tetapi entah bagaimana menunjukkan folder mana yang akar. TAPI lagi, bilah ini sangat bagus, karena jauh lebih mudah untuk melihat folder root yang dibuka dan Anda dapat menyegarkannya serta melakukan hal-hal lain yang termasuk dalam bilah. Kita perlu melihat bagaimana tampilannya dengan misalnya 10 folder dibuka dengan dan tanpa bilah.

@stevencl Terima kasih telah memposting rekaman itu! Secara keseluruhan, saya senang dengan arah kemana fitur ini mengarah! Terima kasih untuk semua waktu dan upaya yang telah dilakukan sejauh ini. Ini tanggapan / pemikiran saya:

• Saya lebih suka desain pertama dengan desain bilah nama folder tunggal di bawah "EXPLORER", namun, saya khawatir jika semua nama folder tercantum di sana, itu akan sangat cepat terpotong untuk menampilkan "tambahkan file", " tambahkan folder ", dll., tombol. Saya rasa saya hanya akan meletakkan string "Multiple" atau sesuatu yang serupa ketika lebih dari satu folder terbuka; jika tidak, hanya ada satu folder jadi letakkan nama folder di sana seperti yang dilakukan hari ini (dan sembunyikan root folder di pohon).
• Disambiguasi nama file dengan menambahkan nama folder di judul tab di Editor, IMO, tidak diperlukan kecuali ada beberapa editor yang terbuka dengan nama file yang sama. Perhatikan bahwa skenario ini tidak jarang terjadi bahkan dengan satu folder terbuka. Sangat mudah untuk mendapatkan banyak file (mis. .gitignore ) dengan nama yang sama di antara subfolder dalam root yang sama. Jadi desain ini (menambahkan nama folder induk) harus menjadi fitur terpisah, IMO, dan harus diimplementasikan. Bersamaan dengan ini, saya ingin melihat solusi yang bagus untuk https://github.com/Microsoft/vscode/issues/15048 karena ini akan membuat beberapa judul tab menjadi lebih panjang. :)
• Untuk hasil pencarian, menurut saya sangat penting bahwa pencarian bekerja di semua folder root. Filter lain dapat ditambahkan untuk membatasi pencarian ke root yang dipilih. Saat menampilkan hasil, mungkin berguna untuk melihat hasil per root, jadi mungkin opsi untuk melihat satu daftar panjang dengan nama folder root ditambahkan, atau untuk melihat daftar yang dipisahkan dalam beberapa bagian, satu untuk setiap folder root.
• Saya merasa aneh bahwa Anda mengusulkan untuk menambahkan 'ruang kerja' ke __pengaturan pengguna__. Saya benar-benar berharap ini berakhir di __setelan ruang kerja__. Saya pikir_ Anda sebenarnya mengatakan bahwa pengaturan ruang kerja juga dapat berisi properti 'ruang kerja' baru, yang bagus. Ini juga sangat bagus bahwa jalur ruang kerja bisa relatif. Sepertinya itu bukan sesuatu yang dimiliki sama sekali dalam pengaturan pengguna. Ini adalah fitur yang terasa sangat spesifik untuk ruang kerja. Ah, tapi sekarang saya mengerti mengapa ini juga valid dalam pengaturan pengguna, karena ini memberi saya cara untuk menyimpan ruang kerja ini ketika saya ingin folder "acak" di HDD saya dalam satu ruang kerja di mana tidak ada root yang sama.
• Satu hal yang tampaknya hilang di ruang kerja saat disimpan di pengaturan pengguna adalah kemampuan untuk memiliki pengaturan khusus proyek lainnya yang dikaitkan ke satu ruang kerja atau lainnya. Misalnya, jika saya memiliki ruang kerja di mana saya membutuhkan ukuran tab menjadi 2 ruang dan satu lagi harus 3, saya tidak akan dapat melakukannya dengan ruang kerja dalam pengaturan pengguna. Saya harus membuat folder di suatu tempat, lalu meletakkan folder .vscode di dalamnya, dan kemudian menentukan .vscode/settings.json untuk akhirnya menentukan ruang kerja saya dengan penggantian ukuran tab yang sesuai. Pada titik ini, saya berpikir bahwa membuat jenis file Proyek VSCode baru yang menyimpan semua pengaturan ini dan dapat dibuka sebagai file khusus menjadi jauh lebih praktis daripada harus membuat hierarki folder ini untuk menyimpan ruang kerja settings.json file ...

Dalam desain pertama, untuk folder tambahan, jalur (relatif atau absolut) dalam tanda kurung dapat ditambahkan ke nama untuk diferensiasi. Itu akan menjadi solusi sederhana menurut saya.

@stevencl terima kasih telah merekam sesi. Saya benar-benar ingin berpartisipasi tetapi tidak tersedia saat itu 😢

Saya menyukai antarmuka SCM yang diusulkan. Memiliki bagian ringkasan dan Satu bagian per folder memberi saya, IMHO, antarmuka yang jauh lebih mudah untuk mendeteksi dan bekerja dengan perubahan. Dan saya suka ide untuk memiliki perilaku yang konsisten di seluruh UI, jadi ide Satu bagian per folder harus digunakan di tab Pencarian juga, daripada menggabungkan nama folder di setiap hasil. Hal yang sama untuk tab Explorer .

Menggunakan Pengaturan Pengguna untuk menyimpan _Multi-Folder_ agak aneh bagi saya, karena _tampaknya bukan pengaturan pengguna_: smile : additionalFolder entry _always_ bagian dari Workspace Settings . Melakukannya, saat Anda _Tambahkan Folder_, itu hanya akan ditambahkan ke Workspace Settings . Kemudian, ketika membuka folder, Anda hanya mencari .vscode\settings.json berkas dan additionalFolders masuk di sana, untuk memeriksa _If ini adalah ruang kerja multi-folder_. _Ini mirip dengan contoh kedua yang Anda gunakan, tentang dua repos git yang hilang_.

SomeFolder.vscodesettings.json

{
    "editor.wordWrap": "off",
    "editor.codeLens": false,
    "editor.renderWhitespace": "all",
    "workbench.colorTheme": "Abyss",

    "additionalFolders": [
        "./express",
        "./express-plugin",
        "~/commons/other-stuff",
        "file:///C://Temp//oldlib"
    ]
}

Juga, dukung lokasi _user-data_ seperti ~ dan $home , sehingga lebih mudah untuk berbagi proyek antara komputer / platform yang berbeda.

Saya hanya melewatkan satu hal: API . Bagaimana ekstensi akan terintegrasi dengan itu?

Terima kasih atas usahanya. Menantikan rilis orang dalam pertama 👍

Terima kasih untuk umpan baliknya! Saya ingin menindaklanjuti arahan memanfaatkan properti pengaturan baru additionalFolders untuk mengimplementasikan "Multi Root" karena saya mendengar beberapa umpan balik tentang ini dari komentar di atas.

Motivasi utama untuk memperkenalkan pengaturan di tempat pertama sebenarnya untuk menjaga agar hal-hal tetap sederhana dan tidak memperkenalkan terlalu banyak konsep baru sambil tetap memiliki solusi yang kuat dan memungkinkan beberapa skenario yang menarik. Berikut beberapa keputusan dan konsekuensi desain:

Tetap sederhana
Kami merasa bahwa membuka file dan folder adalah inti dari VS Code. Karenanya kami tidak ingin memperkenalkan konsep tingkat atas yang baru dari "Proyek". Misalnya, kami tidak akan menganggap tindakan "Proyek Terbuka" diperlukan, melainkan berpikir bahwa proyek selalu berupa folder dan secara opsional dapat memiliki folder tambahan yang terkait. Dengan asumsi ini, pengaturan tampaknya merupakan cara alami yang memungkinkan untuk itu. Setiap kali Anda membuka folder ini, Anda membuka folder tambahan dengannya. Menambah dan menghapus folder adalah gerakan sederhana dan itu akan memperbarui pengaturan secara langsung.

Pengaturan sangat kuat
Memiliki multi root sebagai pengaturan memungkinkan banyak skenario menarik. Misalnya, Anda bebas memasukkan setelan additionalFolders ke dalam ruang kerja Anda dan karenanya membagikannya dengan orang lain (dengan menggunakan jalur relatif - ini ditunjukkan di video).
Selain itu, Anda juga bebas bagaimana Anda mengatur proyek di tempat pertama: misalnya, dalam beberapa kasus tidak ada hubungan yang jelas dari folder master ke folder tambahan (misalnya bisa jadi beberapa di antaranya bahkan tidak terkait dengan satu sama lain). Jika demikian, Anda dapat membuat folder "proyek" yang hanya menyertakan settings.json dengan folder yang ditautkan ke:

allMyRandomProjects/ 
  .vscode
    settings.json <- contains additionalFolders setting  

Sekarang ketika Anda membuka allMyRandomProjects itu akan menampilkan daftar folder berdasarkan pengaturan. Anda bahkan dapat menyertakan beberapa pengaturan di settings.json yang harus diterapkan ke semua folder yang ditampilkan.

Peralihan ruang kerja dan multi jendela
Tanpa ragu, kami perlu bekerja pada peralihan ruang kerja yang lebih baik dan dukungan multi jendela di VS Code. Karena kami memperlakukan ruang kerja multi-root sama seperti ruang kerja lain dengan folder, meningkatkan peralihan ruang kerja dan dukungan multi-windows akan menguntungkan pengguna mana pun, bahkan mereka yang tidak memanfaatkan ruang kerja multi-root.
Kita harus mencari cara yang lebih baik dan lebih mudah untuk beralih antar folder dan membuka jendela independen dari multi-root.

Dalam komentar saya berikutnya, saya akan memberikan beberapa umpan balik pada setiap komentar yang dibuat.

Pencarian @borekb akan menyertakan opsi untuk membatasi ke folder root tertentu (atau beberapa) dengan cara yang sama Anda dapat mengonfigurasi pencarian untuk menyertakan jalur tertentu saat ini.

@maddouri @TurkeyMan @pesho , @dgileadi @stefcameron tampak jelas bahwa beberapa orang lebih menyukai satu pohon dan yang lain lebih suka beberapa bagian dalam penjelajah. Jadi kita mungkin berakhir dengan pengaturan untuk ini, ada pro dan kontra untuk kedua solusi dan itu harus tergantung pada pengguna mana yang lebih baik untuk skenario tersebut.

@borekb bagaimana pengaturan diterapkan akan berubah sedikit tergantung pada apakah Anda dalam pengaturan multi-root atau tidak: pengaturan pengguna selalu berlaku untuk semua folder yang dibuka seperti sebelumnya. Pengaturan ruang kerja akan diambil dari folder utama ("master") dan diterapkan ke semua file dan folder yang terkait dengannya. Sekarang, Anda masih dapat menentukan pengaturan pada folder tambahan mana pun melalui pengaturan ruang kerja meskipun kami mungkin tidak mendukung semuanya. Misalnya, pengaturan seperti update.channel: none tidak dapat didukung per folder. Apa yang harus kita lakukan adalah mengidentifikasi pengaturan yang dapat kita dukung pada tingkat folder (mis. files.exclude , semua pengaturan editor) dan membuat perubahan yang diperlukan untuk mengaktifkannya. Ini adalah salah satu bidang pekerjaan utama yang harus kami investasikan, terutama karena ekstensi juga dapat menentukan setelan yang ingin kami dukung pada cakupan per folder.

@BTMorton menurut saya Anda ingin cara yang lebih mudah untuk beralih ruang kerja. Ini adalah sesuatu yang harus kita perhatikan secara independen dari multi-root untuk setiap transisi folder yang dapat dilakukan pengguna.

@stefcameron kami akan membiarkan pengaturan additionalFolders cukup terbuka untuk akhirnya menambahkan meta data tambahan padanya. Misalnya saya dapat memikirkan untuk dapat memberikan nama untuk konfigurasi seperti itu sehingga beralih antar proyek menggunakan nama dan bukan folder utama.

Satu hal yang belum kami sentuh di video adalah bagaimana ekstensi dapat mendukung folder multi-root. Tujuan utama lainnya dengan dukungan multi-root (selain "tetap sederhana") adalah: tidak merusak ekstensi

Saat ini, ekstensi memiliki API sederhana untuk mendapatkan akses ke ruang kerja yang saat ini dibuka ( workspace.rootPath: string ). Properti ini dapat menjadi null jika tidak ada folder yang dibuka.

Sekarang, dengan diperkenalkannya pengaturan additionalFolders , sebuah ekstensi masih dapat mengandalkan properti workspace.rootPath sedang disetel (jika folder dibuka), atau tidak (saat tidak ada folder yang dibuka). Karena additionalFolders sebenarnya adalah sebuah pengaturan, sebuah ekstensi bebas untuk membaca dan bahkan menulis ke pengaturan ini dengan API yang kita miliki saat ini di sekitar pengaturan. Bahkan ada peristiwa yang dipancarkan ketika pengaturan ini berubah, memungkinkan reaksi dinamis kepada pengguna yang mengubah pengaturan ini.

Membaca pengaturan ini memungkinkan ekstensi mengetahui folder tambahan di ruang kerja. Misalnya ekstensi Travis CI dapat memilih untuk menampilkan status gabungan di semua folder.

Menulis pengaturan ini memungkinkan beberapa skenario menarik untuk ekstensi: misalnya Anda dapat memiliki ekstensi manajer proyek yang secara dinamis menambah dan menghapus folder ke ruang kerja Anda dan dengan demikian memungkinkan transisi proyek dalam jendela, misalnya dengan menampilkan daftar proyek melalui UI alat pilih .

Pada satu titik kami mungkin akan memperkenalkan beberapa API ekstensi baru yang nyata untuk menangani folder multi-root. Mengubur ini di dalam pengaturan untuk ekstensi untuk membaca / menulis agak aneh. Namun untuk memulainya, ekstensi sudah dapat menjelajahi pengaturan additionalFolders untuk memanfaatkannya jika memungkinkan. Kami juga akan bekerja sama dengan penulis ekstensi untuk memahami skenario mereka dan cara mendukung mereka dengan lebih baik.

@bpasero Akankah konsep folder tambahan juga ditambahkan ke LSP, atau akankah VS Code memulai satu server bahasa per folder tambahan?

@felixfbecker ini adalah sesuatu yang masih harus kami investasikan dan jelajahi untuk menemukan solusi yang baik untuk ekstensi bahasa. Setelah kami memikirkan tentang API tambahan untuk ekstensi, kami juga perlu memikirkan tentang apa artinya ini bagi LSP.

Perlu disebutkan bahwa saat ini Anda sudah dapat mengalami situasi di mana pengguna membuka file dari folder yang tidak dibuka sebagai ruang kerja (misalnya File> Open> somefile.xyz). Idealnya, ekstensi bahasa dapat menunjukkan tingkat fitur bahasa yang sama untuk file semacam itu meskipun folder file itu tidak dibuka.

Pada awalnya, membuka file dari salah satu additionalFolders akan berperilaku sangat mirip dengan membuka file yang tidak ada di folder yang awalnya Anda buka. TypeScript misalnya dapat menangani kasus ini dengan baik: mereka hanya berjalan dari file yang saat ini dibuka hingga file tsconfig.json ditemukan dan kemudian memperlakukan ini sebagai proyek. Fitur seperti menemukan referensi berfungsi tanpa masalah:

Akan lebih baik jika ada ekstensi bahasa yang dapat bekerja dengan hanya pergi dari file yang sedang aktif daripada memaksa untuk memiliki konteks proyek yang eksplisit.

@bpasero terima kasih atas komentarnya. Jadi tampaknya dalam model saat ini, akan selalu ada folder "master" : bahkan dalam contoh allMyRandomProjects , ini pada dasarnya adalah folder master, meskipun sebagian besar kosong. Ini memiliki beberapa implikasi yang halus tetapi saya perlu memikirkannya lebih lanjut untuk memberikan umpan balik yang berguna.

Secara keseluruhan, saya pikir VSCode harus mendukung monorepo vs. beberapa repositori dengan cara yang sangat mirip, sesuai komentar di atas: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

BTW, bagaimana Anda mendefinisikan "root", tepatnya? Jika saya membuka folder A yang berisi subfolder B dan C, apa bedanya dengan mendefinisikan A sebagai path dan B dan C sebagai additionalFolders ? Apakah niat VSCode untuk memperlakukan kedua situasi tersebut secara berbeda atau pada dasarnya sama? (Saya pikir itu harus menjadi pengalaman yang sangat mirip.)

@bpasero

Pada awalnya, membuka file dari salah satu additionalFolders akan berperilaku sangat mirip dengan membuka file yang tidak ada di folder yang awalnya Anda buka. TypeScript misalnya dapat menangani kasus ini dengan baik: mereka hanya berjalan dari file yang saat ini dibuka sampai file tsconfig.json ditemukan dan kemudian memperlakukan ini sebagai proyek. Fitur seperti menemukan referensi berfungsi tanpa masalah:

TypeScript tidak menggunakan LSP. Di LSP, server bahasa memiliki rootUri , dan misalnya PHP akan menggunakan rootUri untuk memindai file yang perlu diindeks. Itu tidak memiliki file seperti tsconfig.json yang akan menunjukkan "proyek". Jadi jika ada file yang tidak dibuka melalui didOpen tetapi juga tidak di bawah rootUri , maka ini tidak akan dipertimbangkan untuk kecerdasan kode, oleh karena itu pertanyaan saya apakah LSP akan diperpanjang untuk ini.

Hanya untuk memperjelas, apakah membuka beberapa root akan membuat file ./.vscode/settings.json jika belum ada?
Dari apa yang saya baca di sini sejauh ini sepertinya kami mengatakan itu akan terjadi.

Saya mengerti mengapa berguna untuk menghindari penambahan konsep proyek, tetapi mungkin akan lebih baik untuk membuat penyimpanan ruang kerja opsional - meskipun dalam kasus ini, 'menyimpan' hanya berarti membuat file pengaturan di folder root.

Saya pikir itu mungkin mengejutkan pengguna yang belum mengikuti utas ini jika mereka membuka folder kedua dan itu membuat file pengaturan. Membuka folder adalah hal yang saya yakin sebagian besar pengguna harapkan bersifat hanya-baca.

Terima kasih untuk semua umpan balik semuanya, ini sangat berguna.

@saborrie - pertanyaan bagus tentang sejauh mana orang akan terkejut dengan pembuatan pengaturan setelah menambahkan folder. Kami perlu menyelidikinya untuk melihat apakah itu masalahnya (jelas sekali dengan orang-orang yang belum mengikuti utas ini :-)).

@borekb - kami telah membicarakan tentang skenario yang Anda sebutkan (membuka folder yang berisi satu atau lebih subfolder) dan kami cenderung memperlakukan ini sama seperti membuka ruang kerja multi root. Tantangannya adalah menentukan kapan harus memperlakukan situasi seperti itu sebagai multi root dan bukan hanya folder yang berisi folder lain.

Saya juga tertarik dengan apa yang orang lain pikirkan tentang ini.

@borekb Anda mengemukakan poin yang bagus, saya juga akan mengatakan bahwa jika Anda membuka satu folder yang berisi beberapa repositori git di dalamnya, tampilan SCM kami harus dapat menunjukkan kepada Anda tampilan yang sama seperti yang akan Anda dapatkan jika Anda mengatur ini secara eksplisit melalui additionalFolders properti. Saya pikir kita dapat mulai menjelajahi evolusi UI ini dengan folder yang memiliki pengaturan additionalFolders dan kemudian mengembangkannya ke lebih banyak kasus penggunaan. Skenario menarik dan terkait lainnya adalah bagaimana kami memilih untuk menyajikan submodul dalam repositori.

Saya juga akan berpikir bahwa pada akhirnya kami ingin mendukung pengaturan .vscode pada level hierarki folder apa pun setelah kami menyelesaikan tantangan yang menyertainya.

Saya akan berbicara lebih sedikit tentang hubungan master-detail ketika berbicara tentang multi-root karena sebagian besar UX akan memperlakukan folder utama sama dengan folder tambahan. Folder master sebenarnya hanyalah wadah pengaturan untuk folder tambahan dan akan menjadi pendorong utama untuk pengaturan ruang kerja global. Untuk kompatibilitas mundur, ini juga akan menjadi yang kami kirim ke ekstensi sebagai rootPath .

@felixfbecker apakah itu berarti saya tidak dapat melakukan "Temukan Referensi" atau fitur bahasa serupa saat membuka hanya satu file PHP dari proyek saya, saya perlu membuka folder itu untuk mendapatkan fitur ini? Saya tidak terlalu mendalami PHP, tetapi jika ada konsep ketergantungan lintas file, saya tidak akan dapat menavigasi ke file PHP lain hanya dari satu file, saya perlu membuka foldernya terlebih dahulu?

@saborrie kami TIDAK akan menambahkan pengaturan ruang kerja secara default saat Anda menambahkan folder. Salah satu alasan kami memutuskan untuk memasukkan ini ke dalam pengaturan pengguna adalah agar ruang kerja tidak menjadi "kotor" dengan pengaturan multi-root. Menempatkan pengaturan ini ke dalam ruang kerja dimungkinkan, tetapi Anda harus melakukannya secara manual. Ini tidak akan terjadi secara default.

@bpasero Ok ya, tetap dengan menyimpan ke pengaturan pengguna daripada pengaturan ruang kerja akan mencegah pengotoran folder ruang kerja - Saya menduga bahwa itu masih akan menyimpan sebelum meminta pengguna untuk secara eksplisit melakukan tindakan simpan meskipun ya?

Itu membuat saya memiliki dua pertanyaan lanjutan:

1) Apa yang akan terjadi ketika pengguna membuka ruang kerja dengan additionalFolders ditentukan dalam pengaturan-ruang kerjanya? Apakah ini akan disinkronkan ke pengaturan pengguna mereka? dan akankah itu menimpa entri untuk ruang kerja-root jika ada di daftar ruang kerja pengaturan pengguna? Atau sebaliknya?

2) Apakah meletakkan daftar ruang kerja ini ke dalam pengaturan pengguna merupakan opsi yang lebih baik daripada awalnya menghindari penyimpanan ruang kerja di salah satu file pengaturan JSON ini? Dalam sistem folder tunggal saat ini, ketika folder dibuka kembali dari item menu File > Open Recent , tab yang sebelumnya dibuka akan diingat - sejauh yang saya tahu ini tidak disimpan di pengguna mana pun File pengaturan yang dapat diedit, tidak bisakah jalur tambahan disimpan dengan cara yang sama, sampai pengguna menyimpannya secara eksplisit?

- Maaf untuk bahasa Inggris, saya menggunakan Google Translator -

Nah, saya membahas tata letaknya, (ya - sedikit kesulitan dalam memahami bahasa Inggris). Maaf kalau begitu ...

Saya tidak menyukai tata letak yang disajikan oleh @maddouri , terutama karena masalah yang ditemukan dalam masalah ini (# 25352, # 25354). Saya rasa akan lebih kompleks bahkan jika Anda harus menggunakan keyboard untuk mengakses folder dalam model yang ditampilkan.

Saya lebih suka model ini, yang menurut gagasan saya dapat menavigasi di antara folder proyek yang berbeda menggunakan tombol panah dan jika saya perlu membuat folder / file di folder utama, saya dapat menggunakan tombol menu pada keyboard, tepat di utama map.

Dan / atau dengan opsi file baru, pembaruan folder baru, dan Ciutkan Semua.

Adapun judul yang muncul di atas, saya lebih suka itu berfokus pada file saat ini dengan foldernya, atau daripada menampilkan semua folder utama yang terbuka ditambah file saat ini, mirip dengan gambar ini.

Dan pertanyaannya: Apakah Open Editores masih ada?

@bpasero

apakah itu berarti saya tidak dapat melakukan "Temukan Referensi" atau fitur bahasa serupa saat membuka hanya satu file PHP dari proyek saya, saya perlu membuka folder itu untuk mendapatkan fitur ini? Saya tidak terlalu mendalami PHP, tetapi jika ada konsep ketergantungan lintas file, saya tidak akan dapat menavigasi ke file PHP lain hanya dari satu file, saya perlu membuka foldernya terlebih dahulu?

Benar, jika Anda hanya membuka satu file, Anda tidak dapat mendefinisikan file dalam file lain yang tidak terbuka, tetapi hanya file di bawah rootUri . Itu karena dalam PHP setiap file dapat membuang simbol di namespace global, dan namespace sebenarnya hanyalah awalan nama untuk kelas. Tidak ada batasan tentang bagaimana namespace dan nama kelas harus sesuai dengan direktori dan nama file (hanya beberapa konvensi), dan tidak ada pernyataan import seperti di TS, hanya alias namespace. Memuat kelas terjadi pada waktu proses melalui "pemuat otomatis" terdaftar. Itu berarti untuk server bahasa pada go-to-definition, simbol dapat didefinisikan dalam file apa pun. Jadi server bahasa akan mengindeks semua file di rootUri saat startup dan kemudian bekerja dengan indeks untuk menjawab permintaan. Apa yang berhasil adalah jika Anda memiliki proyek yang terbuka, dan Anda membuat file baru yang belum disimpan - Anda akan mendapatkan kecerdasan untuk itu, karena Anda mendapatkan rootUri dan file baru melalui textDocument/didOpen . Tetapi simbol apa pun yang ditentukan dalam file yang tidak dibuka tidak di bawah rootUri tidak akan dipertimbangkan.

Pengaturan ruang kerja additionalFolders di dalam ruang kerja selalu diutamakan. Mengingat sifat pengaturan ini, Anda hanya dapat menimpa additionalFolders untuk folder yang saat ini dibuka jika pengaturan ini ditentukan di dalam ruang kerja (ini ditunjukkan dalam video dengan memiliki path: "." untuk "master").

Memiliki ini sebagai status UI yang disimpan mirip dengan misalnya berapa banyak tab yang dibuka adalah opsi yang kami diskusikan tetapi kami tidak menemukannya memiliki banyak keuntungan dibandingkan pengaturan. Beberapa alasan:

• ini tidak dapat dibagikan (baik melalui pengaturan ruang kerja, maupun melalui ekstensi sinkronisasi pengaturan)
• ini bukanlah sesuatu yang dapat diakses ekstensi hari ini dengan mudah (API pengaturan ada, API status UI tidak)

Adakah alasan tertentu Anda tidak menginginkan ini di dalam pengaturan?

@Tekbr ya, "Open Editor" akan bekerja seperti sebelumnya

@felixfbecker akankah ekstensi PHP dapat mengadopsi sesuatu seperti rootUri: string[] dengan mudah? Atau Anda lebih suka server bahasa PHP memulai beberapa kali untuk setiap folder yang dibuka (misalnya, VS Code akan multi-plex pada level folder yang dibuka ke server bahasa N?)

@bpasero PHP dapat bekerja dengan rootUris: string[] dengan cukup mudah. Server bahasa lain mungkin tidak. Memunculkan beberapa server bahasa berarti setiap folder bekerja secara terisolasi (tidak ada lompat ke definisi, temukan semua referensi di antara mereka). Mungkin pendekatan akan menjadi ServerCapability yang memutuskan apakah VS Code akan menelurkan satu atau beberapa server bahasa.

Saya suka konsep pengaturan folder tambahan. Bagi saya, memiliki satu folder root sudah cukup. Jika saya ingin fungsionalitas pengembangan penuh pada proyek terkait, saya dapat membuka jendela vscode baru.

Yang saya butuhkan dari folder tambahan hanyalah fungsionalitas terbatas. Misalnya saya mungkin ingin definisi simbol dari proyek terkait untuk digunakan dalam proyek akar tetapi tidak perlu atau ingin kemampuan untuk mengganti namanya atau menemukan semua referensi untuk itu di folder tambahan.

@bpasero Saya hanya menganjurkan untuk mempertimbangkan membuat ruang kerja dalam pengaturan opsional (dan ikut serta). Pada dasarnya, alih-alih secara otomatis mengubah pengaturan ketika pengguna menambahkan folder, mulailah dengan itu hanya dalam status UI, dan kemudian izinkan pengguna untuk menyimpan ini ke pengaturan dengan cara tertentu. Mungkin juga memungkinkan pilihan apakah itu masuk ke pengaturan ruang kerja atau ke pengaturan pengguna.

Saya tidak sepenuhnya menentang penyimpanan sepenuhnya dalam pengaturan, saya hanya melakukan sedikit untuk mempertanyakan keputusan untuk tidak menggunakan status UI, kalau-kalau itu telah diabaikan.

@bpasero @saborrie Jika kita pergi ke rute itu, maka saya akan menambahkan bahwa ketika diminta untuk menyimpan ke pengaturan, harus ada opsi untuk "mengingat pilihan saya" (untuk menyimpan ruang kerja ke pengaturan, baik pengaturan pengguna atau pengaturan proyek). Saya akan kecewa membuka jendela VSCode, memuat beberapa folder, membuat semuanya berfungsi seperti yang saya inginkan dan kemudian terjadi reboot atau crash dan saya kehilangan seluruh konfigurasi saya untuk kombinasi folder itu karena ruang kerja tidak pernah disimpan ke disk.

# 396 (komentar)

@Tekbr ya, "Open Editor" akan bekerja seperti sebelumnya

Terima kasih atas balasannya, @bpasero.

TL; DR: Gunakan tampilan hierarki setiap kali masuk akal sebagai kebalikan dari menambahkan nama akar ke setiap item.

Beberapa hal, saya sangat tidak suka cara Anda menambahkan folder ke bagian akhir, saya sangat ingin ini menjadi pilihan karena saya mungkin ingin memilikinya seperti ini express\.editorconfig dan express-plugin\.editorconfig jadi mungkin Anda dapat menawarkan opsi berikut: editor.tabName: "${root}\${filename}"

Hal lain yang saya ingin dan Anda sebutkan di video adalah pewarnaan di atas akar agar sesuai dengan tab jadi 👍 untuk ini.

Cari:

Dalam tampilan Search saya benar-benar berpikir bahwa Anda membuat kesalahan sejauh pengalaman berjalan, dalam pikiran saya itu harus ditampilkan sebagai pohon, seperti ini:

[-] express
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 
[-] express-plugin
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 

Alasannya adalah:

1. Anda dapat dengan mudah melihat di mana file terlepas dari panjang namanya.

2. Anda dapat meruntuhkan akar yang tidak ingin Anda lihat.

Saya pikir itu juga lebih cocok dengan jenis desain yang Anda terapkan pada Explorer .

Tugas:

Untuk Tasks saya lebih suka memiliki tampilan seperti ini:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Beberapa poin:

1. Menurut pendapat saya, Anda tidak boleh menyentuh / mengubah nama folder, yang berarti "plugin ekspres" harus ditampilkan persis seperti yang ditampilkan di Explorer dan bukan sebagai "Plugin Ekspres".

2. Berpindah di antara tugas dengan keyboard juga dapat dibuat sedemikian rupa sehingga mengabaikan pemilihan akar jadi jika Anda pindah ke bawah dari express\"Run Tests" dalam contoh item berikutnya yang akan dipilih adalah express-plugin\Compile as menentang express-plugin

ps Belum melihat keseluruhan video tapi ini hanya hal-hal yang terlintas dalam pikiran.

Bagaimana jika semua folder root yang Anda sertakan di ruang kerja Anda memiliki nama yang sama?
misalnya

• / dev / project / public / src
• / dev / framework / src
• / dev / beberapa-komponen / src

Anda kemudian akan memiliki ruang kerja dengan:

[+] src\
[+] src\
[+] src\

Sesuai cara _sublime_ untuk memasukkan folder di ruang kerja, setiap root folder virtual memiliki:

• Jalan
• Nama (opsional) - ini adalah nama folder jika dikecualikan, tetapi dapat ditampilkan sebagai apa saja
• Filter pengecualian untuk File / Folder

Lihat catatan https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (di atas) untuk contoh metadata yang terkait dengan cara melakukan sesuatu ini.

Saya ingin tahu bahwa fitur ini masih dalam tahap pengembangan?

@ifzm Ya, dan jika Anda membaca catatan rilis terbaru (Mei 2017 (versi 1.13)), Anda akan tahu bahwa mereka sedang mengerjakannya secara aktif.

@eyalsk Maaf, saya tidak melihat dengan teliti, ini adalah fitur yang menarik: D

Saya tidak tergila-gila dengan konsep additionalFolders , meskipun saya mengerti keinginan untuk menjaga hal-hal sederhana.

Tampaknya aneh bagi saya bahwa salah satu dari sekumpulan folder akan menyimpan konfigurasi "ruang kerja".

Bayangkan folder root berikut:

• situs web
• api
• seluler

... folder mana yang harus menampung pengaturan additionalFolders ? Mengapa?

Saya lebih suka gagasan manajer ruang kerja / proyek, di mana pengaturan disimpan di lokasi bersama / umum. Saya benar-benar tidak berpikir bahwa ini rumit dari perspektif UX, dan terminologi workspace dapat digunakan kembali / diperpanjang.

Tidak terkait: Saya sepenuhnya setuju dengan komentar @eyalsk tentang daftar bersarang (dan penamaan tab).

@ glen-84 dalam hal ini Anda bebas memiliki folder keempat pada disk yang disebut "my-mobile-website-project" yang memiliki pengaturan ini dan tertaut ke semua folder lainnya.

@bpasero Saya mengerti itu, tapi itu benar-benar hanya peretasan.

Untuk menguraikan:

Saya sibuk mengerjakan website , dan memutuskan bahwa saya ingin membuat beberapa perubahan pada api . Jika saya mengklik Add Folder , itu akan mengaitkan api dengan website , sehingga membuka website di masa mendatang akan membuka api demikian juga. Saya perlu memahami cara kerjanya, dan ketika saya melakukannya, saya harus membuka contoh terpisah dari VSC, membuat folder kosong dengan nama yang tepat, menambahkan kedua folder "proyek" ke dalamnya, dan kemudian menutup contoh awal.

Sebaliknya, saya dapat dengan mudah menggunakan Add Folder , dan itu (opsional) dapat meminta saya untuk menggunakan nama ruang kerja di masa mendatang untuk membuka kedua folder pada saat yang bersamaan.

workspaces.json (contoh)

{
    "workspaces": {
        "My company workspace": {
            "folders": {
                "/path/to/website": {
                    "folder-setting1": "value1"
                },
                "/path/to/api": {
                    "folder-setting1": "value1"
                }
            },
            "settings": {
                "workspace-setting1": 123
            }
        }
    }
}

Saya hanya merasa lebih fleksibel dan tidak terlalu canggung.

@ glen-84 mengerti. mengikuti solusi yang Anda usulkan membuat penggunaan VS Code lebih kompleks, itulah sebabnya kami memilih untuk melawan konsep seperti itu. Alasan utamanya adalah tiba-tiba tidak hanya ada "Open File" dan "Open Folder" tetapi juga "Open Project". Tetap dengan primitif yang kita miliki adalah pendekatan yang lebih langsung tanpa memperkenalkan konsep baru.

Meskipun demikian, semua pekerjaan yang kami lakukan sekarang untuk mendukung banyak folder adalah pekerjaan yang baik juga untuk skenario seperti yang Anda usulkan. Jika kami ingin mendukung skenario Anda, langkah-langkah untuk mencapainya jauh lebih ringan karena UI sudah sesuai untuk itu. Saya juga dapat membayangkan bahwa mungkin ekstensi dapat memperkenalkan gagasan ruang kerja seperti itu dan kami hanya menambahkan API yang diperlukan untuk mendukung ini.

Mari kita dapatkan UX dengan benar tanpa memperkenalkan konsep baru dan kemudian pikirkan tentang skenario lain seputar multi-folder. Ada banyak hal yang harus dilihat pertama kali (ekstensi, pengaturan, SCM UI, dll.).

solusi yang Anda usulkan membuat penggunaan VS Code menjadi lebih kompleks

Saya harus tidak setuju dengan ini. Jika pengguna bingung dengan fitur opsional "Proyek Terbuka" (atau ruang kerja), maka mereka cenderung bingung dengan banyak fitur yang ada di VSCode. Ini tidak rumit dari sudut pandang pengguna (jika ada yang membaca ini tidak setuju, harap katakan begitu).

Saya juga dapat membayangkan bahwa mungkin ekstensi dapat memperkenalkan gagasan ruang kerja seperti itu dan kami hanya menambahkan API yang diperlukan untuk mendukung ini.

Ekstensi sudah ada, dan sudah disebutkan beberapa kali. Penulis bahkan memiliki dukungan multi-folder pelacakan tiket terbuka . Ekstensi ini memiliki 370k + pemasangan, dan nilai 4,7. Bahkan dengan UI sederhana yang memanfaatkan palet perintah, ada sedikit tanda kebingungan dilihat dari komentarnya.

Mari kita dapatkan UX dengan benar tanpa memperkenalkan konsep baru dan kemudian memikirkan tentang skenario lain di sekitar multi-folder

Cukup adil. Bagaimanapun, ini tentang mendukung beberapa folder root dalam jendela yang sama - metode sebenarnya untuk mengelola grup folder ini dapat ditangani di tahap selanjutnya.

Apakah Anda mempertimbangkan untuk membuat jajak pendapat publik untuk mengumpulkan pendapat pengguna tentang subjek (saya mengetahui video YouTube, tapi saya mengacu pada aspek ini sendiri), atau apakah keputusan telah dibuat untuk menggunakan additionalFolders konsep?

Saya setuju dengan @ glen-84. Saya tidak mengerti masalah kerumitannya. Ya, ini bisa membuatnya lebih kompleks, tetapi ini adalah editor kode. Menurut saya, 95% programmer yang menggunakannya, yang dapat dengan mudah memahami ide proyek. Seharusnya ada sedikit kekhawatiran tentang membingungkan orang setiap hari karena setiap hari orang tidak menggunakannya.

Sementara ekstensi merupakan solusi, ekstensi juga merupakan yang kedua dibandingkan dengan peningkatan yang diimplementasikan secara asli (yaitu tidak dapat menambahkan opsi ke menu, hanya palet perintah, dll).

@ glen-84 keputusan telah dibuat untuk menggunakan pengaturan additionalFolders berdasarkan sentimen dalam tim pengembangan, studi pengguna yang kami lakukan (2 video tersebut) dan umpan balik yang kami dapatkan dalam masalah ini.

@pltrant membuat penggunaan multi root lebih kompleks karena Anda terus-menerus harus berpikir untuk membuka folder atau membuka proyek. Hal-hal seperti "Buka Terbaru" tiba-tiba membutuhkan perhatian lebih jika entri yang dipilih adalah folder atau proyek, atau lebih buruk lagi Anda bahkan memiliki 2 pemetik dan harus memutuskan mana yang akan digunakan.

Saya tidak yakin bagaimana memiliki pengaturan itu lebih rumit. Anda pada dasarnya tidak perlu peduli dengan pengaturan, Anda hanya perlu menambah dan menghapus folder ke pengaturan Anda dan pengaturan sedang diperbarui di latar belakang. Saya berpendapat bahwa Anda tidak pernah melihat nilai dari pengaturan itu dalam banyak kasus.

@ glen-84 Mengenai contoh proyek Anda dengan 3 folder yang sama pentingnya, menurut saya yang mana yang harus berisi pengaturan additionalFolders harus ditentukan berdasarkan ketergantungan. Jika folder API tidak bergantung pada proyek lain, ketika dibuka, itu harus dibuka sebagai satu folder dan tidak boleh berisi pengaturan tambahan aFolders. Tetapi ketika Anda membuka folder seluler , saya kira itu memiliki ketergantungan pada folder API. Jadi, Anda menambahkan pengaturan di folder seluler untuk membuka API sebagai folder tambahan saat dibuka di vscode. Hal yang sama berlaku untuk situs web. Jika tergantung pada api, tambahkan pengaturan di sana. Jika tidak, tidak diperlukan pengaturan.

Saya tidak berpikir akan ada pembukaan folder tambahan secara rekursif atau berjenjang. Saya juga menyukai gagasan ekstensi membaca format proyek lain seperti Visual Studio Solutions dan menyarankan / meletakkan pengaturan folder tambahan di tempat. Dan Anda selalu dapat membuka folder induk umum dari semua.

@stevencl menonton kedua video tersebut.

1. Alternatif 2 dengan disambiguasi tampaknya yang paling jelas. Sepertinya ini bisa dilipat (yaitu salah satu akar di pohon) yang memungkinkan banyak proyek untuk dilihat sekaligus. Jika Anda membutuhkan mockup, beri tahu saya.

2. Alternatif 2 lebih efisien dari perspektif real estate layar. Anda tidak akan memiliki info yang sama (nama proyek) diulang di bagian atas - seperti pada opsi 1 dan kemudian ditampilkan di root setiap proyek.

3. Hasil Pencarian dan Git dapat berperilaku sama ... sebagai pohon yang dapat ditutup. Hasilnya akan dikelompokkan (bersama dengan status) di bawah judul yang sesuai. Saya kira jika Anda menginginkan ringkasan yang dapat dinavigasi (seperti yang Anda tunjukkan untuk GIT, itu akan menjadi opsi yang bisa ada di seluruh pencarian (berapa banyak file yang Anda temukan) dan area proyek (ini dapat menampung tombol tindakan).

Singkatnya, saya adalah penggemar dari akar yang bisa dilipat dengan kemungkinan penambahan ringkasan yang bisa dinavigasi. Semacam kombinasi Alternatif 2 dan contoh ini

Saya berharap bahwa apa pun yang Anda pilih, Anda membuat pengalaman serupa di berbagai mekanisme. Anda mengatakan bahwa ada dua alternatif, tetapi sebenarnya ada 4 karena GIT dan Penelusuran sama-sama berbeda. Saya setuju dengan siapa pun yang membuat komentar ini

Re: berbagi info multi-proyek. Saya pikir itu akan berguna - bagaimana Anda memilikinya akan masuk akal sebagai permulaan - saya akan membuatnya hanya menggunakan tugas gulp - atau tugas yang dapat dipahami VS Code.

Terima kasih atas semua upaya Anda dalam hal ini.

Penerapan ruang kerja multi-root dilacak di # 28344 dan dalam pencapaian bulan Juni ini.

@bayu_joo ,

Mungkin ada kasus di mana tidak ada ketergantungan. Misalnya jika saya mengerjakan website dan memutuskan untuk menambahkan mobile untuk mengerjakannya pada waktu yang sama. Tidak ada ketergantungan di antara keduanya, tetapi sekarang website menjadi "induk". Jika saya kebetulan mengerjakan mobile terlebih dahulu, maka itu akan menjadi induk. Ini hanya sedikit sewenang-wenang. Folder tersebut juga bisa untuk proyek yang sama sekali tidak terkait.

Terlepas dari itu, saya menghormati keputusan para pengembang VSC, meskipun saya belum tentu setuju dengannya.

Terima kasih atas semua komentar lanjutannya. Seperti yang telah disebutkan di atas, kami sedang melacak pekerjaan dalam masalah # 28344. Kami akan mempertimbangkan komentar ini sementara kami terus mengerjakan ini, terutama saat merancang pengalaman SCM. Seperti yang telah dibahas dalam video dan telah beberapa kali disebutkan di atas, kami ingin mencapai konsistensi di sepanjang pengalaman.

Mengenai masalah kompleksitas yang dikemukakan @ glen-84,

Diskusi seputar ini sangat membantu dan telah memberi kami beberapa hal untuk dipikirkan untuk desain kami saat ini. Misalnya, mungkin kita harus mempertimbangkan untuk mengizinkan pengguna memilih folder 'primer' saat mereka menambahkan folder kedua ke ruang kerja. Mungkin kami meminta ini saat ruang kerja ditutup, mungkin itu pengaturan. Banyak hal yang perlu kami pikirkan untuk menyederhanakan pengalaman.

Seperti yang disebutkan @bpasero , kami selalu sangat enggan untuk menambahkan konsep baru (seperti proyek) ke VS Code. Ini bukan karena kami pikir itu akan membuat VS Code tidak dapat digunakan, itu lebih karena konsep tambahan menambah bobot atau bobot VS Code, membuatnya terasa lebih kompleks. Konsep semacam itu akan menjadi hal lain yang harus dicurahkan pengembang untuk sumber daya mental.

Lebih jauh lagi, setelah ada sesuatu di VS Code, akan jauh lebih sulit untuk mengeluarkannya (seiring waktu orang menjadi terbiasa dan bergantung padanya). Jadi kami menghabiskan banyak waktu dengan hati-hati mempertimbangkan apa yang kami tambahkan ke VS Code dan hanya menambahkan sesuatu jika kami yakin bahwa biaya penambahan konsep baru akan bermanfaat. Jadi sekarang kami ingin menentukan seberapa sukses desain untuk multi root yang tidak menambahkan konsep baru.

Sekali lagi, terima kasih atas umpan balik yang sangat berharga. Tanpa dialog seperti ini, akan jauh lebih sulit mencoba merancang pengalaman ini.

Luar biasa betapa bijaksana dan tanggapnya Anda semua di tim; itu sangat dihargai!

Apa yang mungkin belum dikatakan tentang kerumitan adalah bahwa Anda tetap menambahkan beberapa. Saya pikir kedua opsi ini sedang dibahas:

1. Proyek eksplisit.
2. Sesuatu yang terlihat seperti banyak folder biasa tetapi sebenarnya tidak - ada konsep penting dari folder utama yang menyangkut hal-hal seperti rootUrl untuk ekstensi dan mungkin hal-hal lain (warisan pengaturan ruang kerja, misalnya). Saya pikir biasanya, pengguna VSCode perlu memahami konsep ini dan mungkin akan lebih mudah untuk menjelaskannya secara terbuka daripada mencoba mengabstraksikannya.

Saya sebenarnya lebih suka cara ketiga, benar-benar tidak memperkenalkan sesuatu yang baru, hanya menangani hal-hal seperti beberapa repo .git dan pencarian dan tugas dan hal-hal seperti itu dengan cara yang transparan - seperti apa dua pertiga pertama video menyarankan (Saya sangat menyukai wireframes). Namun, kemudian saya menyadari rootUrl perlu dipertimbangkan untuk ekstensi yang mungkin merupakan alasan utama mengapa ini rumit.

Jika bukan karena rootUrl , saya akan mulai dengan pembaruan UI seperti yang diusulkan di wireframes ditambah persistensi lokal dari ruang kerja multi-root, dengan cara yang sama seperti semua folder lainnya disimpan dalam "Buka Terbaru".

Saya ingin mengulanginya dari sudut pandang saya, keadaan ideal adalah tempat VSCode bekerja dengan banyak folder terlepas dari apakah itu root SCM atau bukan (monorepo vs. banyak repo, lihat di atas). Saya percaya bahwa wireframes yang diusulkan ditambah beberapa pekerjaan inti tambahan seperti mewarisi .vscode pengaturan akan cukup untuk "v1" dari dukungan multi-root. "Proyek" atau "folder utama + tambahan" bisa datang nanti, IMO. Namun, apa yang saya katakan mungkin jatuh dengan rootUrl , saya tidak yakin tentang itu, saya hanya ingin menyampaikan sentimen umum saya tentang ini.

Senang sekali Anda mencoba untuk memecahkan masalah yang sulit ini dan menjaga kesederhanaan sebanyak mungkin!

Saya memiliki proyek node backend dan frontend, dan memiliki 2 editor VisualCode terbuka, yang merupakan beban sumber daya yang signifikan.

Saya menonton kedua video dan setuju dengan komentar di atas bahwa beberapa proyek ini tidak perlu ada hubungannya dengan satu sama lain. Mungkin satu bisa menjadi proyek nodejs sementara yang lain adalah C ++.

Saya tidak suka jika salah satu proyek menjadi proyek "master", dengan tambahan proyek. Setiap proyek harus sama dan tidak terkait.

Saya berharap dapat membuka folder, dan kemudian membuka folder lain (bukan TAMBAH). Folder hanya akan ditambahkan seperti pada video 1, dengan akar baru saja muncul (tetapi tunjukkan jalur lengkap di tooltip saat mengarahkan folder root). Proyek-proyek ini sama sekali tidak terkait. Memilih salah satu atau lainnya akan menyebabkan peralihan konteks. Seolah-olah saya beralih antara 2 contoh Kode Visual, baik pengaturan, skema warna, dan apa yang tidak.

Cara untuk mempertahankan beberapa proyek ini adalah dengan menyimpan ini sebagai file proyek baru, yang mereferensikan dua proyek lainnya, tetapi tanpa memodifikasi salah satu dari 2 proyek itu sendiri. Dengan kata lain, 2 project tetap independen, mandiri, dan tidak mengetahui project ke-3 (file pengaturan) yang mereferensikannya.

Setelah file ke-3 ini disimpan / dibuat, akan memungkinkan untuk membuat pengaturan yang menggantikan pengaturan dari proyek A dan B. Pengaturan yang tidak dibuat akan bergantung lagi pada proyek yang aktif.

Saat membagikan proyek, seseorang dapat membagikan file proyek yang mereferensikan dua lainnya. Ketika mereka hilang dari sistem file, tetapi berisi referensi ke url github mereka, itu harus menanyakan pengguna apakah itu ingin mengambilnya (secara default sebagai subfolder di root dari file proyek master itu, tetapi pengguna dapat mencari yang diinginkan lokasi untuk masing-masing).

Kemampuan untuk mencari di beberapa proyek harus bersifat opsional, dan kemampuan untuk menjalankan dan men-debug beberapa proyek secara bersamaan akan sangat berguna, tetapi tampaknya terlalu rumit untuk rilis pertama, dan mungkin kasus penggunaan seperti itu harus memerlukan menjalankan 2 instance. Setidaknya untuk sekarang.

Tampilannya di UI adalah langkah kedua, tetapi secara fungsional seperti inilah yang saya harapkan untuk berfungsi. Saya tidak suka ide memodifikasi proyek A menjadi referensi B atau sebaliknya, dan itulah yang saya pahami adalah niatnya. Untuk pengembang Agile, saya akan senang jika saya dapat mengerjakan 2 proyek dalam 1 jendela daripada harus menjalankan 2 contoh, tetapi tidak lebih dari itu untuk saat ini. Bahkan mungkin tidak dengan file proyek utama ke-3, tetapi hanya dengan pengalihan konteks.

Terima kasih atas tanggapan yang berkelanjutan. Ada tema pasti tentang penundaan persistensi ruang kerja multi folder hingga beberapa tindakan eksplisit dari pengguna (seperti menyimpan). Kami perlu memikirkan lebih lanjut tentang ini dan menyelidiki lebih lanjut.

Saya juga menyarankan para pengembang untuk melihat Eclipse IDE tentang caranya
menangani fungsi ini, mereka sudah mengetahuinya sejak lama dan berhasil
Bagus.

Pada hari Selasa, 13 Juni 2017 jam 9.11, Steven Clarke [email protected]
menulis:

Terima kasih atas tanggapan yang berkelanjutan. Ada tema pasti tentang
menunda persistensi ruang kerja multi folder hingga beberapa eksplisit
tindakan dari pengguna (seperti menyimpan). Kita perlu memikirkan lebih banyak tentang ini
dan selidiki lebih lanjut.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

-
Daniel Sokolowski
Arsitek Teknis

Stantive Technologies Group Inc.
Telepon: +1 (613) 634-7410
http://www.stantive.com

Pemberitahuan Kerahasiaan:
Informasi yang dikirimkan hanya ditujukan untuk orang atau entitas
yang ditujukan dan mungkin berisi rahasia dan / atau hak istimewa
bahan. Setiap penyebarluasan transmisi ulang ulasan atau penggunaan lain dari atau
mengambil tindakan apa pun yang mengandalkan informasi ini oleh orang atau
entitas selain penerima yang dituju dilarang. Jika Anda menerima
ini karena kesalahan, harap segera hubungi pengirim melalui pengembalian elektronik
transmisi dan kemudian segera hapus transmisi ini termasuk semua
lampiran tanpa menyalin mendistribusikan atau mengungkapkan sama.

Proyek Master
Saya menentang proyek MASTER. Peralihan konteks sering terjadi saat bekerja dengan layanan mikro yang berbeda. Ini berlaku untuk poin-poin berikut tentang Linting dan SCM.

Persistensi ruang kerja
Saya pikir pada iterasi pertama, kita tidak harus mempertahankan ruang kerja. Saya lebih suka iterasi pada satu atau dua rilis untuk fitur ini sebelum kami memperkenalkan pengaturan atau lapisan ketekunan apa pun untuk meminimalkan segala jenis migrasi yang kompleks atau merusak.

Linting / Pengaturan
Linting khusus proyek harus diberi spasi nama ke file di direktori yang sesuai. Misalnya, Proyek A menggunakan lebih cantik sedangkan Proyek B menggunakan standar. Beralih di antara kedua konteks harus mulus tanpa bentrok aturan linting satu sama lain.

Cari
Mencintai beberapa gambar rangka untuk yang satu ini di mana hasil pencarian ada di semua proyek dan diurutkan berdasarkan proyek.

_Project A_
file1: matched substring
file2: matched substring
...

_Project B_
file3: matched substring
file4: matched substring

SCM
Dalam hal ini, saya lebih condong ke arah menunjukkan perincian berdasarkan proyek dengan setiap perubahan scm.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

Saya merasa pendekatan ini lebih transparan dan intuitif.

Konsensus (berdasarkan komentar terbaru dan masalah lain) tampaknya bertentangan dengan gagasan additionalFolders , setidaknya dalam rilis awal.

Meskipun saya memahami bahwa keputusan telah dibuat, apakah Anda akan mempertimbangkan untuk mencoba menerapkan fitur ini sebagai sekumpulan API, sambil membiarkan persistensi untuk iterasi berikutnya? Jadi, API untuk menambahkan / membuka folder, dan memperbarui tampilan explorer, pencarian, tugas, dan SCM untuk mendukung ini.

Anda telah berbicara tentang betapa sulitnya menghapus sesuatu dari produk (jika konsep proyek / ruang kerja gagal), tetapi kenyataannya ini berlaku sama (jika tidak lebih) untuk konsep additionalFolders .

Menerapkan additionalFolders dan "proyek / ruang kerja" sebagai ekstensi akan memungkinkan Anda mengumpulkan data penggunaan tanpa melakukan satu model pun. Salah satu ekstensi ini (atau solusi hybrid) nantinya dapat diintegrasikan ke dalam produk.

Apakah masalah lingkungan telah diperbaiki di Mac OS? Saya masih tidak dapat menggunakan Homebrew npm dan semacamnya tanpa membuka VSCode dari baris perintah melalui code dan ini akan mengacaukan dengan dukungan multi root tentunya?

Ya, ini juga wajib bagi saya. Saya tidak mengerti masalah orang dengan itu. Ini mungkin bukan cara kerja satu orang, tetapi itu tidak berarti pengelolaan ruang kerja pilihan orang lain kurang valid. Saya benci jawaban dari "Mengapa Anda ingin melakukan itu?" alih-alih "Mari kita cari tahu cara menambahkan fitur yang dimiliki setiap editor kode lain di dunia."

Kembali ke Atom saya kira.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (Saya mendapatkan masalah yang sama di Insiders dan versi reguler). Jika saya dapat membantu men-debugnya, saya setuju.

@akutz orang-orang ini telah berusaha keras untuk merancang sistem multi-root yang layak, mereka bahkan memasang video sesi desain mereka (ada di catatan rilis terbaru). Itu akan datang, tetapi mereka memastikan bahwa mereka melakukannya dengan benar :-) (https://code.visualstudio.com/updates/v1_13)

Halo @cliffarh ,

Senang mendengarnya. Saya baru-baru ini melihat VSCode karena saya telah menggunakan Atom selamanya (dan Sublime sebelumnya). Baru-baru ini Atom bermasalah dan di utas Reddit saya melihat bahwa VSCode benar-benar pilihan yang bagus hari ini. Jadi saya terkejut karena tidak mendukung fitur dasar.

Hanya menumpuk di sini - ini benar-benar satu-satunya fitur yang mencegah saya mempertimbangkan untuk beralih dari IntelliJ / WebStorm ke VSCode secara penuh ... terutama karena, seperti yang disebutkan poster sebelumnya, saya bekerja dengan arsitektur terdistribusi sepanjang hari dan membutuhkan banyak manajemen Git yang terintegrasi kepada editor saya (karena saya terlalu malas 😆)

Saya _Sayang_ bahwa kalian sedang mengerjakan ini, dan saya tidak sabar untuk melihatnya beraksi.

Saya suka vscode tetapi "fitur yang hilang" ini menjauhkan saya dari peralihan penuh dari atom ke vscode

Versi awal sudah ada dalam build Insiders. Pergi dan dapatkan itu :)

+1 Butuh fitur ini

Versi pratinjau pertama sangat bagus guys!
Sudah ada masalah kecil bahkan sebelum saya mulai menguji dengan benar ...
Saat saya menambahkan dua folder "root" dengan samename dari dua proyek terpisah, tidak ada yang membedakan folder ini.

misalnya saya menambahkan /dev/www/myproject/src dan kemudian menambahkan /dev/libraries/mycomponent/src
Yang saya lihat hanyalah dua folder root bernama src .

> src
> src

Saya yakin kita membutuhkan cara untuk mengubah nama tampilan folder root.
Yang kemudian akan menampilkan:

> My Project (/src)
> Component 1 (/src)

Pikiran?

VSCode menunjukkan bagian dari nama folder saat Anda membuka dua file dengan nama yang sama, yang juga dapat berfungsi dengan folder?

@doublehelix kami membahas hal ini baru-baru ini tetapi tidak memiliki tempat untuk melacak masalahnya. Saya membuat https://github.com/Microsoft/vscode/issues/29871 , terima kasih 😄

@Tyriar Saya benar-benar menemukan fungsi pencarian yang membingungkan untuk sedikitnya dan berpikir bahwa itu harus menampilkan hasil yang mirip dengan bagaimana itu ditampilkan di Explorer seperti yang saya katakan sebelumnya .

Saya tidak tahu apakah kalian melihat apa yang saya dan beberapa orang katakan di atas atau apakah ada lebih banyak perubahan yang akan datang tetapi secara pribadi saya tidak suka cara Anda menambahkan nama root setiap kali sebagai kebalikan dari mengurutkan sesuatu di pohon -seperti tampilan jika memungkinkan.

@eyalsk Masih dalam proses, saya akan melihat lebih banyak hasil penelusuran di bulan Juli: # 29977

Proyek vscode didasarkan pada sebuah folder.
Jadi, Anda dapat mengonfigurasi konfigurasi setiap proyek secara terpisah, dan Anda dapat menggunakan Git terintegrasi secara langsung, atau tidak.

PyCharm: hati:: hati:: hati:

+1

Saya harus memuji Anda, tim VSCode yang terhormat.
Akhirnya saya bisa membuang Atom sejak Ruang Kerja Multi-Root mendarat di Insiders Builds!
Sejak dua tahun, .gitignore dll. Tidak dihormati di Atom saat mencari di ruang kerja multi-root dan Anda melakukannya dengan benar dari awal!

Apakah persistensi ruang kerja dilacak di masalah lain?

Kemarin Tim VS Code merilis versi baru VS Code dengan fitur Multi Root Workspaces 🎉.

Hasil dari pekerjaan ini adalah apa yang kami sebut "Produk yang Layak Minimum" (MVP) untuk mengaktifkan pengujian pada beberapa ruang kerja folder root.

Sebenarnya hanya tersedia dari build Insiders sehingga Anda bisa mendownloadnya di sini Download VS Code Insiders

File Explorer

Cari

Misalkan setiap folder yang ditambahkan ke ruang kerja adalah repositori git yang terpisah - apakah versi Multi Root Workspaces saat ini menangani kontrol sumber yang berbeda dari repositori tersebut?

@Weyzu kami sedang bekerja untuk mengadopsi SCM untuk skenario multi root pencapaian ini. Pemikiran awal kami adalah bahwa tampilan SCM perlu menyadari multi-repositori, yang belum tentu sama dengan kesadaran multi-folder seperti di explorer dan pencarian: sudah ketika Anda membuka satu folder di VS Code Anda dapat memiliki banyak repositori di dalamnya . Menurut kami tampilan SCM harus menunjukkan repositori ini dengan cara yang baik sehingga Anda melihat perubahan keluar / masuk untuk setiap repositori serta dapat mengkomit file dari setiap repositori.

Hasilnya akan memberikan pengalaman yang lebih baik untuk skenario multi-root serta skenario root tunggal di mana beberapa repositori terdapat dalam satu root.

Hasilnya akan memberikan pengalaman yang lebih baik untuk skenario multi-root serta skenario root tunggal di mana beberapa repositori terdapat dalam satu root.

Pendekatan yang bagus, kalian keren!

@bpasero luar biasa! Saya pasti tertarik melihat orang-orang Anda mengambilnya. IntelliJ / WebStorm memiliki sesuatu yang serupa di mana ia secara otomatis mendeteksi akar Git dan mengaturnya untuk Anda dengan tepat di kanan bawah, dan saya pribadi senang menggunakannya.

Apakah kalian memikirkan sesuatu seperti itu atau sesuatu yang lebih rumit?

Kami masih memilah UX untuk ini dan akan terus mengabari Anda tentang hasilnya.

Tidak dapatkah root sistem file virtual berfungsi di sini? Ini akan secara efektif bertindak seolah-olah root VFS adalah dir induk untuk beberapa jalur yang berbeda.

Saya ingin memberikan pembaruan pada pekerjaan multi-root kami karena hari ini adalah hari pertama di mana UX multi-root yang telah direvisi telah mencapai rilis orang dalam dan banyak dari Anda yang terbiasa dengan perilaku "lama" mungkin bingung apa yang sedang terjadi.

Cacat dari solusi lama
Solusi lama untuk multi root akan memperkenalkan pengaturan baru workspace (ke dalam settings.json global) yang memungkinkan untuk menambahkan folder tambahan ke satu folder root. Pengaturannya terlihat seperti ini jika Anda tidak memperhatikan:

{
  "path to folder": [
      "additionalFolder1",
      "additionalFolder2"
   ]
}

Kami menyebut solusi ini folder "master" dengan folder tambahan ("detail").

Ini adalah solusi paling mudah tanpa memperkenalkan banyak konsep baru, tetapi juga memiliki kekurangan:

• Anda tidak akan pernah bisa membuka folder master sebagai folder tunggal lagi karena pengaturannya tetap ada
• Anda tidak dapat menghapus folder master dari penjelajah
• beberapa pengaturan dari folder master diterapkan ke semua folder lainnya
• pengaturan Anda tercemar dengan hal-hal konfigurasi multi-root
• sulit untuk mengizinkan untuk membuka beberapa folder pada saat yang sama (misalnya, saat Anda membuka 3, folder master mana yang harus kita ambil?)

Solusi Kami
Kami berpikir bahwa konsep ruang kerja yang lebih eksplisit diperlukan untuk skenario multi root dan karena itu di dalam hari ini Anda akan melihat beberapa UI baru bermunculan:

Idenya adalah bahwa ruang kerja multi-root memerlukan tindakan eksplisit untuk dibuat. Dengan cara yang sama Anda bisa berada di ruang kerja kosong (tidak ada folder yang dibuka, bilah status ungu) atau di ruang kerja satu folder (bilah status biru muda) Anda juga bisa berada di ruang kerja multi-root (status biru tua) batang). Cara ketiga membuka ruang kerja di VS Code ini memungkinkan Anda memiliki folder sebanyak yang Anda suka. Ruang kerja ini dapat disimpan ke dalam file (mis. myWorkspace.code ) dan juga termasuk pengaturan ruang kerja. Anda tidak dipaksa untuk menyimpannya, selama Anda tidak ingin menyimpannya, mereka akan muncul sebagai "Ruang Kerja Tanpa Judul".

Untuk membuka ruang kerja, Anda dapat membuka file ruang kerja yang disimpan atau memilih dari daftar yang baru dibuka:

Ini semua adalah kode yang sangat muda dan UX yang sangat muda, jadi nantikan beberapa perubahan selama beberapa minggu ke depan. Kami tahu masih ada beberapa hal yang harus diselesaikan (misalnya, bagaimana kami dapat membuat transisi dari satu folder ke multi-folder lebih lancar).

Beberapa perubahan yang telah dilakukan hari ini yang akan dirilis besok berdasarkan masukan:

• ganti nama .code menjadi .code-workspace sebagai ekstensi untuk ruang kerja
• memiliki daftar folder dan ruang kerja yang terpadu (misalnya di File> Buka Terbaru) alih-alih membedakan antara folder dan ruang kerja

Nantikan lebih banyak lagi yang akan datang 👍

Di atas ini, kami sekarang memiliki satu folder .vscode per folder proyek yang berisi file settings.json . File ini dapat berisi yang berikut:

// Place your settings in this file to overwrite default and user settings.
{
      "editor.wordWrap": "on",
      "files.autoSave": "onFocusChange",
       "editor.fontSize": 15
}

Masalahnya di sini adalah, ketika kami ingin bekerja dengan banyak pengguna (sesi RDP berbeda) di server pada folder proyek yang sama, kami berbagi pengaturan yang sama. Ini mungkin bukan perilaku yang diinginkan. Saya mungkin ingin ukuran font saya lebih besar dari rekan saya.

Jadi menurut pendapat saya, Anda juga harus memperhitungkan bahwa pengguna yang berbeda mungkin bekerja pada folder yang sama tetapi dengan pengaturan yang berbeda di settings.json .

@ DarkLite1 Anda mengemukakan poin yang bagus. Dalam desain pengaturan kami untuk multi-root, kami mencoba mengidentifikasi pengaturan yang dapat kami dukung per folder dan pengaturan yang tidak dapat kami dukung. Kami biasanya mengatakan bahwa pengaturan yang menargetkan editor atau sumber daya tertentu dapat didukung per folder karena jelas dari folder mana editor dibuka. Pengaturan lain yang tidak akan didukung adalah tentang kustomisasi meja kerja (mis. Menampilkan bilah status atau tidak).

Contoh Anda adalah tentang pengaturan editor.fontSize yang sebenarnya kami dukung per folder bahkan dalam ruang kerja multi root. Saya pikir ini bisa menjadi skenario yang valid bahwa pengguna ingin memiliki ukuran font yang lebih besar untuk folder yang berisi banyak dokumentasi penurunan harga (bahkan mungkin dengan font yang berbeda?). Jadi menurut saya, kita tidak boleh mencegah dari menghormati pengaturan ini per folder juga di lingkungan multi root.

Jika Anda ingin menyimpan editor.fontSize sebagai pengaturan ruang kerja pribadi, maka menurut saya itu tidak boleh diperiksa ke dalam repositori.

Dengan konsep ruang kerja baru, Anda dapat melakukan hal berikut:

• File> Ruang Kerja> Ruang Kerja Baru
• Pilih folder Anda
• Buka pengaturan ruang kerja
• Ubah editor.fontSize: 15

Sejak saat itu, ruang kerja Anda akan membawa pengaturan ini, tetapi Anda tidak memaksanya kepada orang lain.

Dari perspektif UX, akan lebih mudah jika saya dapat menyeret & melepas folder ke jendela VS Code tanpa harus secara eksplisit membuat ruang kerja terlebih dahulu (ini adalah sesuatu yang saya lakukan sepanjang waktu di Sublime). Saya selalu mengerjakan banyak proyek pada waktu yang sama, dan tergantung pada apa yang saya kerjakan, itu akan menjadi proyek yang berbeda (tumpang tindih) setiap hari.

Ruang kerja akan memperkenalkan konsep yang tidak sesuai dengan cara saya bekerja, dan saya harus melacak konfigurasi ruang kerja yang berbeda (seperti yang saya pahami) yang terdengar seperti itu akan membuat beberapa konfigurasi berantakan di folder proyek saya.

Selain itu, saya pikir saya berbicara untuk banyak pengguna jika saya berpendapat bahwa hal-hal seperti pencarian, konfigurasi bersifat global secara default (berlaku untuk semua folder yang terbuka) - meskipun alangkah baiknya jika saya memiliki opsi untuk mencari secara lokal di folder ( Saya selalu menemukan ini rumit di Sublime).

@SanderMertens Anda mungkin melewatkan ini tetapi @bpasero menulis;

Ruang kerja ini dapat disimpan ke dalam file (mis. MyWorkspace.code) dan juga termasuk pengaturan ruang kerja. Anda tidak dipaksa untuk menyimpannya, selama Anda tidak ingin menyimpannya, mereka akan muncul sebagai "Ruang Kerja Tanpa Judul".

Sekarang, saya tidak yakin apakah Anda akan memiliki kemampuan untuk menarik dan melepas folder tetapi dari apa yang saya dapatkan, orang akan memiliki kemampuan untuk membuka folder sewenang-wenang tanpa membuat ruang kerja.

Saya tidak sabar menunggu fitur ini disertakan dalam build stabil.

Yay! 😄

Saat ini Anda tidak dapat menyeret folder ke dalam explorer untuk menambahkannya, tetapi ini ada di backlog kami. Komplikasi dengan interaksi ini adalah kita tidak mengetahui maksud pengguna: membuka folder di jendela atau menambahkannya ke ruang kerja?

Transisi dari 1 folder ke banyak folder saat ini merupakan langkah yang lebih eksplisit dibandingkan dengan apa yang dilakukan editor lain (Anda perlu membuka File> Workspaces> Save Workspace dan memilih folder yang Anda inginkan). Ada beberapa alasan mengapa kami ingin mengikuti perilaku saat ini untuk saat ini sampai multi root stabil. Alasan utamanya adalah multi-root merupakan perubahan besar untuk semua ekstensi kami. Saat penjelajah bekerja dan Anda dapat mencari melalui semua folder, sebagian besar ekstensi tidak akan bekerja dengan benar sampai API multi root baru diadopsi. Karena itu, kami tidak ingin membuatnya terlalu mudah di awal untuk masuk ke multi-root secara tidak sengaja. Ini adalah isyarat pengguna eksplisit untuk memasuki ruang kerja multi root dan dalam mode itu kami mungkin ingin menarik perhatian pada fakta bahwa beberapa ekstensi belum berfungsi.

Alasan lainnya adalah pengaturan ruang kerja: Bayangkan alur ini:

• Anda mulai dengan 1 folder yang memiliki pengaturan ruang kerja
• Anda menambahkan folder kedua (asumsikan ini berfungsi tanpa sakelar konteks dan pemuatan ulang jendela)
• Anda membuka pengaturan ruang kerja
  => pengaturan ruang kerja di multi root sekarang disimpan di beberapa lokasi di luar folder karena Anda dapat memiliki banyak folder
  => kita mungkin perlu bertanya kepada pengguna apakah pengguna ingin memigrasi pengaturan ruang kerja ke lokasi baru itu

Jadi, apa pun yang terjadi, memasukkan multi-root bukanlah operasi yang ringan saat ini. Kami mungkin meninjau kembali ini saat debu mengendap dan multi-root diadopsi secara luas, tetapi untuk saat ini kami pikir model ini lebih baik dan menghindari frustrasi.

@bpasero Saya pikir secara default setelah Anda menyeret folder ke dalam explorer, folder itu seharusnya tidak menyimpannya secara otomatis ke ruang kerja meskipun mungkin ada dan ini harus menjadi tindakan eksplisit di mana pengguna mengklik folder dia / dia diseret dan kemudian menambahkannya secara eksplisit ke ruang kerja dan jika Anda memiliki beberapa folder yang tidak terkait, mungkin masuk akal untuk memberikan tindakan lain untuk menyimpan semuanya sekaligus.

Itu semua tergantung pada kasus penggunaan yang ingin dicakup. Saya telah menemukan dari pengalaman bahwa KISS selalu merupakan pendekatan terbaik. Memperkenalkan Workspaces terdengar bagus sebagai feature tetapi apa manfaat sebenarnya dan apa kerugiannya?

Satu kelemahan yang muncul di benak saat memperkenalkan dan menggunakan Workspaces adalah ia perlu menyimpan datanya (pengaturan) di suatu tempat dan memerlukan pemeliharaan / kesadaran pengguna.

Misalkan satu-satunya tujuan adalah memberi pengguna kemampuan untuk bekerja dengan banyak folder dalam satu sesi Kode VS. Tidak kurang, tidak lebih.

Kasus penggunaan paling umum:
Tidak ada konsep Workspaces . Pengguna hanya membuka folder tambahan, atau sebanyak yang dia inginkan, dan mereka membuka dalam tampilan di sebelah kiri seperti folder tunggal. Dia mengharapkan pengaturannya sama di mana-mana. terlepas dari di mana file-nya berada. Dan dia tidak ingin ada kekacauan tambahan dari file konfigurasi VS Code di antara file proyeknya seperti yang dinyatakan oleh @SanderMertens , saya dan mungkin orang lain di luar sana juga.

Tantangan / Masalah / Pertanyaan:

• Mengapa ada begitu banyak file pengaturan? Pengaturan pengguna, pengaturan ruang kerja? Ini harus IMHO semua disimpan dalam satu dan lokasi yang sama. Dengan preferensi pada pengguna folder / profil pribadinya, sehingga setiap pengguna di sistem dapat memiliki pengaturannya sendiri. Bonus ekstra. mereka tidak mengacaukan file proyek dan banyak pengguna dapat melakukan hal mereka sendiri. Hapus profil? Bagus! Bersihkan papan tulis untuk VS Code juga.

Saya pikir Workspaces adalah hal-hal yang terlalu banyak rekayasa jika Anda ingin:
Kecepatan, kesederhanaan, dan editor yang berfungsi., Tidak ada hal yang terlalu rumit atau memahami konsep tambahan. Jika pengguna dari Sublime atau editor lain tidak menggunakan konsep ini dalam alur kerja mereka, itu seharusnya menjadi indikasi terlalu banyak berpikir. Atau itu bisa berarti sesuatu yang sangat luar biasa ditemukan yang akan diterapkan oleh editor lain juga, tetapi saya ragu.

Maaf jika ini terdengar seperti kata-kata kasar, itu sama sekali bukan niat saya. Namun saya yakin kami dapat melakukan lebih baik terkait dengan akses multi root / folder.

@ DarkLite1 terima kasih telah meluangkan waktu untuk memberikan umpan balik tentang strategi baru kami untuk ruang kerja.

Saya setuju dengan semua poin Anda dan menginginkan solusi sederhana juga. Ruang kerja sebagai konsep adalah langkah pertama kami menuju solusi multi-root yang berfungsi dengan pola yang ada (pengaturan ruang kerja, ekstensi, dll.). Karena ini adalah langkah pertama, perkirakan beberapa tepi yang lebih kasar (misalnya transisi dari folder 1 ke N tidak seringan mungkin). Sasaran kami adalah membuat transisi ini lancar dan tidak membuatnya lebih rumit dari yang dibutuhkan di masa depan. Dan kami juga tidak ingin memaksa pengguna untuk mengelola ruang kerja ini (itulah sebabnya kami memiliki "Ruang Kerja Tanpa Judul" yang aktif selama jendela terbuka dan akan hilang setelah Anda menutup jendela itu).

Ada beberapa hal seputar ruang kerja multi-root yang perlu diingat yang mungkin tidak begitu jelas. Saya harap penjelasan mendetail berikut membantu untuk memahami proses desain kami:

Pengaturan Ruang Kerja
Kami mendukung pengaturan di dalam folder ruang kerja (folder .vscode ). Sebanyak beberapa pengguna mungkin tidak menyukai pengaturan semacam ini yang berakhir di .gitignore file atau repositori, ada banyak yang mengandalkan fungsionalitas ini. Kami tidak bisa begitu saja berhenti mendukung pengaturan yang ada di dalam folder karena pengguna mengandalkannya. Sekarang, untuk skenario multi-root jelas kita harus mencari tempat baru untuk pengaturan ruang kerja. Kami datang dengan konsep file ruang kerja yang berisi pengaturan ini. Selama ruang kerja tidak disimpan di mana pun, itu berada di folder yang berisi data spesifik Kode VS lainnya dan ketika Anda menyimpan file, pengaturan akan ada di dalam file itu.

Sekarang bayangkan Anda mulai dengan 1 folder di VS Code yang memiliki pengaturan ruang kerja yang ditentukan dan Anda ingin menambahkan folder kedua. Apa yang harus kita lakukan sekarang? Abaikan pengaturan ruang kerja folder pertama? Minta pengguna untuk memigrasi pengaturan? Kami memutuskan untuk menjadikan ini sakelar konteks eksplisit untuk memperjelas bahwa membuka ruang kerja membawa pengaturan ruang kerjanya sendiri di lokasi yang berbeda.

Dan sekarang bayangkan Anda beralih dari 1 folder ke 2 folder dan kami memindahkan pengaturan ruang kerja ke tempat lain. Bayangkan Anda membuat perubahan pada pengaturan ruang kerja ini. Sekarang Anda ingin kembali dari 2 folder ke 1, apakah Anda ingin memigrasikan pengaturan ruang kerja kembali ke folder?

Contoh lain: Anda bertransisi dari 1 ke 2 folder dan mengonfigurasi pengaturan ruang kerja. Sekarang Anda menutup jendela. Saya rasa Anda akan marah kepada kami jika Anda tidak dapat kembali ke ruang kerja ini karena Anda telah mengonfigurasi pengaturan untuk ruang kerja ini dengan cermat. Jadi meskipun Anda tidak menyukai konsep ruang kerja, setelah Anda mengonfigurasi pengaturannya, saya rasa Anda ingin ruang kerja itu tetap hidup.

Saya harap contoh-contoh ini membuatnya sedikit lebih mudah untuk memahami mengapa KISS tidak semudah yang kita bayangkan.

Ekstensi
Semua ekstensi kami selalu berfungsi pada API yang menyediakan jalur ruang kerja tunggal karena hingga saat ini kami tidak mendukung ruang kerja multi-root. Sebagai pengguna, Anda mungkin berpikir bahwa beralih dari 1 folder ke 2 folder adalah operasi yang sangat sederhana dan ringan, tetapi untuk ekstensi itu dapat berarti banyak hal: Ekstensi bahasa yang selama ini diasumsikan hanya ada satu folder tiba-tiba harus menyadari beberapa folder. Dan di atas semua itu, folder ini dapat datang dan pergi dengan sangat dinamis kapan saja.

Memperkenalkan konsep ruang kerja nyata memberi kita lebih banyak ruang dan waktu untuk memperluas dan membantu ekstensi mengadopsi konsep ini. Misalnya, kita dapat menonaktifkan ekstensi yang belum mengadopsi ruang kerja multi-root untuk mencegah hal-hal aneh terjadi (misalnya, ekstensi bahasa hanya berfungsi di satu folder dan melaporkan kesalahan yang salah di folder lain).

Mari kita coba menstabilkan dukungan multi-root dengan ruang kerja baru ini terlebih dahulu dan kemudian meninjau kembali seberapa ringan kita dapat melakukan transisi. Setelah kami memiliki ekstensi on-board dan mengetahui kisah pengaturan kami, saya pikir kami dapat beralih ke pengalaman yang lebih ringan.

NB: karena Anda membuat referensi ke editor lain sehubungan dengan dukungan multi-root mereka, saya hanya ingin menunjukkan bahwa editor ini juga dilengkapi dengan ruang kerja atau konsep proyek yang dapat Anda simpan ke file dan dibagikan dengan orang lain. Biasanya Anda tidak melihat konsep ini karena berpindah dari folder 1 ke N adalah operasi yang sangat ringan. Saya berpendapat bahwa orang-orang yang mengandalkan fitur ini mulai pindah ke ruang kerja / proyek yang disimpan sebagai cara untuk mengelola pekerjaan. Misalnya, kecuali Anda menyimpan ruang kerja / proyek dan menutup jendela, semua informasi ini hilang.

@bpasero terima kasih telah kembali kepada saya dan untuk penjelasan rinci, saya sangat menghargai itu.

Karena saya tidak sepenuhnya mengenal Sublime, saya mengambil kebebasan untuk memeriksa bagaimana mereka menangani ini. Dan Anda benar, mereka juga menggunakan Workspaces dan bahkan Project file. Satu-satunya hal yang sedikit mengganggu saya adalah menempatkan file VS Code di antara proyek saya. Tetapi seperti yang Anda sebutkan, jika orang lain mengandalkan ini, harus diperhitungkan bahwa ini mungkin yang terbaik. Saya hanya bertanya-tanya mengapa file pengaturan ini tidak spesifik untuk pengguna? Saya dapat membayangkan seorang rekan membuka VS Code pada struktur folder yang sama, tetapi ingin memiliki pengaturannya sendiri.

Jika Workspaces adalah jalan ke depan, dan tampaknya demikian, akan logis saat membuka aplikasi yang akan memuat ulang pengaturan yang terakhir digunakan. Meskipun ini adalah Workspace belum disimpan. Kurasa itu membuat hidup sedikit lebih sederhana.

Mengapa saya memilih VS Code? Karena ini lintas platform, karena saya menggunakan Linux di rumah dan Windows di tempat kerja, ini benar-benar dapat menjadi editor default saya! Sebagai bonus tambahan, saya adalah pengembang PowerShell dan ada ekstensi untuk itu juga. Jadi dua kemenangan besar di sana! Selain itu, untuk kursus Java yang saya ikuti, Red Hat juga membuat ekstensi untuk VS Code. Jadi, begitu Anda mengenal VS Code lebih baik, dengan pintasannya dan semuanya, Anda akan mendapatkan keuntungan secara keseluruhan.

Aplikasi dan ekstensinya masih sedikit dalam beta atau bahkan status alfa di beberapa titik, tapi tetap saja, kerja bagus guys! Sangat menghargai upaya dan melihat kemajuan Insider yang dibangun setiap hari. Pertahankan kerja bagus dan semoga akhir pekan Anda menyenangkan.

Terima kasih atas penjelasan @bpasero , saya rasa saya lebih mengerti sekarang apa kompleksitasnya.

Salah satu pendekatannya adalah dengan secara konseptual memperlakukan setiap rangkaian proyek dengan konfigurasi yang sama sebagai ruang kerja. Selain itu, Anda dapat menahan diri untuk tidak menambahkan folder .vscode selama proyek tidak menyimpang dari konfigurasi default. Yang harus:
1) singkirkan sebagian besar kekacauan dalam proyek
2) mencegah sebagian besar bentrokan konfigurasi saat menambahkan proyek (dalam kasus sederhana, tidak akan ada konfigurasi)

Saya pikir konsep ruang kerja eksplisit seperti yang dibahas adalah solusi yang baik untuk masalah yang disebutkan. Dengan dua aturan sederhana ini saya meminimalkan kasus penggunaan di mana orang mengalami masalah ini.

Bagi saya, melihat komentar di utas, dan kasus penggunaan saya, saya melihat _Multi-folder_ dan _Workspaces_ sebagai dua konsep yang berbeda, dan mungkin itu harus diperlakukan secara terpisah juga.

Seharusnya tidak memaksa untuk _membuat ruang kerja_ hanya untuk menambahkan folder lain ke jendela saat ini. Ini seharusnya hanya menambahkan folder baru di pohon, dan membiarkan ruang kerja yang baru dibuat sebagai _internal info_. Jika pengguna memutuskan untuk menyimpan workspace, maka workspace benar-benar dibuat. Dan bahkan jika saya tidak menyimpan ruang kerja, saat membuka kembali folder teratas, itu akan _mengingat_ ruang kerja sementara saya_ dan membuka folder lain juga, sama seperti ia mengingat file yang dibuka saat Anda membuka folder hari ini. BTW, saya bertanya-tanya bagaimana saya bisa membuka multi-folder di baris perintah.

Untuk kasus penggunaan saya, multi-folder hanyalah cara untuk melihat lebih dari satu folder sekaligus di jendela yang sama, bukan pendekatan _Project Group / Solution_. Jadi, solusi yang lebih sederhana akan cocok. Tapi saya mengerti bagaimana orang lain membutuhkan _Workspace_, dengan pengaturannya sendiri dan sebagainya: thumbsup :

Hal yang paling mengganggu saya tentang konsep Ruang Kerja baru ini (dibandingkan dengan iterasi pertama menggunakan User Settings ) adalah hal yang sama yang mengganggu saya ketika saya menggunakan Sublime Text. Fakta bahwa Anda _dapat_ menyimpan file .code-workspace _anywhere_, dan sekarang saya harus mengelola tempat umum untuk menyimpannya. Akan jauh lebih sederhana, IMHO yang akan muat secara otomatis, di salah satu dari dua tempat ini:

• di dalam folder user-data-dir , seperti User Settings dan Keybindings
• di dalam _Top Folder_

Untuk memperjelas, saya memahami konsep ruang kerja yang lebih kompleks yang dibutuhkan pengguna lain. Saya hanya ingin pendekatan yang lebih sederhana untuk konsep multi-folder yang lebih sederhana.

Saya suka opsi ini, tambahkan opsi ini.

Karena folder di dalamnya tidak terlalu mengesankan.

atau tambahkan kemampuan untuk mengubah opsi ini.

Saya suka ide Workspace! Ada ide kapan ini akan siap?

Apakah diharapkan pada titik ini bahwa informasi git di pojok kiri bawah tidak secara akurat mencerminkan cabang git dari repo apa pun tempat file yang saat ini difokuskan? Saya tidak melihat apa pun tentang "beberapa akar git" di catatan rilis v1_15.

Saya telah menggunakan fitur ini sekarang dengan Insider build selama beberapa hari dan saya harus mengatakan itu semua yang saya inginkan. Pengalaman pengguna yang sangat bersih dan saya tidak sabar menunggu sampai di build utama sehingga saya dapat mengubah seluruh tim saya menjadi ini.

Saat bekerja dengan NodeJS dan membuka beberapa modul NPM secara bersamaan, cara ini menyatukan semuanya ke dalam satu jendela adalah penghemat waktu yang sangat besar.

Alat peraga besar untuk tim!

Mengapa fitur ini muncul di catatan rilis saya dengan gif dan penjelasan, tetapi tidak tersedia di editor sebenarnya ?!

@ShashankaNataraj yang ada di dalam yang dibangun bukan di atas bangunan asli. Jika Anda melihat dokumen dengan cermat, itu akan disebutkan hanya untuk insider build

Peta jalan kami untuk pekerjaan multi root yang sedang berlangsung tersedia di https://github.com/Microsoft/vscode/issues/28344 dan akan berlanjut hingga Agustus, September, dan mungkin juga Oktober.

Kami akan membuat fitur ini hanya tersedia di orang dalam sampai:

• kami dapat memberikan pengalaman SCM, debug, dan tugas berkemampuan multi-root yang tepat
• kami mengadopsi API multi-root dan fungsionalitas untuk ekstensi yang kami kirimkan dan yang secara aktif kami kontribusikan (mis. Go)
• penulis ekstensi memiliki cukup waktu (misalnya, 1 pencapaian) untuk mengadopsi API multi root baru

Harap dipahami bahwa kami ingin menghindari pengiriman fitur ini ke stabil dan mengalami pengalaman ekstensi yang rusak karena kami mempercepat fitur ini terlalu cepat.

Terima kasih telah menjadi orang profesional, kerja bagus!

@bpasero Saya agak khawatir tentang penulis ekstensi yang akan memperbarui plugin kapan saja. Apakah mereka menerima beberapa email perubahan penting yang akan datang?

Terima kasih

@FelikZ silakan lihat peta jalan kami (https://github.com/Microsoft/vscode/issues/28344). Untuk rilis September kami berencana untuk mengadopsi ekstensi yang kami kirimkan dalam VS Code dan saat kami sedang mengerjakannya kami menambahkan API dan utilitas yang diperlukan untuk melakukannya.

Selama bulan September ini rencananya:

Pembaruan orang dalam hari ini hadir dengan beberapa perubahan pada file .code-workspace yang ingin saya rangkum di sini. Ruang kerja yang sudah ada dengan format sebelumnya akan secara otomatis dipindahkan ke format baru.

Format lama terlihat seperti ini:

{
    "id": "1500007676869",
    "folders": [
        "file:///Users/bpasero/Development/Microsoft/monaco",
        "file:///Users/bpasero/Development/Microsoft/vscode-distro",
        "file:///Users/bpasero/Development/Microsoft/vscode-docs",
        "file:///Users/bpasero/Development/Microsoft/vscode-extension-sdk"
    ]
}

Dan format baru ist:

{
    "folders": [
        { "path": "/Users/bpasero/Development/Microsoft/monaco" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-distro" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-docs" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-extension-sdk" }
    ]
}

ID Ruang Kerja
ID ruang kerja digunakan untuk mengaitkan beberapa hal dengan ruang kerja:

• semua status UI (mis. membuka file)
• semua status file kotor (alias hot-exit)
• status ekstensi (jika ada)

Kami memutuskan untuk menghapus properti id dari file ruang kerja dan sebagai gantinya menghitung id secara otomatis berdasarkan jalur file absolut dari file ruang kerja pada disk. Ini memiliki beberapa kelebihan dan kekurangan tetapi pada akhirnya kami pikir kelebihannya menjadikan ini solusi yang lebih baik:

• aneh bahwa Anda dapat mengedit id dalam file hanya dengan mengetikkan nilai lain
• tidak terlalu jelas bagaimana memperlakukan id saat berbagi file ruang kerja dengan orang lain (haruskah id diubah? haruskah id menjadi uuid?)
• tidak mungkin untuk menyalin file ruang kerja dan membukanya di jendela terpisah, Anda harus mengubah id terlebih dahulu dalam file yang disalin
• Akibatnya, tindakan "Simpan Ruang Kerja Sebagai" harus menanyakan pengguna apakah salinan harus memiliki id atau tidak

Satu kelemahan dari pendekatan ini adalah setelah Anda memindahkan atau mengganti nama file ruang kerja, status terkait akan hilang. File kotor ("hot-exit") akan tetap dibuka kembali setelah dimulai ulang, tetapi akan terbuka di jendela kosong dan tidak lagi dikaitkan dengan jendela ruang kerja. Kami masih berpikir bahwa kami dapat meningkatkan perilaku ini, meskipun berperilaku konsisten dengan apa yang terjadi hari ini ketika Anda mengganti nama folder dengan status UI terkait dan file kotor.

Folder
Kami memutuskan untuk meninjau kembali format properti folders .

• kami tidak lagi mengharuskan Anda menggunakan URI sumber daya, tetapi hanya jalur file untuk mempermudah pengeditan
• kami mengubah entri dari properti folders menjadi objek sehingga kami dapat mengasosiasikan metadata ke entri sesuai kebutuhan (mis. setiap folder dapat memiliki properti tambahan name )

Akhirnya, dukungan untuk jalur relatif telah mendarat juga. Anda dapat memasukkan jalur file relatif dan itu akan diselesaikan terhadap folder induk dari file ruang kerja. Perhatikan bahwa karena bug https://github.com/Microsoft/vscode/issues/33188 saat ini kami sedang menulis ulang jalur relatif ke jalur absolut saat membuat perubahan pada file ruang kerja.

@bpasero itu luar biasa. Kapan properti tambahan name akan berfungsi? Saat ini saya memiliki dua folder dengan nama yang sama di ruang kerja saya dan itu mengerikan.

@DaniloPolani lihat https://github.com/Microsoft/vscode/issues/29871

Pembaruan penanganan jalur relatif : Dimulai dengan insider build saat ini, kami akan menulis jalur ke file ruang kerja sebagai jalur relatif jika lokasi file ruang kerja adalah induk dari target. Dengan kata lain, jalur sekarang akan selalu relatif kecuali kita harus menggunakan notasi " ../ " untuk mengekspresikan jalur.

Karena ruang kerja tanpa judul selalu berada di direktori data VS Code, jalur di sana akan selalu absolut. Tapi begitu Anda menyimpan ruang kerja tanpa judul ke suatu lokasi, kami akan menulis ulang jalurnya jika memungkinkan.

Jika Anda penasaran tentang perubahan di sekitar ruang kerja multi root yang masuk selama sprint ini, periksa catatan rilis yang diperbarui .

+1

+1

@bpasero IMHO, cara status UI ditangani (jika menggunakan string ID di file .code-workspace , atau menggunakan jalur file sebagai ID) tidak memadai.
Mengganti nama file .code-workspace , atau salah satu folder induknya, atau memindahkannya, dan kehilangan status UI menurut saya sama sekali tidak intuitif. Saya pikir orang yang tidak menyadari bagaimana cara kerjanya di bawah tenda sama sekali tidak tahu tentang alasan mereka kehilangan status UI mereka sebelumnya dan bagaimana mendapatkannya kembali.
Itu tidak boleh terikat dengan jalur absolut file di sistem file sama sekali!

Ini berlaku untuk cara status UI terkait dengan jalur folder yang saat ini juga ada dalam rilis stabil. Saya sangat bingung pada awalnya, sampai saya melakukan googling.

IMO Jika kita berurusan dengan hanya satu folder, status UI harus disimpan di dalam folder .vscode . Jika kita berurusan dengan ruang kerja multi-root, status UI harus disimpan sebagai file terpisah di folder yang sama dengan file .code-workspace menggunakan konvensi penamaan yang sesuai (atau mungkin di dalam file itu sendiri, meskipun pengaturan pencampuran dan negara mungkin bukan ide yang bagus).

Jika diterapkan dengan benar, ini akan memungkinkan pengguna untuk memiliki akses penuh ke status UI, melampirkan status UI baru ke ruang kerja tertentu (multi-root atau tidak), dll.
Saya ingin sekali dapat menyinkronkan status UI antara komputer yang berbeda, katakanlah bekerja di kantor, lalu pulang, mengambil laptop atau apa pun dan melanjutkan tepat di tempat saya tinggalkan.
Memiliki beberapa status UI yang dilampirkan ke ruang kerja dan dengan mudah beralih di antara mereka (menu / keybinding / command / etc) saat bekerja pada fitur yang berbeda juga akan luar biasa. Mungkin berbeda .code-uistate file di dalam .vscode terdaftar secara otomatis, atau banyak .code-uistate file yang diawali sesuai dengan .code-workspace , atau terdaftar dalam array.

Saya memikirkan ini sebagai perpanjangan dari cara kerja proyek dan ruang kerja di Sublime Text. Fungsionalitas sama, desain berbeda. Dalam hal ini, ruang kerja VS Code akan serupa dengan proyek Sublime, dan status VS Code UI yang berbeda akan serupa dengan ruang kerja Sublime.

Mengenai masalah ini:

aneh rasanya Anda bisa mengedit id dalam file hanya dengan mengetikkan nilai lain

Ya, benar-benar. Menghapus ID dari sana adalah pilihan yang tepat.

tidak begitu jelas bagaimana memperlakukan id saat berbagi file ruang kerja dengan orang lain (haruskah id diubah? haruskah id menjadi uuid?)

Nah, jika kita punya myproject.code-workspace dan myproject.code-uistate maka terserah pengguna untuk memutuskan apakah akan membagikan Status UI mereka atau tidak. Tidak perlu lagi memikirkan apa maksud ID itu, bagaimana itu dibuat, apakah itu perlu UUID untuk menghindari konflik saat berbagi, dll.
Ingin berbagi pengaturan dan pengaturan folder? Kirim myproject.code-workspace , tidak perlu khawatir.
Ingin membagikan semuanya? Kirim kedua file tersebut.

tidak mungkin untuk menyalin file ruang kerja dan membukanya di jendela terpisah, Anda harus mengubah id terlebih dahulu di file yang disalin

Jika Anda ingin memulai dengan status UI baru dengan pengaturan dan pengaturan folder yang sama, cukup gandakan file .code-workspace .

Akibatnya, tindakan "Simpan Ruang Kerja Sebagai" harus menanyakan pengguna apakah salinan harus memiliki id yang berbeda atau tidak

Itu rumit karena pengguna tidak tahu apa ID itu. Mungkin akan lebih mudah untuk memiliki dua opsi "Kloning Ruang Kerja dengan Status Saat Ini" dan "Ruang Kerja Kosong Baru". Tapi itu UX dan Anda harus melakukan analisis tentang itu.

Setuju dengan Franc, simpan semua file konfigurasi proyek di dalam pengaturan
folder dalam proyek, lihat Eclipse IDE yang memiliki hak
pendekatan. Ini memiliki konsep pengaturan proyek dan ruang kerja dengan
default proyek overwriting di ruang kerja. Ruang kerja hanyalah sebuah folder dengan
folder yang mewakili proyek. Jadi, miliki folder .vscode di ruang kerja
folder, dan setiap proyek memiliki folder .vscode . Dan tolong jangan
cukup pilih ini untuk menyebutkan Eclipse IDE.

Pada hari Sen, 18 Sep 2017 jam 20.52, Franco Gallardo Grazio <
[email protected]> menulis:

@bpasero https://github.com/bpasero IMHO, cara status UI ditangani
(jika menggunakan string ID di file .code-workspace, atau menggunakan
jalur file sebagai ID sebagai gantinya) tidak memadai.
Mengganti nama file .code-workspace, atau salah satu folder induknya, atau memindahkan
sekitar, dan kehilangan status UI menurut saya sama sekali tidak intuitif. saya
berpikir orang tidak menyadari bagaimana itu bekerja di bawah tenda akan benar-benar
tidak ada petunjuk tentang alasan mereka kehilangan status UI sebelumnya dan cara mendapatkannya
itu kembali.
Itu tidak boleh terikat dengan jalur absolut file dalam file
sistem sama sekali!

Ini berlaku untuk cara status UI terkait dengan jalur folder yang saat ini ada di
rilis stabil juga. Saya sangat bingung tentang itu pada awalnya, sampai saya
melakukan googling.

IMO Jika kita berurusan dengan hanya satu folder, status UI harus disimpan
di dalam folder .vscode. Jika kita berurusan dengan ruang kerja multi-root,
Status UI harus disimpan sebagai file terpisah di folder yang sama dengan
File .code-workspace menggunakan konvensi penamaan yang sesuai (atau mungkin
di dalam file itu sendiri, meskipun pengaturan dan status pencampuran mungkin bukan file
ide bagus).

Jika diterapkan dengan benar, ini akan memungkinkan pengguna memiliki akses penuh
ke status UI, lampirkan status UI baru ke ruang kerja tertentu (multi-root atau
tidak), dll.
Saya ingin sekali dapat menyinkronkan status UI antara komputer yang berbeda, katakanlah
bekerja di kantor, lalu pulang, mengambil laptop atau apa pun dan
melanjutkan tepat di tempat saya tinggalkan.
Memiliki beberapa status UI yang dilampirkan ke ruang kerja dan dengan mudah beralih di antaranya
mereka (menu / keybinding / command / etc) saat bekerja pada fitur yang berbeda akan
jadilah luar biasa juga. File .code-uistate yang mungkin berbeda di dalam .vscode
terdaftar secara otomatis, atau banyak file .code-uistate yang diawali menurut
ruang kerja .code utama, atau tercantum dalam larik.

Saya memikirkan ini sebagai perpanjangan dari bagaimana proyek dan ruang kerja
bekerja di Sublime Text. Fungsionalitas sama, desain berbeda. Dalam hal ini a
Ruang kerja VS Code akan mirip dengan proyek Sublime, dan berbeda
VS Code UI menyatakan akan mirip dengan ruang kerja Sublime.

Mengenai masalah ini:

aneh rasanya Anda bisa mengedit id di file hanya dengan mengetik
nilai lain

Ya, benar-benar. Menghapus ID dari sana adalah pilihan yang tepat.

tidak begitu jelas bagaimana memperlakukan id saat berbagi file ruang kerja
dengan orang lain (haruskah id diubah? haruskah id menjadi uuid?)

Nah, jika kita punya myproject.code-workspace dan myproject.code-uistate
maka terserah pengguna untuk memutuskan apakah akan membagikan Status UI mereka atau tidak.
Tidak perlu lagi memikirkan apa arti ID itu, bagaimana itu dibuat, jika perlu
UUID untuk menghindari konflik saat berbagi, dll.
Ingin berbagi pengaturan dan pengaturan folder? Kirim myproject.code-workspace,
siapa Takut.
Ingin membagikan semuanya? Kirim kedua file tersebut.

itu tidak mungkin untuk menyalin file ruang kerja dan membukanya secara terpisah
jendela, Anda harus mengubah id terlebih dahulu di file yang disalin

Jika Anda ingin memulai dengan status UI baru dengan pengaturan folder yang sama dan
pengaturan hanya menggandakan file .code-workspace Anda.

Akibatnya, tindakan "Simpan Ruang Kerja Sebagai" harus meminta
pengguna jika salinan harus memiliki id yang berbeda atau tidak

Itu rumit karena pengguna tidak tahu apa ID itu. Mungkin itu
lebih mudah untuk memiliki dua opsi "Gandakan Ruang Kerja dengan Saat Ini
Status "dan" Ruang Kerja Kosong Baru ". Tapi itu UX dan Anda harus melakukan
analisis tentang itu.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

-
Daniel Sokolowski
Arsitek Teknis

Stantive Technologies Group Inc.
Telepon: +1 (613) 634-7410
http://www.stantive.com

Pemberitahuan Kerahasiaan:
Informasi yang dikirimkan hanya ditujukan untuk orang atau entitas
yang ditujukan dan mungkin berisi rahasia dan / atau hak istimewa
bahan. Setiap penyebarluasan transmisi ulang ulasan atau penggunaan lain dari atau
mengambil tindakan apa pun yang mengandalkan informasi ini oleh orang atau
entitas selain penerima yang dituju dilarang. Jika Anda menerima
ini karena kesalahan, harap segera hubungi pengirim melalui pengembalian elektronik
transmisi dan kemudian segera hapus transmisi ini termasuk semua
lampiran tanpa menyalin mendistribusikan atau mengungkapkan sama.

@danielsokolowski Saya memahami gagasan proyek yang menimpa ruang kerja untuk pengaturan. Di vscode Anda memiliki pengaturan umum, pengaturan pengguna (over menulis umum), dan pengaturan ruang kerja (lebih menulis pengguna atau umum). Setiap proyek sudah memiliki kesempatan untuk memiliki folder .vscode-nya sendiri (pengaturan ruang kerja ada di dalamnya). Apakah Anda menyarankan folder tambahan yang akan mengumpulkan proyek hanya untuk berbagi informasi pengaturan? Itu akan tampak mirip dengan file / folder " solusi " dalam istilah studio visual.

@fgallardograzio Memiliki konfigurasi proyek yang bercampur dengan pengaturan dalam file yang sama akan memaksa penggandengan. Barang ui terdengar jauh lebih baik sebagai fitur lain yang terpisah dari tiket edisi ini. Sekarang Insiders build memiliki tata letak yang bagus dari root tambahan di file tersebut, mungkin ekstensi dapat mengisi celah untuk bagian ui. Terima kasih. Selamat siang.

@Yemi , ya, jadi Elcipse mengizinkan saya membuka ruang kerja yang berbeda
hanya folder yang berisi berbagai sub-folder untuk mewakili proyek. saya
secara pribadi menggunakan dua ruang kerja, satu untuk mengembangkan Eclipse IDE dan satu lagi untuk
semua proyek terkait pekerjaan saya. Pengambilan utama adalah bahwa pengaturannya adil
file yang dapat dibaca manusia yang disimpan di folder pengaturan masing-masing - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
ini sangat logis bagi saya.

Komentar / tip yang layak disebutkan untuk IDE apa pun, dalam situasi yang Anda alami
proyek mandiri, katakan workspace/your-awesome-library yang Anda inginkan
termasuk sebagai bagian dari proyek lain
workspace/my-wiget/libraries/your-awesome-library satu dapat menggunakan sambungan
atau hardlink tergantung OS - menurut saya ini lebih bersih dari subrepos git / hg
konsep.

Pada Selasa, 19 Sep 2017 pukul 10.33 Yemi Bedu @ P&R [email protected]
menulis:

@danielsokolowski https://github.com/danielsokolowski Saya mengerti
gagasan proyek menimpa ruang kerja untuk pengaturan. Di vscode Anda
memiliki pengaturan umum, pengaturan pengguna (over menulis umum), dan ruang kerja
pengaturan (lebih menulis pengguna atau umum). Setiap proyek sudah memiliki
Kesempatan untuk memiliki folder .vscode sendiri (pengaturan ruang kerja tinggal di dalamnya).
Apakah Anda menyarankan folder tambahan yang akan menumpuk proyek hanya untuk
berbagi informasi pengaturan? Itu terlihat mirip dengan " solusi "
file / folder dalam istilah studio visual.

@fgallardograzio https://github.com/fgallardograzio Memiliki proyek
konfigurasi yang bercampur dengan pengaturan dalam file yang sama akan memaksa
kopel. Barang ui terdengar jauh lebih baik sebagai fitur lain yang terpisah dari
tiket masalah ini. Sekarang Insiders build memiliki tata letak file
akar ekstra di file tersebut, mungkin ekstensi dapat mengisi celah untuk ui
bagian. Terima kasih. Selamat siang.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

-
Daniel Sokolowski
Arsitek Teknis

Stantive Technologies Group Inc.
Telepon: +1 (613) 634-7410
http://www.stantive.com

Pemberitahuan Kerahasiaan:
Informasi yang dikirimkan hanya ditujukan untuk orang atau entitas
yang ditujukan dan mungkin berisi rahasia dan / atau hak istimewa
bahan. Setiap penyebarluasan transmisi ulang ulasan atau penggunaan lain dari atau
mengambil tindakan apa pun yang mengandalkan informasi ini oleh orang atau
entitas selain penerima yang dituju dilarang. Jika Anda menerima
ini karena kesalahan, harap segera hubungi pengirim melalui pengembalian elektronik
transmisi dan kemudian segera hapus transmisi ini termasuk semua
lampiran tanpa menyalin mendistribusikan atau mengungkapkan sama.

Apakah fitur ini masih belum ditambahkan?

Ini sangat penting bagi saya. Saya sedang mengerjakan proyek yang terdiri dari 2 repositori terpisah: web frontend, dan api. Alangkah baiknya jika saya bisa membuka kedua folder ini dalam satu "proyek".

Tentu, saya dapat menyelesaikan ini dengan mengkloning 2 repo ke dalam satu folder dan membuka folder itu tetapi ini tidak berfungsi untuk setiap kasus. Terutama jika Anda memiliki beberapa proyek yang bergantung pada satu repositori (yaitu berbagi API yang sama).

Fitur ini juga akan berguna bagi mereka yang menggunakan kode sebagai dokumentasi.

@JamesTheHacker untuk sementara menggunakan vscode-insiders yang mendukung banyak proyek pada waktu yang sama. Dan Anda dapat menyarankan fitur tergantung pada apa yang Anda rasakan dengan versi orang dalam untuk membuatnya lebih baik

Saat ini dikirimkan, versi VSCode mungkin akan beralih ke 2.0. Hanya mengatakan :)

Pertanyaan singkat tentang fitur ini:

Fitur ini mendukung penambahan banyak folder dengan repositori ke ruang kerja yang ada. Apakah itu juga mendukung konfigurasi mono-repo, di mana saya ingin membuka banyak proyek dalam mono-repo, tetapi karena mereka berada dalam satu repo, mereka tidak memiliki git repo sendiri. Jadi dari sudut pandang proyek, mereka tidak memiliki folder .git - salah satu folder leluhur memilikinya.

Anda mungkin bertanya mengapa tidak membuka folder mono-repo sebagai satu folder besar dan hanya bekerja di sana? Ada dua jawaban:

1. (kurang menarik bagi saya) terlalu banyak proyek di mono-repo, dan saya hanya tertarik pada beberapa di antaranya.
2. Banyak plugin berasumsi bahwa sebuah proyek hanya berisi satu ... proyek. Misalnya, hanya satu paket npm. Jadi mereka mencari hal-hal di _root_ proyek. Contoh: plugin npm untuk VSCode, plugin mocha untuk vscode, dan banyak fungsi di VSCode itu sendiri - misalnya, saya tidak dapat menentukan jalur di launch.json yang relatif terhadap file saat ini, yaitu "folder node_modules yang merupakan leluhur terdekat dari file saat ini".

Setelah penjelasan kontekstual ini, pertanyaan saya sederhana - apakah fitur ini akan mendukung proyek yang folder .git adalah leluhur dari root mereka? Jika demikian, maka dimungkinkan untuk menggunakan fitur ini dalam mono-repo.

@borbb Ya. Saya tidak tahu bagaimana orang-orang di Microsoft mengelola versi mereka, tetapi saya pikir ini adalah fitur yang cukup masif untuk jurusan

Setelah penjelasan kontekstual ini, pertanyaan saya sederhana - apakah fitur ini akan mendukung proyek yang folder .git adalah leluhur dari root mereka? Jika demikian, maka dimungkinkan untuk menggunakan fitur ini dalam mono-repo.

Ini sudah didukung sejak lama, jika Anda hanya membuka subfolder dari repo git.

+1

Sublime dan Atom melakukannya, Anda harus melakukannya. Tidak ada alasan yang lebih baik. Ini MS BARU, selesaikan semuanya, saya percaya sepenuhnya pada Anda. :)

Halo,
@inestyne jika Anda membaca posting sebelumnya seperti dari @Jeyanthinath Anda akan mengetahui menggunakan VSCode Insiders untuk mengevaluasi fitur ini. Bahkan ada peta jalan untuk diperiksa. Jadi silakan gunakan produk dan berikan umpan balik sebelum bermigrasi ke stabil sehingga kita semua mendapatkan produk terbaik. Terima kasih. Selamat siang.

Cukup baca utasnya dan gunakan Insiders OMG. Saya akan berhenti berlangganan ... Anda troll yang tidak membaca tidak mungkin. Terima kasih @ pr-yemibedu

Peka

Karena utas ini berdurasi 2 tahun, dan fitur tersebut tampaknya ada dalam versi Insiders sekarang, apakah ada cara untuk menandai utas ini sehingga lebih jelas daripada membaca seluruh utas dari atas?

Satu hal yang hilang adalah kemampuan untuk membuka jendela baru dengan ruang kerja baru dari CLI.

@jearle Jendela baru / ruang kerja harus dibuat seperti sebelumnya dengan code-insiders <folder> , bukan?
code-insiders -a <folder> diperlukan untuk menambahkan folder ke jendela saat ini.

@Jeyanthinath terima kasih! Telah melakukan hal yang sama dengan @JamesTheHacker dan itu akan membantu saya!

@Tyriar untuk mendapatkan fungsionalitas yang saya inginkan, saya harus menjalankan perintah berikut:

code .; code -a .

code . membuka folder sebagai bukan ruang kerja, dan kemudian code -a . menempelkan dirinya ke jendela yang sebelumnya terbuka sebagai ruang kerja yang memungkinkan saya membuka folder yang sama lebih dari sekali.

Menurut saya pribadi ini juga perlu diubah. Saya bekerja dengan ionic dan server khusus dalam dua repo git yang berbeda dan itu tidak terlalu mudah. Kemampuan untuk setidaknya memiliki dua "tab proyek" yang terbuka atau sesuatu akan sangat bagus.

Saya beralih dari Atom karena seberapa buggy dan lambatnya.

@ dark-swordsman Anda dapat mengaktifkan nativeTabs di mac

@felixfbecker apakah ini mungkin pada Windows?

Sunting: Saya mencari melalui file pengaturan sepenuhnya dan tidak ada pilihan untuk itu. Itu sebabnya saya bertanya.

Edit2: Juga, tidak ada sumber yang jelas tentang bagaimana mengaktifkan vs insiders

Halo,
@ dark-swordsman Anda tidak mengaktifkan VS Insiders. Ini adalah build dari VSCode yang memiliki beberapa fitur tambahan yang belum diselesaikan menjadi stabil dan dengan cara tertentu memberi Anda ruang nama editor tambahan untuk digunakan (Anda dapat menginstalnya secara berdampingan tanpa konflik pengaturan atau ekstensi). Terima kasih. Selamat siang.

Dukungan untuk ruang kerja multi-root sekarang diaktifkan secara default di rilis stabil.

Silakan lihat dokumentasi kami untuk penjelasan lengkap tentang semua fitur yang menyertainya. Penulis ekstensi harus merujuk ke wiki kami yang menjelaskan API ekstensi baru untuk membuat ekstensi Anda siap untuk ruang kerja multi-root. Kami senang bahwa beberapa ekstensi sudah mulai mengadopsi API multi-root baru, terima kasih untuk itu!

Harap jangan ragu untuk mengajukan masalah untuk multi-root saat Anda menemukannya, kami masih berencana membuat perubahan dan menyediakan API tambahan agar ekstensi dapat bekerja dengan ruang kerja multi-root di masa mendatang.

Ini bagus, tapi kapan akan tersedia? Anda mengatakan itu dalam build stabil, tetapi saya memiliki build Stabil terbaru (1.17.2) dan tidak dapat memperbaruinya. Selain itu, dalam dokumentasi yang baru saja Anda referensikan, dikatakan bahwa itu masih dalam build Insider dan akan segera dirilis dalam versi stabil.

Saya mengerti mungkin sedikit waktu sebelum build berikutnya dirilis, tetapi saya melihat notifikasi ini mengharapkannya tersedia.

Edit: Saya minta maaf atas ketidaksabaran saya. Saya hanya mencoba membuka jendela baru dengan cara manual (panggil .exe lagi) dan itu tidak berfungsi, tetapi tidak melihat di File> Buka Jendela Baru. Ini akan berhasil untuk saat ini. Menantikan rilis build berikutnya. 👍

@bpasero Harap tutup masalah terbuka # 35849 ini karena fungsionalitas yang diharapkan telah dilakukan sebagai bagian dari fitur # 396 ini.

Hanya pertanyaan singkat. Apakah mungkin, setelah saya membuka lebih banyak folder, untuk mengganti folder mana yang ingin saya kompilasi? Saat ini itu selalu yang pertama dalam versi stabil.

EDIT: Ini mungkin untuk pembuat ekstensi PlatformIO, tetapi saya bertanya di kedua sisi. Untuk berjaga-jaga...

@DJManas Sepertinya ini terserah pada ekstensi yang Anda gunakan untuk memutuskan, jadi Anda harus bertanya kepada pembuat ekstensi.

@bpasero Ok, saya lakukan secara paralel, terima kasih atas balasannya.