Rollup-plugin-typescript2: Opsi tsconfig default "include" diganti dengan indeks dari tsconfig.json asli

ini membuat penggunaan include tidak mungkin karena Anda tidak pernah tahu berapa lama array akan berada di tsconfig.json

Hal yang menarik,
jika saya memindahkan opsi typescript2 config include dari tsconfigDefaults ke tsconfigOverride
itu akan menimpa opsi tsconfig.json include menurut indeks.

Artinya, justru sebaliknya
tapi itu juga sangat buruk

dan satu hal lagi
setelah beberapa investigasi tambahan
Saya menyadari bahwa perilaku yang sama juga relevan untuk properti array lainnya

Jadi saya pernah mengalami masalah ini sebelumnya di https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 , dan untuk masalah itu, begitulah cara kerja deep merge _.merge . Ini adalah penggabungan yang dalam sehingga menggabungkan larik dan indeks adalah satu-satunya pengenal larik. Ini mungkin _tidak terduga_ tetapi ini adalah penggabungan yang dalam, begitulah cara kerja penggabungan yang dalam.

Faktanya, ini tidak menggabungkan properti ini, tetapi menggantikan nilai dalam sel indeks ,

• Sebaliknya, melakukan append / concat tidak akan digabungkan sama sekali, dan tidak akan memberikan cara untuk menimpa dengan tsconfig sama sekali. Itu sepertinya perilaku yang salah bagi saya.
• Alih-alih melakukan penggabungan dangkal hanya akan menimpa apa yang ada di default, yang saya juga tidak yakin perilaku yang diharapkan, tetapi ini mirip dengan cara kerja tsconfig berkenaan dengan exclude : jika Anda menambahkan exclude , itu menimpa default.

Saya bisa menulis PR untuk melakukan penggabungan dangkal hanya dengan include dan exclude , tapi itu akan menjadi _pretty_ melanggar perubahan; Saya tidak tahu bagaimana hal itu dapat memengaruhi semua pengguna hilir. Idk jika pengguna TSDX mengharapkan penggabungan yang dangkal atau dalam, tetapi itu akan merusak penggunaannya jika mengharapkan penggabungan yang dalam.

jika saya memindahkan opsi typescript2 config include dari tsconfigDefaults menjadi tsconfigOverride
itu akan menimpa opsi tsconfig.json include menurut indeks.

Artinya, justru sebaliknya

Ya, begitulah seharusnya tsconfigOverride bekerja, ini adalah sebuah override.

Saya menyadari bahwa perilaku yang sama juga relevan untuk properti array lainnya

Ya, begitulah cara _.merge melakukan penggabungan mendalam, jadi apa pun di tsconfig yang merupakan array memiliki perubahan yang sama.

@ agilgur5 terima kasih atas tanggapannya!

1) Dari sudut pandang saya, perilaku ini membuat konfigurasi sama sekali tidak berguna. Kami tidak dapat menjamin keandalan konfigurasi jika kami terikat pada posisi dalam larik.

2) Memang, itu akan menjadi perubahan besar. Tetapi jika arah kita adalah untuk mencapai DX terbaik, maka kita harus membuat hal ini jelas dan berguna.

Saya memiliki trik di saku saya untuk menangani hal ini, tetapi terlihat berisik dari perspektif kode yang bersih - cukup baca tsconfig , dapatkan properti include dan gabungkan ini dengan array saya. Sepertinya itu lebih mudah.

Saran saya:
1) untuk default - kumpulkan properti default dan gabungkan dengan tsconfig asli; hapus duplikat.
2) untuk override - terapkan hanya opsi override

Default biasanya tidak digabungkan saat diganti, mereka diganti. Dan seperti yang saya sebutkan di atas, penggabungan membuatnya _impossible_ untuk menimpa default dengan tsconfig . Kedengarannya seperti perilaku yang salah bagi saya dalam banyak hal, jadi saya sangat tidak menyarankannya.

Saya pikir semua opsi membingungkan, saya tidak yakin saya setuju bahwa salah satu dari ini adalah "DX terbaik". Penggabungan dangkal adalah hal yang paling mendekati cara kerja tsconfig dengan default exclude , tetapi itu tidak datang tanpa trade-off.
Secara umum, pemutusan perubahan perlu banyak pemikiran yang dimasukkan ke dalamnya, itulah sebabnya saya mengungkitnya - efek hilirnya tidak sepele; TSDX juga harus merilis perubahan yang melanggar untuk memperbarui perubahan tersebut.

@ agilgur5 baik-baik saja, maka saya tidak dapat menggunakan default atau menimpa sama sekali.
Sebab? Tidak ada jaminan bahwa tidak ada nilai yang akan ditulis pada indeks tersebut.
Plus, Anda dapat menyiasati semuanya melalui undefined sebagai nilai array, dan menambahkan nilai yang Anda butuhkan lebih jauh. Dan ternyata ada celah dalam sistem ini? Bagus sekali.

Kasus:

1. Saya ingin menambahkan tambahan d.ts saya di dalam properti config "include".
2. Pengguna meletakkan src dirnya di dalam "include" dengan proyek lain khusus d.ts mengetik di luar src .

1. ['config.d.ts`]
   2. ['src', 'some.d.ts', 'another.d.ts']
2. Hasil: ['src', 'some.d.ts', 'another.d.ts']

Seperti yang Anda lihat, tidak ada cara untuk mengkonfigurasi ini dengan benar. Saya harus membaca tsconfig.json, mendapatkan properti "include" -nya dan menggabungkannya menjadi ['src', 'some.d.ts', 'another.d.ts', 'config.d.ts'].
Dan saya pikir ini adalah overhead yang lengkap.

Sementara itu, saya menemukan apa masalahnya. Orang lain mungkin tidak mengetahuinya dan menghabiskan waktu berharga mereka untuk mencari tahu apa yang tidak berhasil untuk mereka.
Dan setelah pesan pertama Anda, saya telah melihat setidaknya 2 masalah terkait. Dan itu akan terus berlanjut.

Saya melihatnya sehingga jika kita membiarkan semuanya apa adanya, maka saya tidak dapat menggunakannya, itu adalah kotak hitam bagi saya karena saya tidak dapat menjamin apa pun.
Tidak ada ruang untuk preferensi pribadi "suka" / "tidak suka".
Ini bisa digunakan atau tidak. Dan itu tidak bisa.

Saya tidak masalah mengumpulkan pendapat orang lain yang terlibat dalam hal ini.
Dan satu hal lagi, saya tidak memiliki masalah untuk tetap menggunakan solusi saat ini, saya memiliki peretasan yang dijelaskan di atas, yang siap saya gunakan. Tetapi saya tidak mengerti apa masalahnya membuat solusi ini transparan, tanpa terikat pada fakta bahwa itu akan memerlukan perubahan yang merusak.

Maksud saya, Anda memberikan preferensi Anda sendiri di sini sementara saya sudah memberikan beberapa opsi berbeda. Saya sudah mengatakan dua kali mengapa preferensi itu, penggabungan, pada dasarnya rusak, sama tidak intuitifnya, dan sama sekali tidak "transparan". Untuk mengulang, penggabungan bukanlah _just_ perubahan yang merusak, itu benar-benar membuat hal-hal utama menjadi tidak mungkin . Saya ulangi lagi, tidak mungkin .
Tidak mungkin menimpa dengan penggabungan bukanlah "preferensi", itu fakta.

Sekali lagi, "default" yang tidak dapat diganti bukanlah default, itu adalah persyaratan. Mengubah "default" menjadi persyaratan tidak masuk akal dan merupakan perilaku yang salah.

Anda dapat mengganti penggabungan dalam sekarang, Anda tidak dapat mengganti penggabungan. Membuat kasus penggunaan yang ada menjadi tidak mungkin tidak masuk akal.

Saya juga sudah memberikan opsi alternatif dua kali yang tidak rusak secara fundamental, yang merupakan penggabungan dangkal. Saya akan ulangi lagi, Anda dapat menggunakan gabungan dangkal untuk menyelesaikan ini juga.
Apakah itu lebih baik masih bisa diperdebatkan. Ada trade-off untuk segalanya.

Saya telah berkontribusi di sini untuk memperbaiki bug sebelumnya (saya tahu itu _.merge karena saya telah membaca basis kode) dan perpustakaan yang saya pelihara membuat porsi yang signifikan dari penggunaan perpustakaan ini (~ 10%), saya tidak hanya membuat poin pembicaraan di sini ...

Belum lagi, ini dapat diselesaikan tanpa merusak perubahan - Anda dapat menambahkan opsi baru untuk tsconfigConcat atau tsconfigDefaultShallow dll.

Mengatakan bahwa hanya ada satu opsi dan itu harus melanggar dan harus membuat kasus penggunaan yang ada tidak mungkin adalah tidak benar.

Saya pikir kita harus menghancurkan sesuatu tidak peduli apa yang kita lakukan di sini. Untuk membuatnya berperilaku sesuai dengan semangat dokumentasi dan nama properti, pada dasarnya ia harus melakukan ini:

• tsconfigDefaults - ini adalah objek yang akan menggabungkan semua hal di bawah ini secara mendalam
• tsconfig - ini adalah objek yang kita dapatkan dari skrip ketikan, setelah impornya sendiri dan semuanya. Semua nilai di sini menggantikan nilai dalam tsconfigDefaults . Semua array di sini digabungkan dengan array di tsconfigDefaults .
• tsconfigOverride - ini adalah opsi nuklir. Objek masih digabungkan secara mendalam, tetapi array di sini menggantikan array grosir. Jadi jika Anda menyediakan array include kosong di sini, tsconfig akhir tidak akan memiliki include sama sekali.

Akankah itu mencakup semua kasus yang ingin kami dukung (setelah pengguna membuat perubahan yang sesuai), atau apakah saya melewatkan sesuatu?

@ezolenko terdengar luar biasa dan sangat masuk akal untuk digunakan

@ezolenko Saya tidak yakin mengapa Anda harus memecahkan sesuatu? Saya telah memberikan opsi yang sudah tidak terputus.

Saya tidak yakin bagaimana yang Anda cantumkan mencerminkan "semangat dokumentasi dan nama properti" karena dokumen mengatakan:

Objek yang dikirimkan sebagai tsconfigDefaults akan digabungkan dengan memuat tsconfig.json . Konfigurasi akhir yang diteruskan ke skrip ketikan akan menjadi hasil dari nilai dalam tsconfigDefaults diganti dengan nilai yang dimuat tsconfig.json
[...]
Ini adalah penggabungan dalam (objek digabungkan , array digabungkan, primitif diganti , dll), tingkatkan verbosity menjadi 3 dan cari parsed tsconfig jika Anda mendapatkan sesuatu yang tidak terduga.

Ia mengatakan "merged", "replace", dan "deep merge", yang semuanya berarti mengganti dan menimpa default. Ada satu referensi ke "gabungan" yang _berbeda dari yang lain_, tetapi penggabungan dalam _not_ sebenarnya digabungkan. 5 referensi mengatakan satu hal dan 6 tidak benar. Bagi saya, sepertinya referensi ke-6 yang salah harus diperbaiki, bukan 5 yang benar diubah menjadi referensi ke-6 yang salah.

lodash adalah standar de facto dan definisi penggabungannya adalah _not_ untuk digabungkan. Definisi default adalah bahwa mereka diganti ketika Anda menyetel nilai properti yang sama, _not_ concatenated:

_.defaults({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a']}
_.defaultsDeep({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a', 'c']}

Jika Anda ingin menambahkan opsi penggabungan, saya pikir itu harus menjadi konfigurasi terpisah, karena itu juga tidak cocok dengan 5+ referensi di dokumen dan karena itu bukan arti default, baik dalam definisi maupun dalam penggunaan di mana pun. Perpustakaan.

Ini juga merusak simetri dengan tsconfigOverride serta dokumennya sendiri:

• tsconfigOverride : {}
  Lihat tsconfigDefaults .

Saya berharap default diganti, itulah definisinya, membuat mereka bersambung malah sangat tidak intuitif. Penggabungan mendalam mungkin tidak intuitif untuk array, tetapi dokumen dengan jelas mengatakan itu adalah penggabungan yang dalam dan cepat bagi saya untuk memahami bahwa itulah masalahnya karena indeks relevan. Saya juga tidak melaporkan bug karena itulah yang dikatakan oleh dokumen dan bahkan menautkan ke penggabungan dalam - itu adalah perilaku yang dimaksudkan, bukan bug.

Seperti yang telah saya katakan, penggabungan array yang dangkal mungkin lebih intuitif, karena begitulah cara kerja tsconfig _itself_ sebenarnya. Seperti yang telah saya tautkan di atas, tsconfig _itself_ tidak digabungkan saat Anda menambahkan exclude , ini menimpa exclude .

Jadi penggabungan tidak cocok dengan 5+ referensi di dokumen, definisi penggabungan, definisi default, atau perilaku tsconfig sendiri. Dan itu merusak simetri dan dokumen opsi lain. Saya tidak yakin bagaimana itu intuitif.

Dan seperti yang telah saya katakan beberapa kali, menjadikannya rangkaian yang sangat tidak intuitif alih-alih menimpa membuat use case

https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

Maksudnya adalah jika Anda menambahkan exclude , itu menimpa default yang telah kita tetapkan. Default hanya diterapkan jika Anda belum menyetel nama properti, sama seperti setiap nama properti lainnya (sekali lagi, itu adalah definisi default dan cara kerja default di semua pustaka).

Jika Anda mengubahnya menjadi gabungan, maka pengguna sekarang tidak memiliki cara untuk menimpa default kami exclude , adalah _impossible_ bagi mereka untuk menimpa default. Kami juga mengirimkan tsconfig default exclude , jadi ini juga membuatnya _impossible_ untuk menimpa tsconfig , meskipun tsconfig _itself_ memungkinkan Anda melakukannya bahwa.

Tidak yakin mengapa saya berbicara seperti rekaman rusak di sini mengulangi _definisi yang sudah ada_ dan _penggunaan yang sudah ada_ di _ seluruh ekosistem _.

@ agilur5

Dan seperti yang telah saya katakan berkali-kali, membuatnya menjadi rangkaian yang sangat tidak intuitif, bukannya menimpa
membuat kasus penggunaan tertentu menjadi tidak mungkin. Berikut adalah penggunaan TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

Konfigurasi ini dapat dengan mudah terganggu, dan saya tidak mengerti mengapa hal ini tidak jelas bagi Anda. Saya tidak ingin perpustakaan saya menjadi rapuh, dan itulah mengapa saya membuat masalah ini.

lucunya adalah bahwa @ezolenko dan saya telah mengusulkan solusi yang akan membantu melindungi, termasuk TSDX, tetapi Anda tetap menolak.

Default hanya diterapkan jika Anda belum menyetel nama properti

Saya setuju dengan perilaku default . Masuk akal untuk menerapkan config default hanya jika tsconfig tidak memiliki properti yang sesuai, tetapi hal ini menimbulkan banyak masalah lain yang lebih kompleks, yang solusinya akan membuat API menjadi lebih rumit.

tidak mungkin bagi mereka untuk menimpa default

Pertanyaannya adalah, mengapa pengguna harus memiliki akses ke apa yang dilarang oleh penulis perpustakaan?

Kita harus memiliki konfigurasi leverage tsconfig yang tidak dapat ditimpa, tetapi pada saat yang sama, kita perlu memberikan kesempatan untuk memperluas preset kita. Dan inilah poin utamanya.

Solusinya hanya terletak pada desain API baru.

Konfigurasi ini dapat dengan mudah terganggu, dan saya tidak mengerti mengapa hal ini tidak jelas bagi Anda. Saya tidak ingin perpustakaan saya menjadi rapuh, dan itulah mengapa saya membuat masalah ini.

Anda mengeluarkan kata-kata dari mulut saya yang tidak saya ucapkan dari jarak jauh. Saya tidak mengatakan itu tidak bisa dan saya juga tidak mengatakan itu tidak rapuh. Saya baru saja mengatakan bahwa solusi _your_ tidak cocok dengan _definisi yang ada_ atau _penggunaan yang sudah ada_ di _seluruh ekosistem_ default maupun dokumen itu sendiri. Melanggar seluruh definisi default jelas merupakan perilaku yang salah.
Seperti yang telah saya katakan beberapa kali, saran saya adalah menggabungkan array dangkal, yaitu tsconfig menimpa tsconfigDefaults seperti halnya untuk setiap properti non-array dan sebagai tsconfig _itself_ berfungsi .
Seperti yang telah saya katakan beberapa kali, hal itu dapat dilakukan dengan perubahan yang merusak atau yang tidak terputus.

Tolong jangan mengeluarkan kata-kata dari mulutku. Saya telah mengulanginya sendiri berkali-kali, tolong baca hal-hal yang sebenarnya saya tulis daripada mengarang.

Pertanyaannya adalah, mengapa pengguna harus memiliki akses ke apa yang dilarang oleh penulis perpustakaan?

tsconfig tidak melarangnya, TSDX tidak melarangnya, dan rollup-plugin-typescript2 juga tidak melarangnya, jadi saya tidak tahu apa yang Anda maksud.

Kita harus memiliki konfigurasi leverage tsconfig yang tidak dapat ditimpa, tetapi pada saat yang sama, kita perlu memberikan kesempatan untuk memperluas preset kita. Dan inilah poin utamanya.

Solusinya hanya terletak pada desain API baru.

Ya, Anda dapat menambahkan opsi tsconfigConcat untuk ini, dan itu akan menjadi "API baru". Memecah API saat ini dengan menemukan kembali seluruh definisi default akan menciptakan serangkaian masalah baru dan perilaku baru yang tidak intuitif. Kecuali meskipun penggabungan mendalam mungkin tidak intuitif untuk larik, ini masih merupakan perilaku _correct_. Penggabungan hanyalah perilaku yang salah, karena bukan itu yang dimaksud dengan default.

A tsconfigConcat akan menyelesaikan kasus penggunaan Anda dan lebih intuitif karena benar-benar memiliki kata yang sama dan itulah yang dilakukannya.
Mengubah tsconfigDefaults menjadi "penggabungan" bukan karena itu, untuk kelima kalinya, _bukan arti default_.

default = \ = penggabungan. Itu bukan pendapat saya, itu definisi.

@ agilgur5 maaf, tapi Anda tidak bisa dianggap serius.
setiap kalimat Anda kontroversial, saya bosan.

Saya hanya berpendapat bahwa API saat ini sama sekali tidak mengizinkan pekerjaan yang memadai dengannya, dan inilah alasan untuk mengubahnya.
Saya tidak akan melanjutkan ini lagi.

Yah saya tidak mengeluarkan kata-kata dari mulut orang, tidak membaca kata-kata mereka yang sebenarnya, mengarang-ngarang, menyerang karakter kontributor, memberikan 0 tautan, memberi 0 alternatif, dan hanya mempertimbangkan satu opsi dan tidak ada yang lain, itu Anda .

Jika Anda ingin menyerang kontributor yang hanya mencoba membantu dan memberikan definisi nyata, kasus penggunaan nyata, dan alternatif nyata, saya rasa itulah pendapat Anda: mengangkat bahu:

Saya pikir saya mendapat kesan bahwa gabungan lodash sebenarnya akan menggabungkan array (menyisipkan mereka atau sesuatu) ketika saya menulis bagian itu. Atau saya bahkan tidak memperhatikan apa yang terjadi pada array. Karena tampaknya menimpa konten array menggunakan indeks sebagai nama elemen (bukan? Apakah javascript tentang array ini awalnya bukan array yang sebenarnya, melainkan kamus yang kebetulan memiliki angka untuk kunci?), Dokumentasi kami saat ini ada.

Idealnya, opsi tsconfigs default / main / override harus memungkinkan penyesuaian semua parameter, baik nilai skalar dan array, dengan cara yang sama tidak mengejutkan. Cara Lodash untuk mengganti elemen array berdasarkan indeks memiliki satu kelemahan utama - Anda tidak dapat membuat array sparse literal (mungkin padding array dengan sekelompok undefined s?). Itu berarti konfigurasi rollup harus dibangun secara dinamis, dan tsconfig, sebagai file json, tidak dapat melakukannya sama sekali.

Bahkan dengan array sparse literal, mengganti elemen berdasarkan indeks terlalu rapuh.

Di sisi lain, penggabungan mengejutkan, jika tidak ada hal lain yang biasanya berperilaku seperti ini. Dan saja tidak memungkinkan penghapusan nilai sebelumnya.

Beralih antara penggabungan dan penggantian seperti yang saya usulkan pada awalnya sangat mengejutkan.

Mengubah kedua penggabungan untuk mengganti array grosir seperti yang diusulkan @ agilgur5 mungkin merupakan opsi yang paling tidak mengejutkan, ini akan memungkinkan penghapusan nilai, dengan mengorbankan harus mengulang nilai yang ingin disimpan. Ini masih merupakan perubahan besar dan orang-orang harus menulis ulang konfigurasi mereka untuk itu (lihat https://xkcd.com/1172/).

Kami dapat mengubah perilaku opsi tersebut atau membuat set baru dan menghentikan opsi yang ada dengan peringatan.

(maaf jika saya melewatkan poin penting di suatu tempat, saya hanya melewatkan seluruh utas)

@ezolenko Saya melihat cara selanjutnya

Mari kita lihat situasi dan motivasinya:
Pengembang ingin menambahkan beberapa konfigurasi yang diperlukan untuk skrip ketikan melalui plugin rollup.
Dalam kasus ini, kita tidak boleh mencegah pengembang menambahkan pengaturan dengan aman, dan tidak kehilangan pengaturan lain saat menggabungkan konfigurasi dan konfigurasi rollup.

Apa artinya ini memberitahu kita? Mari kita mulai dari semantik:

Seperti yang saya katakan sebelumnya

Saya setuju dengan perilaku default. Masuk akal untuk menerapkan config default hanya jika tsconfig tidak memiliki properti yang sesuai ...

Kami dapat mendesain ulang hal ini sepenuhnya.

Saran saya adalah:

1. Terapkan tsconfigDefaults properti jika tsconfig tidak memiliki properti terkait.
2. tsconfigOverride harus mengurus ini.
   2.1 Ini harus bekerja seperti sebelumnya dengan nilai skalar.
   2.2 Ini harus menggabungkan properti array. (mungkin ini tidak merusak apa pun dan harus memenuhi motivasi konfigurasi)

Saya hanya mencoba menghindari opsi rpt2 tambahan ketiga, karena ini akan memperumit API ini setidaknya 50% dan pengembang mana pun akan berhenti memahami ini.

@ agilgur5 Sungguh menakjubkan bahwa kenyataan dan kata-kata yang Anda ucapkan tidak sama.

Juga, berkat notifikasi email, saya membaca pesan aslinya, dan tidak diedit 8 kali, agar terlihat lebih baik di mata orang.
Tidak ada yang ingin menyerang Anda, apalagi, tidak ada yang melakukannya.
Anda hanya diminta untuk berhenti bersikap agresif dan berhenti menulis pidato yang kontradiktif di utas ini.

• 0 link - Saya menghabiskan banyak waktu untuk memahami masalah, menjelaskan sepenuhnya, memberikan contoh, dan bahkan screenshot. Dan juga, saya bahkan mempelajari TSDX Anda, dan memberi tahu Anda bahwa konfigurasi Anda rapuh, karena saya telah memeriksanya. Dan yang terpenting, saya tidak berdiam diri, tetapi membuat masalah ini untuk meningkatkan masalah bagi mereka yang dihadapkan dengan ini.
• 0 alternatif - harap baca dengan cermat. Saya mulai menawarkan solusi dari pesan pertama.
• mengeluarkan kata-kata - tenang dan berhenti bersikap narsis setidaknya di utas ini, tidak menyenangkan bagi saya untuk bekerja seperti ini.

@maktarsis bagaimana dalam pendekatan Anda dev dapat menghapus entri yang disertakan atau dikecualikan dari tsconfig? Skenarionya adalah: Anda memiliki tsconfig.json yang digunakan di tempat lain, Anda ingin menggunakannya dalam rollup tanpa menyentuh json itu sendiri, tetapi Anda ingin menghapus baris dari excludes array karena alasan tertentu.

@ezolenko saya mengerti Anda sekalipun.

Secara alami, seperti dibahas di atas, hal ini tidak akan mungkin terjadi.
Tapi kita berbicara tentang kemungkinan daripada motivasi.

Saya masih tidak melihat situasi ketika kami perlu menulis ulang pengecualian.
Namun demikian, saya berpendapat bahwa kita tidak perlu menimpa "exclude" dev. Dengan kata lain, saya tidak bisa membayangkan mengapa.
Penting untuk memahami alasan "untuk beberapa alasan".

Jika Anda ingin memiliki kemungkinan ini, Anda perlu menyediakan API tambahan untuk penggabungan.
Tetapi seperti yang mungkin Anda pahami, menurut saya itu mungkin tidak diklaim dan tidak perlu.
Pengecualian sesuatu dari "exclude" mungkin tidak diperlukan sama sekali, tetapi jika kita pergi ke arah lain, maka kita memperumit pemahaman konfigurasi.

Kita membutuhkan keduanya, menambahkan sesuatu ke array yang tidak ada dan menghapus sesuatu darinya. Dengan penggabungan dangkal, penambahan dan penghapusan dilakukan dengan mereplikasi seluruh larik (dengan perubahan) di tingkat yang lebih tinggi. Tidak terlalu nyaman, tapi bisa digunakan.

Ini juga terjadi dengan "esModuleInterop": true yang membuat perpustakaan saya tidak berfungsi di beberapa lingkungan.

Opsi compiler yang tidak berguna di config.json:

{
   ...
  "compilerOptions": {
       ...
      "esModuleInterop": true,
  },
}

Opsi kompiler yang berguna di rollup-config:

typescript({
    useTsconfigDeclarationDir: true,
    tsconfigOverride: {
      esModuleInterop: true,
    },
  }),

@maktarsis saran pertama buat saya perilaku yang diharapkan:

Terapkan properti tsconfigDefaults ketika tsconfig asli tidak memiliki properti yang sesuai.

^ komentar di atas tampaknya tidak berhubungan karena bukan untuk include atau array. "Saran" yang disebutkan adalah apa yang sudah dilakukan oleh tsconfigDefaults .
Juga saya, dan TSDX, menggunakan esModuleInterop berat jadi saya tahu bahwa ini berfungsi di tsconfig.json , tidak yakin apa maksud komentar itu. Konfigurasi yang diposting juga kehilangan compilerOptions , seharusnya:

js typescript({ useTsconfigDeclarationDir: true, tsconfigOverride: { compilerOptions: { esModuleInterop: true, }, }, }),

Tapi itu akan menimpa dan berfungsi sebagaimana mestinya.

Perhatikan di sini bahwa penggabungan dangkal telah disebutkan sebelumnya dalam repo ini beberapa kali: # 86 (yang menyebutkan perilaku penggabungan dangkal TS seperti yang saya lakukan di sini), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460, dan https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841