Menguji pembuatan perpustakaan komponen untuk Angular menggunakan perintah baru untuk Angular / Cli - library

Ketika proyek menjadi sedikit lebih dari satu, ada kebutuhan untuk entah bagaimana menggunakan kembali tidak hanya modul individual dengan kode, tetapi juga komponen UI itu sendiri. Ada banyak pilihan untuk menyelesaikan masalah - mulai dari copy-paste tradisional, hingga menyiapkan proyek terpisah dengan tes, dokumentasi dan bahkan blackjack.

Masalahnya adalah bahwa opsi kedua membutuhkan upaya persiapan yang signifikan dan masing-masing proyek tersebut unik - dengan alat sendiri di mana setiap pengembang baru perlu menghadapinya lagi. Pada akhir Juli, tim Angular mengusulkan sendiri, komprehensif, solusi untuk masalah ini dengan menambahkan ke angular / cli perintah baru untuk membuat perpustakaan - perpustakaan.

Mari kita lihat apa yang terjadi.

Untuk tes, versi stabil terbaru angular / cli diambil - 6.1.5 (09/04/2018)

Dunia yang sempurna

Di dunia yang ideal, semuanya harus nyaman. Jadi, untuk pustaka komponen, saya akan menyoroti tiga poin penting

• Keseragaman proyek dan mulai cepat
• Kenyamanan pengembangan
• Kemudahan distribusi

Jadi, mari kita mulai dari awal.

Untuk membuat perpustakaan kita sendiri, kita perlu mengambil dua langkah - membuat proyek baru dan menambahkan perpustakaan ke sana. Pertama, buat proyek baru:

npx @angular/cli@latest new mylibapp 

Setelah menjalankan perintah, kita akan melihat proyek standar (untuk 6 sudut, yang berbeda dari versi ke-5) di mana dua sub-proyek akan dibuat - mylibapp utama dan mylibapp-e2e. Proyek sudut itu sendiri sekarang dijelaskan dalam sudut.json.

Belum ada perpustakaan.

Dan di sini dia adalah peringatan pertama. Nama kami sudah diambil oleh proyek utama, dan menamai perpustakaan juga tidak akan berfungsi. Oleh karena itu, jika Anda ingin memberi nama perpustakaan my-super-library, Anda harus terlebih dahulu membuat proyek, yang seharusnya dipanggil dengan cara yang berbeda. Misalnya, proyek perpustakaan-saya-super. Dan hanya dengan begitu, buat perpustakaan dengan nama yang diinginkan.

Sekarang buat sub proyek ketiga dan hasilkan perpustakaan.

 cd mylibapp npx ng generate library mylib --prefix mlb 

Tidak perlu menentukan awalan, tetapi sangat diinginkan untuk tidak berpotongan dengan perpustakaan lain.

Seperti yang Anda lihat, sekarang, perpustakaan ketiga kami telah ditambahkan sebagai sub-proyek ketiga. Ia memiliki package.json, tsconfig dan karma.conf.js yang terpisah, yang memungkinkan Anda untuk mengonfigurasinya tanpa takut melukai proyek lain. Omong-omong, jika diinginkan, kita bisa menambahkan perpustakaan lain dan itu juga akan menjadi sub proyek yang terpisah. Tapi itu sebabnya perpustakaan tidak dapat dibedakan dengan proyek yang benar-benar terpisah (seperti misalnya. Net) Saya tidak tahu. Dan jika proyek e2e tidak sulit untuk dihapus dengan tangan, maka proyek utama sudah tidak ada lagi. Akibatnya, kode tambahan muncul di repositori, yang tidak terlalu bagus.

Sekarang mari kita lihat alat apa yang kita dapatkan segera. Ini adalah sekelompok tslint + codelyzer, karma + melati dan busur derajat untuk e2e. Yaitu set standar proyek sudut, tidak ada yang spesifik untuk perpustakaan kami tidak dibawa. Ini agak aneh, karena beberapa alat untuk melihat komponen dan merendernya ke dalam dokumentasi (seperti buku cerita ) memang harus dimiliki. Tapi baiklah, kita akan berasumsi bahwa di sini mereka hanya meninggalkan kita ruang untuk bermanuver.

Mari kita jalankan tes dan linter untuk memastikan semuanya bekerja.

 npm test mylib npx ng lint mylib 

Semuanya berjalan dengan baik untuk saya, tetapi Chrome digunakan untuk pengujian, yang juga aneh. Saya tidak membenci dia, tetapi pada server yang membangun itu tidak akan menjadi 90%. Mengapa mereka tidak menggunakan Dalang yang sama tidak jelas.

Untuk meringkas:

Pro

• Mulai cepat proyek baru
• Pendekatan seragam

Cons

• Kode ekstra dalam proyek
• Hal-hal yang jelas harus diselesaikan dengan tangan Anda.

Sejauh ini, tidak ada yang kritis, kami terus menggali lebih jauh.

Pengembangan

Kami sudah memiliki beberapa komponen di luar kotak, mari kita lihat mereka. Karena kami tidak memiliki alat khusus, kami akan menggunakan proyek utama (inilah mengapa diperlukan). Untuk melakukan ini, kita perlu membangun perpustakaan, mengimpor modul perpustakaan dan memulai proyek utama.

 npx ng build mylib 

 import { MylibModule } from "mylib"; ... @NgModule({ declarations: [ AppComponent, ], imports: [ BrowserModule, MylibModule ], providers: [], bootstrap: [AppComponent] }) 

 npm start 

Setelah semuanya selesai, kita akan melihat komponen kita dari perpustakaan. Tetapi sekali lagi ada nuansa - mode menonton untuk perpustakaan belum dilakukan, apakah Anda perlu menjalankan perpustakaan membangun sendiri setiap kali? Arloji hanya akan muncul di angular / cli 6.2+. Dan tidak di luar kotak, untuk ini Anda harus menambahkan bendera baru di tsconfig.json

tsconfig.json

 "angularCompilerOptions": { "enableResourceInlining": true, } 

Dan kemudian jalankan build dengan bendera arloji:

 ng build mylib --watch 

Jika karena alasan tertentu Anda menggunakan cli di bawah 6.2, Anda harus membuatnya sendiri, yang, sejujurnya, buruk.

Sekarang mari kita tambahkan komponen baru. Untuk melakukan ini, jalankan perintah menghasilkan komponen standar. Karena fakta bahwa perpustakaan bukan proyek utama kami, Anda harus menggunakan bendera proyek, yang juga sedikit mengganggu (tetapi jika perpustakaan itu solusi independen ...).

 npx ng generate component some-nice-image --project mylib 

Sekarang, di bawah mylib / src, buat folder aset, tambahkan gambar dan bangun kembali perpustakaan untuk melihat hasilnya. Dan kemudian kejutan lain menunggu kita - tidak ada gambar. Ternyata sumber daya yang digunakan di perpustakaan tidak secara otomatis masuk ke build, Anda perlu menyalinnya sendiri (atau seperti itu ). Dan sepertinya tidak menakutkan, tapi entah bagaimana masih tidak benar.

Tapi pohon-gemetar harus bekerja di luar kotak. Mari kita membuat komponen lain di perpustakaan tetapi kita tidak akan menggunakannya dalam proyek utama. Menyusun proyek utama dalam mode produksi

 npx build --prod 

Dan kita melihat bahwa ukuran bundel belum berubah. Mengguncang pohon benar-benar berfungsi dengan perpustakaan!

Sekarang akan menyenangkan untuk mencoba membuat semacam kecanduan. Karena setiap proyek memiliki package.json sendiri, kita harus terlebih dahulu pergi ke folder library dan menjalankan perintah install npm

 npm i -D @drag13/when-do npm i @drag13/round-to 

Saya sengaja menempatkan mereka dalam berbagai cara untuk memeriksa bagaimana pengepak akan menangani ini nanti. Semuanya diatur tanpa masalah. Kami mencoba mengumpulkan dan mendapatkan peringatan

Mendistribusikan paket npm dengan 'dependensi' tidak disarankan. Silakan pertimbangkan untuk menambahkan drag13 / round-to ke 'peerDependencies'atau hapus dari dependensi

Mendistribusikan paket dependensi npm tidak diinginkan. Silakan pertimbangkan untuk menambahkan drag13 / round-to dependency ke peerDependencies atau bahkan menghapusnya dari dependensi

dan kemudian kesalahan:

Ketergantungan drag13 / round-to harus secara eksplisit dimasukkan dalam daftar putih

Drag13 / round-to dependency harus ditambahkan secara eksplisit ke daftar putih.

Ini sudah menarik, secara desain, perpustakaan tidak ingin memiliki dependensi langsung. Kami mencoba untuk memindahkan kecanduan kami ke bagian peerDependencies dan menyusun kembali - voila, semuanya berfungsi. Tetapi itu berarti urutan instalasi perpustakaan pihak ketiga sekarang berbeda. Pertama, letakkan dependensi pada modul utama, lalu tambahkan pena ke bagian peerDependency perpustakaan dengan pena.

Sisanya bekerja sama dengan proyek Angular biasa.

Untuk meringkas secara singkat:

Pro:

• Kami bekerja di lingkungan yang akrab dengan tim yang akrab
• Ada pohon yang bergetar di luar kotak

Cons:

• Untuk "melihat komponen" Anda perlu menggunakan seluruh proyek
• Belum ada mode tontonan
• Sumber daya perlu disalin secara manual atau untuk mengkonfigurasi proses pembuatan sendiri.

Dan akhirnya, pergi ke publikasi

Posting

Semuanya ada di sini. Angular / cli menggunakan ng-packgr yang mapan untuk mempublikasikan, yang secara independen mengkompilasi kode kami ke dalam paket yang cocok untuk penerbitan npm, meninggalkan pengaturan file package.json (yang tidak kecil), minifikasi, pengemasan dalam format yang berbeda (misalnya, di UMD) .

Untuk menerbitkan paket Anda (atau melihat apa yang ada di dalamnya), Anda perlu menjalankan tiga perintah

 npx ng build --prod cd dist/mylib npm publish 

Jika Anda tidak ingin mempublikasikan, ganti perintah publish dengan paket

Sebagai hasilnya, saya mendapat yang berikut:

Pertama, mari kita lihat package.json, yang terlihat sangat berbeda dari package.json asli dari perpustakaan kami.

Seperti yang Anda lihat, paket tidak menghapus devDependencies kami, meskipun beberapa melakukannya. Selain itu, secara teoritis senang dengan jumlah format yang dijelaskan dalam package.json (meskipun saya tidak tahu setengah dari mereka).

Di dalam paket berisi bundel yang diperkecil dan tidak-diperkecil dalam format UMD, dan beberapa bundel lain dari format internal angular (fesm5, fesm2015). Tapi, yang paling penting, sekarang kepala pengembang tidak akan sakit tentang ini, yang hanya luar biasa.

Mari kita beralih ke kesimpulan.

Pro:

• Kenyamanan
• Perhatian

Total

Solusinya menarik, tetapi mentah. Awal dan publikasi sangat mudah, tetapi masih ada pertanyaan untuk pengembangan. Sangat frustasi bahwa sekarang perpustakaan bukanlah proyek yang dirancang sendiri, melainkan sebuah proyek tambahan dengan kemungkinan publikasi.

Di sisi lain, sejumlah besar pekerjaan telah dilakukan, fungsionalitasnya terus berkembang, dan saya yakin bahwa seiring waktu, kita akan mendapatkan alat yang sangat baik untuk pengembangan.