Three.js: Lanjutkan dukungan untuk perpustakaan JS bersama perpustakaan ES6 JSM

Jika saya mengerti dengan benar rencananya adalah tetap menyertakan "/build/three.js" di samping "/build/three.module.js".

Ya. Namun, patut dipertanyakan apakah pendekatan ini masuk akal. Ketika examples/js dihapus, hanya ada beberapa kasus penggunaan yang tersisa di mana three.js dan three.min.js masih berguna.

Sebenarnya akan bermanfaat untuk menghapus three.js dan three.min.js karena akan memungkinkan kita untuk mengubah titik masuk main dari paket npm , lihat #19575.

Jika kita dapat melakukannya dengan mudah, saya yakin masuk akal untuk terus mendukung /examples/js dengan membuatnya secara otomatis melalui skrip bundler ES6 sebagai bagian dari proses pembuatan.

Idenya adalah untuk memindahkan examples/jsm ke fitur bahasa JavaScript yang lebih modern seperti kelas. Karena examples/js masih dapat digunakan dengan browser lama, maka perlu untuk mengonfigurasi (contoh) build baru dengan fitur transpilasi kode. Selain itu, kami masih akan mempertahankan basis kode duplikat ( examples/js vs examples/jsm ) yang menurut saya merupakan pendekatan yang buruk. Itu membuat perawatan lebih rumit.

Saya percaya pengguna harus mengurus konversi ES6 ke ES5 jika diperlukan. Sama untuk minifikasi kode atau tugas terkait build lainnya.

Saya percaya Anda benar. Jika saya mengerti dengan benar rencananya adalah tetap menyertakan " /build/three.js " selain " /build/three.module.js ".

benar

Masalah dengan file dari folder /examples adalah Anda perlu menggunakan file dari /examples/js saat Anda menggunakan /build/three.js dan file dari /examples/jsm saat Anda menggunakan /build/three.module.js , alias menjaga konsistensi dalam metode pemuatan.

Mengapa? Karena saat menggunakan modul, impor objek utama THREE bukan lagi objek js biasa THREE = {} melainkan objek modul browser internal yang disegel (tidak dapat diperpanjang), oleh karena itu, file dari /examples/js yang mencoba menulis properti baru di objek THREE gagal.

Jadi Anda tidak dapat mencampur import * as THREE from '/build/three.module.js dan THREE.WhateverExample = function() ...

Salah satu cara yang mungkin adalah mengubah nama lib yang diimpor menjadi apa pun selain THREE dan membuat ulang objek global js THREE polos untuk contoh yang akan ditulis di dalamnya...

Ini biasanya masalah

JS tradisional termasuk

yang mencemari penamaan ruang global, dan karena Anda tidak dapat mengubah nama ke dalam file yang dimuat, Anda mungkin mendapatkan kesalahan seperti itu...
Di sisi lain, dengan modul, pengguna mendapatkan kekuatan penamaan selama impor dan bukan lagi penulis lib yang memilih nama yang dihasilkan...

mantan:

<script>
// a script you can't modify already use the name THREE
var THREE = document.getElementById('div-nb-3')
</script>

<script type="module">
import * as foo from '/build/three.module.js'

THREE.appendChild( new foo.WebGLRenderer().domElement )
</script>

@ Mugen87 Anda 100% benar. Jika kita membuang /examples/js, kita mungkin juga membuang three.js & three.min.js karena pada dasarnya tidak kompatibel dengan modul tambahan mana pun. Kasus penggunaan mereka akan menjadi niche dan ini hampir dijamin akan membuat kebingungan.

@devingfx Anda benar bahwa modul memiliki kelebihan dan menghilangkan potensi konflik nama global. Selama bertahun-tahun penggunaan saya tidak pernah memiliki konflik apa pun dengan TIGA variabel global dan saya pikir ini adalah skenario yang tidak mungkin tetapi poin Anda secara teknis benar.

yang menurut saya pendekatan yang buruk. Itu membuat perawatan lebih rumit.

Saya percaya pengguna harus mengurus konversi ES6 ke ES5 jika diperlukan. Sama untuk minifikasi kode atau tugas terkait build lainnya.

@ Mugen87 Apakah benar-benar mengerikan mempertahankan penyertaan js tradisional yang menggunakan var global selain modul? Banyak perpustakaan mendukung keduanya dan dari apa yang saya tahu versi JS tradisional sering sama populernya digunakan sebagai rekan versi modul. Keduanya memiliki kelebihan/kekurangan dan beberapa di antaranya bermuara pada preferensi. Apakah tidak baik memberi pengembang opsi untuk menggunakan perpustakaan dalam konteks non-modul?

Saya bersedia mengurus pembuatan/pengujian fitur transpilasi kode yang diperlukan untuk secara otomatis menghasilkan three.min.js, three.js dan /examples/js dari three.module.js dan /examples/jsm . Setelah alur kerja transpilasi telah disempurnakan, mungkin memerlukan beberapa perawatan minimal tetapi != mempertahankan dua versi paralel. Untuk sebagian besar kode hanya perlu diperbarui pada file modul dan hanya sesekali Anda perlu memperbaiki beberapa kesalahan transpilasi.

Saya memiliki cukup banyak proyek yang mengandalkan sintaks global tradisional dan termasuk bahwa saya akan melakukan pekerjaan untuk mengotomatisasi transpilasi modul. Saya pikir setidaknya kita bisa memasukkan perintah dalam package.json dan menyebutnya "legacy-build" yang mengubah modul menjadi three.min.js, three.js dan /examples/js yang berperilaku mirip dengan aslinya file sekarang. File-file ini bahkan tidak harus dikomit ke repo atau dibuat secara default. Kami juga dapat memperingatkan mereka untuk dukungan warisan, mereka tidak dijamin untuk bekerja, kami sarankan menggunakan modul sebagai gantinya dll...

Meskipun secara realistis saya pikir lebih masuk akal menyimpannya di repo dan membuatnya secara otomatis dihasilkan melalui transpiling pada build.

perintah di package.json dan menyebutnya "legacy-build" yang mentranspilasikan modul

tampaknya masuk akal. bukankah babel bergabung baru-baru ini? jadi saya pikir ini mungkin bisa dilakukan apa adanya

edit: untuk memperjelas, tidak mengatakan perintah baru untuk dijalankan oleh siapa pun kecuali pengguna yang ingin kata build

Apakah benar-benar mengerikan untuk mempertahankan penyertaan js tradisional yang menggunakan var global selain modul?

Saya pikir kerumitan mempertahankan ini sedang di bawah perkiraan. Sayangnya saya tidak berpikir itu begitu sederhana dengan cara contoh diatur dalam proyek.

Mari kita lihat GLTFLoader sebagai contoh. Saat ini semua GLTFLoader terkandung dalam satu file yang membuatnya mudah untuk disertakan di bagian atas file HTML. Salah satu manfaat modul adalah beberapa file yang lebih besar dapat dipecah menjadi file terpisah yang dapat diimpor oleh GLTFLoader sebagai dependensi. Seperti apakah tampilan skrip global yang dibuat setelah GLTFLoader bergantung pada empat file eksternal yang beberapa di antaranya dibagikan? Akankah pengguna skrip global yang dibangun sekarang harus memasukkan semua contoh file js itu satu per satu? Atau akankah beberapa file dibundel bersama yang memerlukan pemeliharaan daftar file secara manual yang boleh digabungkan dan mana yang tidak?

Saya pikir satu-satunya kasus yang benar-benar diatur dan dilupakan adalah menggabungkan semua contoh file js ke dalam satu gumpalan monolitik yang menurut saya tidak masuk akal. Saya pikir dengan salah satu dari solusi ini akan ada beberapa rilis dan dokumentasi overhead lainnya, juga.

Mungkin ada cara yang lebih baik untuk melakukannya, tetapi ketika saya mencoba membuat rollup build yang mempertahankan kompatibilitas mundur atau setidaknya struktur yang konsisten untuk file js yang ada, inilah masalah yang saya hadapi.

Jika saya mengerti dengan benar rencananya adalah tetap menyertakan "/build/three.js" di samping "/build/three.module.js".

Ya. Namun, patut dipertanyakan apakah pendekatan ini masuk akal.
Ketika contoh/js dihapus, hanya ada beberapa kasus penggunaan yang tersisa di mana three.js dan three.min.js masih berguna.

@Mugen87 @mrdoob

Michael,
Sebenarnya untuk menyimpan "three.min.js" setidaknya selama 2 tahun lagi adalah suatu KEHARUSAN.
Bukan karena semua sampel saya didasarkan pada itu.
Tetapi karena ribuan file dan anjing top Google didasarkan padanya!
Contoh: https://www.google.com/search?source=hp&q=webgl+benchmark

Di sisi lain, dari sudut pandang saya, "three.min.js" berarti pengembangan dan pengujian yang lebih cepat.
Belum lagi itu berfungsi offline dan Anda tidak memerlukan localhost.
Letakkan saja semua file di folder di suatu tempat, gunakan Firefox dan klik dua kali file HTML.
Saya selalu menyukainya untuk pengembangan!

Ricardo juga harus memikirkan semua ini.
Bersulang

Penghapusan three.js dan three.min.js adalah sesuatu yang dapat didiskusikan dan direncanakan ketika examples/js hilang. Penting bagi saya untuk menyoroti kehilangan signifikansinya ketika Anda tidak dapat mengimpor file dari examples/js lagi.

Saya pikir kerumitan mempertahankan ini sedang di bawah perkiraan. Sayangnya saya tidak berpikir itu begitu sederhana dengan cara contoh diatur dalam proyek.

Saya sangat menyukai poin yang Anda kemukakan. Ada kerumitan yang sama sekali tidak terduga dalam bundling dan contoh modul bersarang adalah contoh yang bagus. Menurut pendapat Anda, saya pikir kita dapat mengambil keputusan yang masuk akal tentang bagaimana menangani bundling modul bersarang ketika saatnya tiba. Saya tidak mengatakan skrip bundler akan menjadi satu set dan lupakan situasinya, hanya saja itu akan menjadi pemeliharaan yang lebih rendah.

Jika saatnya tiba di mana terlalu sulit untuk mempertahankannya, kita selalu bisa membuangnya, tapi menurut saya konyol untuk mengabaikan mencoba karena masalah yang belum kita miliki. Ini akan lebih mudah untuk diterapkan sekarang sementara kita masih memiliki paritas 1 banding 1 antara /examples/jsm dan example /js . Kami mungkin tidak akan mengatur ulang hierarki modul /example/jsm secara besar-besaran dan saya pikir kami dapat membuat pembaruan tambahan untuk bundler ketika kami melakukannya. Saya akan melanjutkan dan mulai mengerjakan bukti kerja untuk ini (dengan babel karena sudah ditambahkan?) untuk menaruh uang saya di tempat mulut saya seperti yang mereka katakan.

Menurut pendapat Mugen, ini akan membantu menjaga relevansi dengan three.js dan three.min.js sementara kami terus mempertahankannya. Itu juga dapat membantu ratusan situs yang mungkin mencari pembaruan yang kompatibel dengan implementasi TIGA berbasis non-modul mereka. Pemfaktoran ulang proyek TIGA untuk menggunakan modul bisa sangat luas bahkan jika Anda tahu apa yang Anda lakukan.

Saya tidak dapat berbicara mewakili kolaborator lain tetapi saya tidak akan berubah pikiran tentang topik ini. Saya memilih untuk menghapus examples/js dengan rilis Desember pada tahun 2020 seperti yang dibahas dan berkomitmen di sini #18749.

Saya memilih untuk menghapus contoh/js dengan rilis Desember pada tahun 2020 seperti yang dibahas dan dilakukan di sini #18749.

Saya tidak punya masalah dengan itu.
Selama "three.min.js" tersedia untuk beberapa tahun lagi ...

Terima kasih atas masukannya Mugen, saya memang membaca utas itu tetapi tampaknya lebih merupakan pengumuman daripada penjelasan untuk keputusan tersebut. Asumsi saya adalah bahwa pengembangan yang disederhanakan adalah alasan utama untuk bergerak ke arah ini, apakah ada yang lain?

Saya pikir memiliki skrip transpilasi yang dapat kita jalankan untuk menghasilkan /examples/js style termasuk harus menjadi kompromi yang oke di sini. Ini harus mengurangi jumlah pemeliharaan/komplikasi yang diperlukan di sini secara drastis. Saya bahkan akan baik-baik saja jika itu hanya perintah di package.json yang harus Anda jalankan sendiri dan file tidak dibuat secara default. Ada manfaat untuk beberapa pengembang dan yang lain yang perlu diubah. Saya lebih suka kita semua tidak membuat alur kerja transpilasi/bundel sendiri secara terpisah ketika sesuatu dapat disimpan di repo utama untuk memungkinkan kita berkolaborasi dengan lebih baik. :)

Saya memang membaca utas itu tetapi tampaknya lebih merupakan pengumuman daripada penjelasan untuk keputusan tersebut.

Sayangnya kami tidak selalu dapat menyematkan semua argumen yang valid ke satu utas, baik karena realisasi perubahan desain perlahan-lahan berkembang pada banyak diskusi selama bertahun-tahun, atau hanya karena beberapa utas tentang subjek yang sama dibuat berulang-ulang (seperti ini ). Kolaborator mencoba meminimalkan kebisingan dan segmentasi, tetapi itu tidak selalu memungkinkan.

Asumsi saya adalah bahwa pengembangan yang disederhanakan adalah alasan utama untuk bergerak ke arah ini, apakah ada yang lain?

Yang terbesar yang saya lihat adalah kemampuan untuk menggunakan dan mengimpor sub-modul yang meminimalkan kode yang berlebihan dan membuat implementasi yang dapat digunakan kembali.

Misalnya, sebagian besar loader perlu membuat semacam struktur/kelas penguraian data, ini karena setiap loader harus mandiri sehingga file example/js dapat digunakan kembali. Namun, jika kita sepenuhnya menghapus batasan non-modular, kita akan dapat membuat satu instance dari kelas DataParser dan mengimpor implementasi standar tersebut pada semua loader, dengan segera membuat pengembangan menjadi lebih mudah dan juga menghapus kode yang berlebihan dari semua loader.

Ya, poin yang bagus. Kita sudah harus melakukan peretasan kotor seperti menyematkan kelas Pass (kelas dasar dari semua pass FX) ke dalam EffectComposer hanya untuk memastikan kode lawas tidak rusak.

poin yang sangat bagus dibuat secara menyeluruh.

mendapatkan dan menjaga orang-orang tetap on-track/up-to-date terdengar seperti (dan dari pengalaman saya sendiri) masalah yang sulit. akan mencoba menaruh beberapa pemikiran ke dalam ini.

Sebenarnya untuk menyimpan "three.min.js" setidaknya selama 2 tahun lagi adalah suatu KEHARUSAN.

Akan selalu memungkinkan untuk membuat build ES5 menggunakan Babel. Pertanyaan yang harus kami jawab adalah apakah tanggung jawab ini ada pada kami atau pengembang yang menggunakan three.js.

Kami telah memutuskan bahwa pengembang akan membuat versi ES5 dari file contoh, jadi mungkin masuk akal untuk melakukan hal yang sama untuk file build. Menurut saya, masuk akal juga untuk melakukan ini di seluruh perpustakaan dalam satu rilis daripada membuangnya, tetapi mempertahankan three.min.js sedikit lebih lama juga baik-baik saja.

Tetapi karena ribuan file dan anjing top Google didasarkan padanya!
Contoh: google.com/search?source=hp&q=webgl+benchmark

Ini adalah situs teratas yang muncul untuk saya dari pencarian itu, dan mereka menggunakan R53 jadi saya tidak berpikir perubahan ini akan mempengaruhi mereka terlalu buruk: https://www.wirple.com/bmark/

Seperti yang Anda lihat, versi lama dari three.js masih berfungsi dengan baik. Setelah kami melakukan transisi ke modul, kami dapat mengarahkan siapa saja yang menginginkan build ES5 tanpa menggunakan Babel untuk menggunakan versi terakhir sebelum kami menghapus file ES5. Mereka dapat memeriksa seluruh repo rilis itu dan menggunakan dokumen dari versi itu juga.

@looeee Anda menyentuh beberapa poin bagus. Seperti disebutkan di atas, saya setuju bahwa masuk akal untuk menghentikan ES5 three.min.js dan three.js secara bersamaan di sini. Mungkin itu harus menjadi diskusi tersendiri?

Either way saya ingin mencapai konsensus tentang memasukkan skrip babel di repo utama yang dapat digunakan untuk menghasilkan file /js/example gaya ES5 sekolah lama. Ini sama sekali bukan tentang apakah ada orang yang bertanggung jawab untuk memberikan dukungan ini. Ada kontributor, seperti saya, yang akan membutuhkan fitur ini. Ada manfaat untuk beberapa pengembang dan yang lain yang perlu diubah. Saya lebih suka kita semua tidak membuat alur kerja transpilasi/bundel sendiri secara terpisah ketika sesuatu dapat disimpan di repo utama untuk memungkinkan kita berkolaborasi dengan lebih baik.

Saya pikir ini adalah kompromi yang adil untuk mengizinkan kami satu file di repo utama sehingga kami dapat mengerjakan skrip transpiler babel ES6 ke ES5 bersama-sama. Apakah benar-benar ada masalah di sana? Mengizinkan kontributor mengerjakan fitur yang mereka butuhkan bersama di repo utama?

Saya tidak meminta kolaborator untuk bantuan atau sumber daya apa pun dalam melakukan ini, saya hanya meminta Anda mengizinkan orang yang membutuhkan ini untuk dapat mengerjakannya bersama di repo utama. Jika saya membuat PR untuk ini dan berhasil, apakah Anda akan benar-benar memilih untuk menolaknya?

Jika saya membuat PR untuk ini dan berhasil

Maksudku, aku senang melihat ini dimulai

apakah Anda benar-benar akan memilih untuk menolaknya?

tehe semua taruhan akan dibatalkan jika gagal lulus linting 😂

Apakah benar-benar ada masalah di sana?

Ya, karena repositori tidak boleh mempromosikan pola pengkodean yang tidak digunakan lagi.

Ya, karena repositori tidak boleh mempromosikan pola pengkodean yang tidak digunakan lagi.

Ini belum secara resmi ditinggalkan jika kita tidak memecat three.js + three.min.js (mengakui konsensus ITT adalah kita harus memecatnya juga) dan memiliki skrip babel yang harus Anda jalankan secara manual sendiri adalah hampir tidak ada dukungan yang bersinar. Saya setuju kita pasti harus mendorong orang untuk menggunakan modul sebagai gantinya dan memiliki peringatan di skrip babel dan membuat file tentangnya. Saya tidak setuju mengizinkan kontributor untuk mengerjakan skrip babel bersama untuk orang-orang dalam situasi yang tidak dapat menggunakan modul karena alasan apa pun yang mempromosikan pola pengkodean yang sudah usang. Terutama karena masih ada situasi di mana menggunakan modul tidak layak/tidak praktis. Dokumen mengakui kebutuhan ini. Saya pikir kita dapat dengan aman menambahkan satu file untuk orang-orang yang membutuhkannya untuk mengerjakannya bersama-sama.

Saya setuju bahwa masuk akal untuk menghentikan ES5 three.min.js dan three.js secara bersamaan di sini.

Maksud saya, kita harus menghentikan contoh/js, three.min.js, dan three.js secara bersamaan, yaitu menghapus semua kode ES5 dalam satu rilis daripada menyebar ke beberapa rilis.

@Mugen87

Ya, karena repositori tidak boleh mempromosikan pola pengkodean yang tidak digunakan lagi.

Anda masih dapat menjalankan game DOS di Windows 10.
Dan itu tidak berarti Microsoft mempromosikan "pola pengkodean yang sudah usang".

Hanya untuk memperjelas contoh modul js seperti yang dipertahankan dalam proyek ini tidak memerlukan node, npm, atau kerangka kerja build apa pun untuk digunakan.

Jangan lupa bahwa membangun aplikasi siap produksi berarti menggabungkan kode Anda :)

Saya menghargai alat bundling seperti Rollup yang tersedia tetapi menurut saya kita harus mempertimbangkan beberapa pertanyaan:

• Apakah adil untuk berasumsi jika pengembang ingin menggunakan TIGA dalam produksi, mereka juga perlu menggunakan salah satu alat bundling ini?
• Apakah adil untuk menghentikan dukungan untuk perpustakaan lain yang mengandalkan pembaruan modul ES5/UMD di folder contoh?

Perasaan pribadi saya tentang ini:

Perpustakaan ini berusia satu dekade. Ada ekosistem besar di luar sana yang bergantung pada modul di folder contoh yang ditulis dalam ES5/UMD. Saya tidak berpikir itu adil untuk menjatuhkan dukungan untuk seluruh ekosistem.

Saya pikir orang lupa bahwa Anda masih dapat menggunakan ES6 tanpa pola bundling modul. Saya menggunakan ES6 setiap hari tetapi tidak menggunakan pola bundling modul di aplikasi frontend saya. Saya telah bekerja di toko-toko perusahaan di mana membangun alat menjadi sangat khusus karena kebutuhan dan tidak akan dapat menggabungkan pola bundling modul.

Apa yang harus kita lakukan?

Mari kita kompilasi Modul ES6 menjadi modul ES5/UMD untuk distribusi tertentu setelah setiap rilis.

Ya, karena repositori tidak boleh mempromosikan pola pengkodean yang tidak digunakan lagi.

Untuk hampir semua hal dalam hidup, sebuah solusi masih bisa berkualitas tinggi menggunakan pola, teknik, dan perkakas yang lebih tua.

Sebagai analogi - Di waktu luang saya, saya menikmati ukiran batu dengan pahat titik. Alat dan tekniknya berbeda dari alat listrik, tetapi pada akhirnya patung itu akan tetap berkualitas tinggi. Saya telah menerapkan preferensi pribadi untuk menggunakan pahat titik karena saya senang menggunakannya dan memiliki keterampilan yang dibutuhkan untuk menghasilkan sesuatu yang saya atau orang lain senangi.

Saya merasakan hal yang sama tentang modul ES5/UMD. Saya telah dapat menemukan pola, teknik, dan alat yang menjunjung tinggi basis kode berkualitas tinggi dan ingin terus menggunakan preferensi pribadi itu.

Mari kita kompilasi Modul ES6 menjadi modul ES5/UMD untuk distribusi tertentu setelah setiap rilis.

Saya setuju dengan apa yang dikatakan looee.

Apakah adil untuk menganggap [...]

apa? Kami berbicara tentang pendekatan apa yang kami sukai, 'asumsi' muncul setelahnya. Preferensi tampaknya mengarah pada mendorong orang lain untuk menggunakan modul tetapi (dengan asumsi beberapa orang masih menginginkan TIGA lama) menawarkan jalur bagi mereka yang benar-benar menginginkannya.

Mari kita kompilasi Modul ES6 menjadi modul ES5/UMD untuk distribusi tertentu setelah setiap rilis.

Ini bisa dilakukan oleh siapa saja; biaya itu tidak perlu ditanggung oleh pengelola three.js. Saya ingin mengulangi apa yang @gkjohnson katakan di atas, biaya pemeliharaan direktori examples/js dan examples/jsm tinggi. Kami tidak dapat melakukan ini tanpa batas, dan jelas bahwa Modul ES6 adalah yang lebih modern dari dua pendekatan. Pertimbangkan biaya berikut:

• Membuat dan memelihara otomatisasi
• Men-debug kegagalan rilis saat otomatisasi rusak
• Memastikan bahwa semua permintaan tarik memperbarui file sumber, bukan yang dihasilkan
• Memelihara dokumentasi yang menjelaskan bagaimana kedua alur kerja digunakan
• Menjawab laporan bug dan pertanyaan dukungan dari pengguna yang mencoba menggunakan alur kerja CJS dan ES6

Item terakhir itu sangat mungkin yang terbesar. Selama dua salinan dari semuanya tersedia di repositori ini, keduanya akan terlihat didukung sepenuhnya. Kami secara teratur menghabiskan waktu membantu pengguna yang mengacaukan dua alur kerja atau mencoba menggunakan pemuat Modul ES6 dengan pustaka inti CJS, yang gagal dengan cara yang rumit.

Kita dapat mengulangi masalahnya dengan sederhana: semua contoh kita — yang penting tetapi bagian opsional dari perpustakaan three.js — saat ini tidak menggunakan sintaks modul sama sekali. Bukan UMD, bukan CommonJS, bukan Modul ES6. Mereka hanya menambal ruang nama global THREE . Kami ingin memperbaruinya, menggunakan sintaks impor/ekspor ES6, dan ada banyak peringatan awal bahwa perubahan ini direncanakan.

Ada ekosistem besar di luar sana yang bergantung pada modul di folder contoh yang ditulis dalam ES5/UMD. Saya tidak berpikir itu adil untuk menjatuhkan dukungan untuk seluruh ekosistem.

Saya tidak berpikir adil untuk mengatakan bahwa apa pun di ekosistem three.js sangat bergantung pada ruang nama global THREE.* sehingga tidak dapat diperbarui untuk menggunakan sintaks impor/ekspor, atau untuk transpile ke ES5, atau untuk menggunakan bundel. Ada sejumlah solusi di sini, dan kami akan dengan senang hati bekerja sama dengan pengguna untuk membantu menemukan opsi yang cocok untuk mereka.

biaya pemeliharaan direktori contoh/js dan contoh/jsm tinggi.

Saya ingin menggali lebih dalam tentang ini. Saya telah menulis banyak perkakas khusus dan membuat skrip otomatisasi untuk aplikasi ujung depan dan dengan senang hati akan membantu dengan cara apa pun yang saya bisa.

Membuat dan memelihara otomatisasi
Men-debug kegagalan rilis saat otomatisasi rusak

Bantu saya memahami pajak pemeliharaan sedikit lebih banyak, apakah ini sesuatu yang unik untuk basis kode TIGA? Dalam pengalaman saya, jenis kode ini biasanya paling lama hidup dan membutuhkan perawatan paling sedikit. Ini adalah skrip yang Anda tulis sekali dan jangan dilihat lagi untuk waktu yang lama.

Memastikan bahwa semua permintaan tarik memperbarui file sumber, bukan yang dihasilkan

Mungkin skrip atau pengujian kecil dapat membantu ini dalam alur kerja rilis.

Memelihara dokumentasi yang menjelaskan bagaimana kedua alur kerja digunakan

Saya juga akan memilih untuk menjatuhkan dokumentasi untuk ruang nama global. Saya pikir itu konyol untuk mendukung dokumentasi untuk dua alur kerja. Ini bukan hal yang buruk. Sebagian besar perpustakaan yang menggabungkan kode mereka untuk konteks yang berbeda, modul UMD/ES6 hanya memiliki satu set dokumen.

Menjawab laporan bug dan pertanyaan dukungan dari pengguna yang mencoba menggunakan alur kerja CJS dan ES6.

Saya pikir volume masalah yang terkait dengan sesuatu seperti ini relatif terhadap ukuran popularitas THREE. Anda dan saya selalu melihat masalah seperti ini di Stack Overflow. Seorang pengguna yang tidak dapat membedakan antara dua alur kerja kemungkinan adalah seorang programmer baru yang terinspirasi oleh perpustakaan dan hanya mencoba mempelajari dasar-dasar pemrograman secara umum.

Jika tujuannya adalah untuk mengurangi volume masalah yang secara khusus terkait dengan kebingungan antara dua alur kerja , maka menghapus kode ES5 mungkin akan membantu dengan itu - tetapi saya ragu volume masalah secara keseluruhan akan berubah. Seorang programmer baru akan selalu terjebak pada pertanyaan berikutnya yang mungkin atau mungkin tidak terkait dengan perpustakaan.

Bagaimana cara mengurangi volume masalah secara keseluruhan?

Jika tujuan sebenarnya adalah untuk mengurangi volume masalah secara keseluruhan, mungkin kebijakan masalah yang lebih ketat dapat membantu dengan itu. Saya melihat kalian melakukan pekerjaan yang hebat dengan ini sudah menggunakan tag seperti Help (please use the forum) tapi mungkin perlu ada lebih banyak hal semacam ini.

Secara umum mungkin lebih baik untuk hanya menguraikan beberapa jenis masalah yang TIGA kontributor bersedia diskusikan dan selidiki jika mereka saat ini merasa kewalahan dengan total volume.

Ide pasangan:

• Pada saat penulisan suggestions dan enhancements memiliki (271) masalah terbuka. Label ini tampaknya menghasilkan banyak kebisingan. Mungkin hanya mengambil PR siap / cek lulus sebagai saran yang sebenarnya. Insta-close semuanya dan tandai sebagai Discussion (please use the forum) .

• Pada saat penulisan loaders memiliki (61) masalah terbuka. Label ini juga tampaknya menghasilkan banyak noise. Saya melihat banyak masalah dengan label ini terkait dengan suggestions dan enhancements atau laporan bug yang dibuat dengan buruk. Mungkin hanya mengambil laporan bug yang terbentuk dengan baik dan PR siap / pemeriksaan lulus untuk saran. Insta-close semua yang lain dan tandai dengan sesuai.

Saya tidak berpikir adil untuk mengatakan bahwa apa pun di ekosistem three.js sangat bergantung pada ruang nama THREE.* global sehingga tidak dapat diperbarui untuk menggunakan sintaks impor/ekspor, atau untuk transpile ke ES5, atau untuk menggunakan pembuat bundel

Saya setuju apa pun dapat diperbarui tetapi jika kami dapat menemukan cara untuk melakukan sedikit pekerjaan untuk terus mendukung pengguna ini secara berkelanjutan, saya setuju dengan @Bug-Reaper dalam mengatakan:

Saya lebih suka kita semua tidak membuat alur kerja transpilasi/bundel sendiri secara terpisah ketika sesuatu dapat disimpan di repo utama untuk memungkinkan kita berkolaborasi dengan lebih baik.

Kami secara kolektif akan menghemat banyak waktu para pengguna ini dari memutakhirkan aplikasi/pustaka mereka, membangun sistem, dan dokumentasi.

Saya ingin menggali lebih dalam tentang ini. Saya telah menulis banyak perkakas khusus dan membuat skrip otomatisasi untuk aplikasi ujung depan dan dengan senang hati akan membantu dengan cara apa pun yang saya bisa.

bagus.

Bagaimana cara mengurangi volume masalah secara keseluruhan?

Tolong biarkan ini tetap pada jalurnya. Selamat berdiskusi lebih lanjut di thread lain. Ini agak berhubungan dengan komentar saya sebelumnya.

Saya setuju dengan @Bug-Reaper dalam mengatakan:

Saya lebih suka kita semua tidak membuat alur kerja transpilasi/bundel [...]

Saya pikir kita semua sepakat tentang ini.

Terima kasih semuanya telah berbagi pro dan kontra. Selalu baik untuk membagikan ini untuk memastikan kami mengambil keputusan yang tepat.

Ini adalah sesuatu yang saya telah menghabiskan beberapa siklus otak tahun ini, dan saya bahkan bertanya kepada vendor browser tentang prioritas mereka sehingga saya dapat merencanakan ke depan.

Saya setuju bahwa Modul ES6 adalah masa depan tetapi mengembangkannya tanpa peta impor dapat menyebabkan sakit kepala yang sangat besar dan benar-benar menghentikan aliran Anda. Ketika kami memutuskan untuk menghentikan examples/js Saya berharap peta Impor akan memiliki daya tarik lebih, tetapi sepertinya saat ini bukan prioritas untuk browser.

Karena itu, saya memutuskan untuk menangguhkan penghentian penggunaan folder examples/js hingga browser menerapkan peta impor. Saya tidak suka memaksa pemula untuk belajar tentang polyfill atau bundler untuk membuat kubus pertama mereka.

Saya mencapai kesimpulan yang sama dengan @Bug-Reaper. Hari ini saya sedang melihat pembuatan skrip yang membangun examples/js dari file examples/jsm .

@mrdoob

Saya memutuskan untuk menangguhkan penghentian folder contoh/js sampai browser menerapkan peta impor.
Saya mencapai kesimpulan yang sama dengan @Bug-Reaper. Hari ini saya sedang melihat pembuatan skrip yang membuat contoh/js dari contoh/file jsm.

Sebuah keputusan yang bijaksana.
👍

@mrdoob Saya tentu saja menerima keputusan Anda, tetapi saya pikir ini adalah kesempatan yang terlewatkan. Cepat atau lambat para pengembang harus menjauh dari skrip global. Dan saya tidak berpikir Import Maps akan membuat banyak perbedaan di sini. Alih-alih "memaksa" pengguna ke alur kerja yang lebih baik dan tahan masa depan, kami mengizinkan mereka untuk terus menggunakan skrip global. Pada tahun 2020.

Dan saya tidak berpikir Import Maps akan membuat banyak perbedaan di sini.

Suatu hari saya melihat seseorang melakukan ini:

<script src="js/three.js"></script>
<script src="https://cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/GLTFLoader.js"></script>
<script type="module" src="js/main.js"></script>

Dan, di dalam main.js mereka melakukan ini:

import {OrbitControls} from "https://threejsfundamentals.org/threejs/resources/threejs/r119/examples/jsm/controls/OrbitControls.js";

Dan hal itu benar-benar berhasil...

Kami tidak bisa hanya mengharapkan pengguna melakukan hal yang benar, mereka belajar dan mencoba sesuatu sampai sesuatu berhasil. Tantangannya adalah menemukan desain yang membantu mereka melakukan hal yang benar tanpa mereka sadari.

Masalah dengan Modul ES6 tanpa peta impor adalah bahwa pengguna tidak bisa hanya menyalin OrbitControls.js ke folder /js dalam proyek mereka sendiri dan mengimpornya seperti dulu. Itu tidak akan berfungsi karena OrbitControls.js mencari ../../build/three.module.js .

Dengan peta impor, OrbitControls.js hanya akan mengimpor dari three . Pengguna dapat menyalin file di mana pun mereka inginkan dan kemudian menyesuaikan jalur di peta impor.

Impor peta membawa kita lebih dekat dengan kemudahan mengimpor file seperti di masa "lama". Ini tidak akan semudah sebelumnya, tetapi setidaknya pengguna tidak perlu khawatir tentang urutan saat mengimpor file. Memenangkan sesuatu kehilangan sesuatu.

Setuju bahwa peta impor akan membuat impor dapat dikonfigurasi dan dengan demikian lebih fleksibel. Meskipun pengguna masih harus menyesuaikan peta impor (dan dengan demikian memahami apa itu sebenarnya).

Saya hanya berpikir bahwa seluruh "salin file JS ke dalam folder" adalah anti-pola yang jahat dan saya berharap kami dapat mencegahnya dengan merekomendasikan pengguna baru/pemula untuk bekerja dengan impor CDN (yang juga merupakan opsi untuk pengembang yang tidak' tidak ingin menggunakan build untuk alasan apa pun). Aplikasi yang tepat (seharusnya) tetap menggunakan alat build.

Saya tidak benar-benar melihat sebagai anti-pola.

Begitulah cara saya belajar membuat situs web. Seseorang akan menempatkan file .css di folder /css , kemudian gambar di /img dan file .js di /js .

Selama beberapa bulan terakhir saya telah melakukan beberapa eksperimen menggunakan pendekatan Modul ES6/CDN dan saya merasa tidak enak bahwa perpustakaan berasal dari domain yang berbeda dari tempat proyek saya berada.

Satu hal besar yang kita hilangkan ketika tidak menyalin file adalah dapat mengeditnya. File di examples/js seharusnya selalu menjadi contoh yang dapat Anda bangun. Jika saya menyalin OrbitControls.js di proyek saya dan itu tidak melakukan apa yang saya butuhkan, saya hanya dapat memodifikasinya karena itu hanya file lokal.

Beginilah cara saya mengatur proyek saya:

<script src="js/libs/three.js"></script>
<script src="js/libs/three/OBJLoader.js"></script>
<script src="js/libs/three/OrbitControls.js"></script>
<script>
    console.log( THREE, THREE.OBJLoader, THREE.OrbitControls );
</script>

Dengan peta impor akan terlihat seperti ini:

<script type="importmap">
{
  "imports": {
    "three": "js/libs/three.module.js",
    "OBJLoader": "js/libs/three/OBJLoader.js",
    "OrbitControls": "js/libs/three/OrbitControls.js"
  }
}
</script>
<script type="module">
    import * as THREE from 'three';
    import { OBJLoader } from 'OBJLoader';
    import { OrbitControls } from 'OrbitControls';

    console.log( THREE, OBJLoader, OrbitControls );
</script>

Tidak secantik sebelumnya, tetapi menangani dependensi/pesanan impor untuk Anda dan tidak memerlukan bundler.

Namun itu masih berfungsi untuk orang-orang yang melakukan pengembangan berbasis bundel. Faktanya, ini membuatnya lebih baik bagi mereka karena add-on sekarang mengimpor dari three daripada ../../build/three.module.js .

Dan hal itu benar-benar berhasil...

FWIW ini sepertinya hanya berfungsi dalam sejumlah kecil kasus. Ketika tidak berfungsi, itu gagal dengan cara yang sangat membingungkan dan kami memiliki beberapa masalah yang diajukan terkait dengan hal itu yang terjadi dengan proses pembuatan juga. Diperdebatkan jika Anda khawatir tentang pemula yang memberi mereka banyak cara untuk menggunakan file yang sama lebih rawan kesalahan dan membingungkan.

Mungkin tangensial tetapi mungkin ada baiknya memberi tahu orang-orang bahwa mereka memiliki dua salinan three.js yang disertakan di halaman melalui peringatan di konsol (bahkan jika itu versi yang sama) yang dapat menyebabkan masalah kecuali jika dilakukan dengan hati-hati untuk tidak mencampurnya. ~Saya percaya React melakukan ini untuk alasan yang sama~ React mungkin sebenarnya hanya menunjukkan ini sebagai kemungkinan sumber kesalahan. Itu setidaknya bisa membantu menjauhkan orang dari pencampuran modalitas ini saat belajar.

Saya mencapai kesimpulan yang sama dengan @Bug-Reaper. Hari ini saya sedang melihat pembuatan skrip yang membuat contoh/js dari contoh/file jsm.

Jika ini adalah paket baru, saya akan dengan senang hati membantu menghidupkan kembali #15526 / #15543 (yang sekarang telah dihapus dari proyek) yang membuat setiap file modul menjadi file ES6. Mengingat bahwa beberapa contoh tersebar di antara begitu banyak file (Shader Nodes, misalnya) dan kami mungkin tertarik untuk membagi beberapa modul menjadi beberapa file, mungkin ada baiknya memutakhirkan skrip rollup untuk mengambil daftar file eksplisit yang ingin kami konversi dan keluaran. Kita harus dapat secara otomatis membuat dependensi antara file-file yang menjadi output, juga.

Satu hal besar yang kita hilangkan ketika tidak menyalin file adalah dapat mengeditnya

Saya setuju meskipun jika kita bisa mendapatkan kelas di mana-mana, saya berharap sesuatu seperti:

import orbitalcontrols from  orbitalcontrolsURL

class mycontrols extends orbitalcontrols {
// do the edits I care about
}

dan kemudian

let controls = new myorbitalcontrols

Satu hal besar yang kita hilangkan ketika tidak menyalin file adalah dapat mengeditnya

Saya setuju meskipun jika kita bisa mendapatkan kelas di mana-mana, saya berharap sesuatu seperti:

impor orbitalcontrols dari orbitalcontrolsURL

class mycontrols memperluas orbitalcontrols {
// lakukan pengeditan yang saya pedulikan
}

dan kemudian

biarkan kontrol = kontrol orbit baru

Anda sudah bisa melakukannya ... bahkan jika "kelas" induknya adalah fungsi js sederhana!

Kode benar-benar berfungsi (dalam tes cepat debugger):

Promise.all([
    import('https://unpkg.com/three/build/three.module.js')
        .then( mod=> [mod.Camera, mod.WebGLRenderer] ),
    import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')
        .then( mod=> mod.OrbitControls )
])
.then( ([
    [ Camera, WebGLRenderer ],
    OrbitControls
])=> new ( class extends OrbitControls {} )( new Camera, (new WebGLRenderer).domElement )
)
.then( console.log )

... atau sintaks yang lebih sederhana:

(async function() {

let { Camera, WebGLRenderer } = await import('https://unpkg.com/three/build/three.module.js')
,   { OrbitControls } = await import('https://unpkg.com/three/examples/jsm/controls/OrbitControls.js')

class Con extends OrbitControls { }

let my = new Con( new Camera, (new WebGLRenderer).domElement )
console.log( my )

})()

selain fungsi aynom itu dan khawatir tentang async/menunggu janji, keren

class mycontrols extend orbitalcontrols {
 // do the edits I care about
 }

Idealnya, ini adalah pola yang harus kita promosikan, daripada menyuruh pengguna mengedit file asli saat membuat perubahan. Namun, contoh-contoh tersebut tidak ditulis dengan mempertimbangkan perluasan sehingga ada batasan kuat pada apa yang dapat Anda capai. Dalam pengalaman saya, Anda akhirnya harus menyalin seluruh contoh asli ke konstruktor kelas yang diperluas agar berfungsi sehingga tidak ada gunanya menggunakan extend .

Misalnya, perubahan yang paling umum diminta untuk OrbitControls adalah membatasi pan . Ini mudah dicapai seperti yang ditunjukkan dalam biola @Mugen87 dari utas itu.

Singkatnya, Anda menambahkan vektor minPan dan maxPan dan menjepit controls.target dalam metode controls.update .

Saya telah mencoba melakukan ini dengan memperluas OrbitControls . Anda dapat membuat kelas yang diperluas, dan itu berfungsi dengan baik. Namun, masalah menjadi jelas ketika Anda mulai melakukan perubahan. Anda tidak bisa begitu saja memperluas metode update :

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);
    }

    update() {
        super.update();
        console.log('Custom update function');
    }
}

Kelas yang diperluas ini berfungsi ( glitch ), tetapi metode OrbitControlsPanLimit.update baru ini diabaikan. Metode OrbitControls.update asli masih digunakan.

Anda dapat menimpanya dengan mendefinisikan ulang di konstruktor:

class OrbitControlsPanLimit extends OrbitControls {
    constructor(object, domElement) {
        super(object, domElement);

        this.update = () => {
            console.log('Custom update function');
        }
    }
}

Anda tidak dapat menggunakan super.update() di sini jadi satu-satunya pilihan adalah menyalin seluruh metode pembaruan asli. Namun, metode itu bergantung pada banyak hal ini dari dalam OrbitControls , yang dibagi di antara semua metode.

    //
    // internals
    //

    var scope = this;

    var changeEvent = { type: 'change' };
    var startEvent = { type: 'start' };
    var endEvent = { type: 'end' };

    var STATE = {
        NONE: - 1,
        ROTATE: 0,
        DOLLY: 1,
        PAN: 2,
        TOUCH_ROTATE: 3,
        TOUCH_PAN: 4,
        TOUCH_DOLLY_PAN: 5,
        TOUCH_DOLLY_ROTATE: 6
    };

    var state = STATE.NONE;

    var EPS = 0.000001;

    // current position in spherical coordinates
    var spherical = new THREE.Spherical();
    var sphericalDelta = new THREE.Spherical();

    var scale = 1;
    var panOffset = new THREE.Vector3();
    var zoomChanged = false;

    var rotateStart = new THREE.Vector2();
    var rotateEnd = new THREE.Vector2();
    var rotateDelta = new THREE.Vector2();

    var panStart = new THREE.Vector2();
    var panEnd = new THREE.Vector2();
    var panDelta = new THREE.Vector2();

    var dollyStart = new THREE.Vector2();
    var dollyEnd = new THREE.Vector2();
    var dollyDelta = new THREE.Vector2();

Hasil akhirnya adalah Anda harus menyalin hampir seluruh OrbitControls asli ke dalam konstruktor OrbitControlsPanLimit yang mengalahkan tujuan perluasan kelas. Kecuali kita menulis kontrol sebagai kelas dengan ekstensibilitas dalam pikiran, saya tidak berpikir memperluas itu layak.

terima kasih @looeee untuk dentingan di sana. Saya berpikir mungkin saya melewatkan solusi mudah dalam usaha saya sendiri, tetapi sekarang setelah Anda menyebutkannya, di situlah saya bangkit.

Idealnya, ini adalah pola yang harus kita promosikan, daripada menyuruh pengguna mengedit file asli saat membuat perubahan.

Hati-hati, itu mendekati argumen pewarisan vs komposisi.

Idealnya perpustakaan tidak boleh mempromosikan pola apa pun. Itu harus mempromosikan fitur-fiturnya dan bagaimana itu bertujuan untuk memecahkan masalah Anda.

Itu juga tidak boleh mengasumsikan alur kerja pengembang, menumpuk, membangun sistem, menggunakan kasus. Perpustakaan yang hebat dapat mengakomodasi kebutuhan masyarakat yang kompleks sebanyak mungkin.

Apa yang baru hari ini adalah hari esok yang lama, pola datang dan pergi. Satu-satunya yang konstan kemudian adalah perangkat lunak yang menawarkan dukungan hebat untuk banyak kasus penggunaan di sepanjang jalan untuk mempertahankan kompatibilitas mundur sebanyak mungkin.

Anda masih dapat menjalankan game DOS di Windows 10.

pewarisan vs argumen komposisi

kumohon tidak. solusi untuk 'argumen' ini adalah menggunakan alat terbaik untuk pekerjaan itu. ada tempat untuk pewarisan, komposisi, fungsional, test-driven... sebut saja.

Karena kita berbicara tentang bagaimana pengembang lain (menggunakan, menggunakan kembali, memodifikasi) three.js, adalah sah untuk mempromosikan pola yang akan mudah dipahami dan dapat digunakan tanpa melangkah keluar dari fitur browser js.

mempromosikan tidak berarti bahwa seseorang tidak dapat menggunakan gaya yang berbeda.

kompatibilitas mundur sebanyak mungkin

iya dan tidak.

Itu harus mempromosikan fitur-fiturnya dan bagaimana itu bertujuan untuk memecahkan masalah Anda

mungkin agar kami jelas, apa masalah/fitur yang ditetapkan untuk Anda?

Itu juga tidak boleh mengasumsikan alur kerja pengembang, menumpuk, membangun sistem, menggunakan kasus

Saya sebagian besar setuju. kasus penggunaan threejs saat ini adalah browser. peringatan ada beberapa loader kami berguna untuk beberapa aplikasi node dari apa yang saya dengar.

Satu-satunya yang konstan kemudian adalah perangkat lunak yang menawarkan dukungan hebat untuk banyak kasus penggunaan di sepanjang jalan

Perubahan adalah satu-satunya yang konstan. pengembang menggunakan alat yang mereka sukai dan terkadang kami mencoba hal lain.

sebagai samping:

Itu harus mempromosikan fitur-fiturnya dan bagaimana itu bertujuan untuk memecahkan masalah Anda

yang datang lebih dulu? fitur, pola atau masalah?
pasti polanya membantu menyelesaikan masalah dan kemudian menjadi fitur
...ataukah fitur yang menciptakan masalah dan kami menemukan pola untuk menyelesaikannya?

yang datang lebih dulu? fitur, pola atau masalah?

Yang datang lebih dulu? Ayam atau Telur?
Ada yang bilang Ayam...

Diskusi hebat di sekitar, terima kasih semuanya atas semua masukannya.

Saya ingin tahu apa pendapat kalian tentang bundler mana ( rollup, babel, parcel, webpack, dll ) yang paling cocok untuk tugas mentranspilasikan modul contoh ES6 kami. Saya percaya @gigablox disebutkan memiliki pengalaman di sini dan saya yakin orang lain juga melakukannya.

Repo saat ini sudah berisi babel, rollup, dan beberapa plugin terkait. Saya melanjutkan dan mulai meretas malam ini dan saya memiliki skrip konfigurasi rollup yang sangat kasar untuk dibagikan:

// jsm-transpiler.js
export default [
  {
    input: './examples/jsm/controls/OrbitControls.js',
    output: {
      banner:"//warning this file was generated automatically",
      file: './examples/js/controls/OrbitControls.js',
      name:'OC',
      footer:'THREE["OrbitControls"]=OC.OrbitControls',
      format: 'umd'
    }
  }
];

Skrip konfigurasi rollup ini memang mengubah modul $# OrbitControls .js menjadi file .js non-modul yang memberikan THREE.OribitControls konstruktor yang sesuai. Berhasil, yang keren :) ! Itu juga menggabungkan 40k baris THREE.js ke dalam file output, tidak terlalu keren haha. Saya juga malas mencemari ruang variabel global dengan mendeklarasikan var global perantara yang disebut OC untuk membantu mengangkut konstruktor OrbitControls ke TIGA.

Rollup tampaknya memiliki beberapa fitur yang sangat keren yang menurut saya dapat mengatasi banyak masalah kita. Terutama pemetaan dan kontrol lain untuk memastikan modul bersarang yang benar disertakan/dikecualikan. Kemampuan untuk memasukkan kode sebelum dan sesudah muatan yang ditranspilasikan melalui properti header/footer/intro/output.

Saya sangat optimis kami dapat mencapai apa yang kami butuhkan dengan skrip konfigurasi rollup yang ditipu. Tetapi alangkah baiknya jika seseorang yang meneliti/memahami perbedaan antara banyak bundler dapat menimbang di sini. Kami akan membutuhkan sesuatu yang cukup kuat untuk menangani modul karena mereka menjadi lebih mengagumkan dan saya berani bertaruh beberapa kode transpile lebih baik daripada yang lain.

Inilah pendapat saya tentangnya:
https://github.com/mrdoob/three.js/pull/20529

Ini adalah skrip pembuatan kustom poc yang mengubah semua modul JSM menjadi modul namespace global JS dalam waktu sekitar 30 detik. Sudah cukup sukses dengan metode ini. Perlu lebih banyak pengujian tetapi mencoba beberapa modul yang lebih kompleks seperti GLTFLoader di dunia halo dan itu baik-baik saja.

Dapat menggunakan bantuan dari penyihir RegExp berpengalaman :) untuk menyelesaikan beberapa kasus tepi yang dapat Anda baca lebih lanjut di PR.

Maksud Impor Peta Chrome untuk Dikirim:
https://groups.google.com/a/chromium.org/g/blink-dev/c/rVX_dJAJ-eI