BerandaComputers and TechnologyCoding dalam PHP 7.4 dan diterapkan ke 7.1 melalui Rector dan GitHub...

Coding dalam PHP 7.4 dan diterapkan ke 7.1 melalui Rector dan GitHub Actions

Pengembang PHP ingin memiliki akses ke fitur bahasa terbaru, tetapi karena berbagai alasan, mereka mungkin tidak sudah bisa. Bisa jadi server klien berjalan pada versi yang lebih lama dan tidak dapat ditingkatkan, atau CMS harus mendukung kode lama, atau basis pengguna akan menyusut secara signifikan, atau lainnya.

Tapi ada solusi: kita bisa menggunakan transpiler untuk mengubah kode menggunakan sintaks baru ke yang lama. Transpiler memberikan yang terbaik dari kedua dunia; pengembang dapat membuat kode menggunakan fitur terbaru dan menghasilkan aset untuk produksi yang bekerja dengan versi bahasa sebelumnya.

Dalam artikel saya sebelumnya , Saya perkenalkan Rektor , alat rekonstruksi untuk PHP. Sekarang mari kita praktikkan. Pada artikel ini, kita akan mempelajari cara mengembangkan plugin WordPress menggunakan kode PHP 7.4 dan merilisnya yang berisi kode dari PHP 7.1 dan di bawahnya melalui Rector dan Tindakan GitHub .

Mengapa PHP 7.1

Saya mulai mengubah plugin WordPress saya karena WordPress memutuskan bukan ke meningkatkan versi PHP minimum , yang saat ini 5,6. Anda mungkin bertanya-tanya, mengapa saya beralih ke PHP 7.1 dan bukan ke PHP 5.6?

Ada dua alasan untuk ini. Pertama, Rektor melakukan transformasi berdasarkan aturan , seperti sebagai ArrowFunctionToAnonymousFunctionRector , yang menurunkan kode dari panah fungsi dari PHP 7.4 ke fungsi anonim dari PHP 7.3 dan di bawahnya:

 kelas SomeClass  {      public function run ()      {          $ pembatas=",";  - $ callable=fn ($ pertandingan)=> $ pembatas. strtolower ($ pertandingan [1]);   + $ callable=fungsi ($ kecocokan) gunakan ($ pembatas) { + return $ delimiter. strtolower ($ pertandingan [1]); +};       }  } 

Dari sekitar 20 aturan downgrade diterapkan hingga saat ini , hanya sedikit dari PHP 7.1 hingga 7.0, dan tidak ada dari 7.0 hingga 5.6. Jadi, ada dukungan terbatas untuk mencapai 7.0, dan belum ada dukungan untuk penargetan 5.6.

Bukan berarti Rektor tidak dapat mendukung PHP 5.6, tetapi pekerjaan harus diselesaikan. Jika aturan akhirnya diterapkan (sebelum WordPress mengubah versi minimumnya menjadi 7.1, jika tidak, aturan tersebut tidak akan diperlukan lagi), saya dapat menargetkan versi PHP yang lebih rendah.

Alasan kedua menyangkut dependensi PHP pihak ketiga. Ini juga harus ditranspilasi, di samping kode aplikasi kita, dan melakukannya mungkin memerlukan upaya yang signifikan.

Misalnya, jika ketergantungan memerlukan PHP 7.1, dan saya menargetkan PHP 7.1 untuk aplikasi saya, maka ketergantungan tersebut langsung didukung dan saya tidak perlu mentranspilasi kodenya. Tetapi jika saya menargetkan PHP 7.0 atau 5.6, maka saya perlu melakukan transpilasinya.

Transparansi dependensi pihak ketiga dapat menjadi tantangan karena tidak di bawah kendali saya. Hanya menelusuri kodenya saja tidak cukup; Saya perlu melakukan penelitian menyeluruh untuk memastikan bahwa semua kode PHP 7.1 dalam dependensi dapat ditransformasikan. Satu fitur yang luput dari perhatian saya dapat membuat aplikasi gagal saat runtime.

Dalam kasus saya, aplikasi saya memiliki satu ketergantungan yang membutuhkan PHP 7.2 dan beberapa lusin membutuhkan PHP 7.1 (lebih lanjut tentang ini nanti). Karena saya tidak memiliki sumber daya yang tidak terbatas, saya memilih untuk menargetkan PHP 7.1 dan mentranspilasi satu dependensi daripada menargetkan 7.0 dan transpile lusin.

Akibatnya, plugin WordPress saya tidak akan tersedia untuk pengguna yang menjalankan WordPress 5.6 dan 7.0, tetapi saya senang dengan itu.

Fitur PHP yang didukung

Saat menyatakan bahwa aplikasi sekarang dapat menggunakan kode PHP 7.4, itu tidak berarti aplikasi tersebut dapat digunakan setiap fitur yang diperkenalkan ke PHP 7.4 . Sebaliknya, ia hanya dapat menggunakan fitur-fitur yang memiliki aturan Rektor untuk menurunkannya.

Selain itu, tidak semua fitur dapat ditransformasikan , dan beberapa fitur tidak akan ditransformasikan karena beberapa alasan atau lainnya.

Misalnya, di antara konstanta baru yang diperkenalkan di PHP 7.4 , konstanta SO_LABEL , SO_PEERLABEL , dan lainnya adalah opsi soket khusus FreeBSD. Itu sepertinya terlalu spesifik, jadi saya tidak berharap ada orang yang menerapkan aturan Rektor untuk mereka.

Akibatnya, aplikasi tidak akan sepenuhnya mendukung PHP 7.4 (jika ada yang membutuhkan konstanta SO_LABEL , itu tidak akan ada); sebagai gantinya, ini dapat sepenuhnya mendukung PHP 7.1 dan ditingkatkan dengan serangkaian fitur dari PHP 7.2, 7.3, dan 7.4.

Daftar di bawah ini mencantumkan fitur yang saat ini didukung untuk merilis aplikasi untuk PHP 7.1. Daftar ini (yang akan bertambah seiring komunitas menerapkan downgrade yang tersisa rules ) juga mencakup fitur yang didukung oleh Paket Symfony polyfill :

Pernahkah Anda memperhatikan bahwa beberapa fitur PHP 8.0 sudah didukung? Segera setelah PHP 8.0 dirilis sekitar akhir tahun ini, Anda dapat segera mulai menggunakan tipe serikat dalam kode aplikasi Anda tanpa melepaskan dukungan untuk PHP 7.1… Seberapa keren itu?

Input dan output transparansi

Saya akan menggunakan plugin saya sendiri GraphQL API untuk WordPress dan paketnya untuk mendemonstrasikan cara mentranspilasi plugin WordPress melalui Rector.

Kode pada plugin menggunakan fitur dari PHP 7.4, 7.3, dan 7.2, yaitu:

  • Properti yang diketik, fungsi panah, operator penugasan penggabungan nol, membongkar di dalam array, dan pemisah literal numerik dari PHP 7.4
  • Penugasan referensi dalam pengrusakan array dan sintaks Heredoc yang fleksibel dari PHP 7,3
  • obyek kembali dan jenis param dari PHP 7.2

Saat transpiling, fitur-fitur ini kemudian diubah ke kode yang setara dari PHP 7.1.

Tabel ini menampilkan contoh-contoh dari kode sumber dan diubah menjadi apa Rektor ketika menghasilkan aset untuk produksi :

Fitur PHP Kode sumber Kode transparan
Properti yang diketik
 kelas ModuleTypeRegistry {  - array yang dilindungi $ moduleTypeResolvers=[];  } 
 kelas ModuleTypeRegistry {  + / + @ var array + / + dilindungi $ moduleTypeResolvers=[];  } 
Fungsi panah
 $ modules=array_filter (   $ modules,  - fn ($ module)=>! $ this-> getModuleResolver ($ module) -> isHidden ($ module )  ); 
 $ modules=array_filter (   $ modules,  + fungsi ($ modul) { + kembali! $ this-> getModuleResolver ($ module) -> isHidden ($ module); +}  ); 
Penggabungan nol operator tugas
  - $ fragments ??=$ this-> getFragments ();  
  + $ fragments=$ fragments ?? $ ini-> getFragments ();  
Membongkar di dalam array
  -kembali [-  ...$categories,-  [-    'slug'=> $this->getBlockCategorySlug(),-    'title'=> $this->getBlockCategoryTitle(),-  ], -]; 
  + return array_merge ( + $ kategori, [[+    'slug'=> $this->getBlockCategorySlug(),+    'title'=> $this->getBlockCategoryTitle(),+  ]] +);  
Pemisah literal numerik
  - $ executionTime / 1_000_000  
  + $ executionTime / 1000000  
Referensi tugas dalam daftar () / penghancuran array
  - [&$vars]=$ vars_in_array;  
  + $ vars=& $ vars_in_array [0];  
Sintaks Heredoc Fleksibel
  -kembali  
  + kembali  
obyek ketik kembali
  -publik function getInstance (string $ class): object;  
  + / + @ objek kembali + / + fungsi publik getInstance (string $ class);  
obyek ketik params
  -publik function getID (object $ resultItem)  {   $ direktif=$ resultItem;   return $ directive-> getID (); } 
  + / + @ objekparam $ resultItem + / + getID fungsi publik ($ resultItem)  {   $ direktif=$ resultItem;   return $ directive-> getID (); } 

File tersebut berasal dari dua sumber: src / dan folder folder vendor / .

src / adalah tempat kode aplikasi disimpan, jadi sepenuhnya di bawah kendali saya. Karena itu, saya dapat menjamin bahwa kode ini hanya akan berisi fitur PHP yang didukung yang dijelaskan sebelumnya.

penjaja/ berisi semua dependensi (dikelola melalui Komposer) baik yang dimiliki oleh saya maupun oleh pihak ketiga . Untuk plugin saya, semua dependensi ke transpile (dari pemilik getpop , skema pop , dan graphql-by-pop ) juga milik saya, jadi sekali lagi, saya jamin kode ini hanya akan berisi fitur yang didukung.

Path yang dikecualikan sesuai dengan dependensi yang disertakan yang sudah saya ketahui hanya berisi kode PHP 7.1 dan di bawahnya. Jadi tidak ada yang perlu diungkapkan untuk mereka, dan karena itu, saya langsung melewatkan menjalankan Rektor pada mereka.

Bagaimana dengan dependensi pihak ketiga? Mengapa saya tidak mentransformasikan salah satu dari mereka?

Untungnya, saya tidak perlu melakukannya. Inilah alasannya.

Transparansi dependensi pihak ketiga

Kita perlu mencari tahu apakah dependensi pihak ketiga harus ditransformasikan ke PHP 7.1.

Langkah pertama adalah mencari tahu dependensi mana yang memerlukan PHP 7.2 atau lebih tinggi. Untuk itu, kami menginstal dependensi Composer untuk produksi karena di situlah kami akan menjalankan kode transparan:

  pemasangan komposer --no-dev  

Sekarang kita bisa mendapatkan daftar dependensi yang tidak mendukung PHP 7.1 dengan menjalankan:

  komposer kenapa tidak php 7.1.33  

Harap perhatikan bahwa batasannya ada pada versi 7.1.33 (yang merupakan versi terbaru PHP 7.1) dan tidak langsung di 7.1 . Itu karena 7.1 diartikan sebagai 7.1.0 , jadi paket membutuhkan versi 7.1.3 juga akan gagal.

Untuk plugin saya, menjalankan perintah di atas menghasilkan dependensi berikut:

 symfony / cache v5.1.6 membutuhkan php (>=7.2.5) symfony / cache-contract v2.2.0 membutuhkan php (>=7.2.5) symfony / expression-language v5.1.6 membutuhkan php (>=7.2.5) symfony / filesystem v5.1.6 membutuhkan php (>=7.2.5) symfony / inflector v5.1.6 membutuhkan php (>=7.2.5) symfony / service-contract v2.2.0 membutuhkan php (>=7.2.5) symfony / string v5.1.6 membutuhkan php (>=7.2.5) symfony / var-eksportir v5.1.6 membutuhkan php (>=7.2.5) 

Jadi saya harus memeriksa kode sumber untuk delapan paket ini untuk memeriksa mengapa mereka memerlukan setidaknya PHP 7.2.5 dan mencari tahu apakah kode itu dapat ditranspilasi.

Enam paket ( kontrak-cache , ekspresi-bahasa , berkas sistem, inflektor , kontrak layanan , dan string ) hanya menggunakan kode PHP 7.1 ke bawah. Mereka memiliki persyaratan pada PHP 7.2.5 hanya karena salah satu dependensinya memiliki persyaratan ini.

Saya tidak tahu (dan saya tidak peduli) apakah paket symfony / var-eksportir , yang merupakan ketergantungan dari symfony / cache , berisi kode PHP 7.2: ini dirujuk dari kelas yang tidak digunakan plugin saya ( PhpArrayAdapter dan PhpFilesAdapter ), dan karena PSR-4 dan pemuatan otomatis, tidak ada kelas dari paket yang akan dimuat saat runtime .

Akhirnya, paket symfony / cache memang berisi kode PHP 7.2, di kelas PdoAdapter . Saya dapat memindahkan kode ini (ada aturan downgrade yang sesuai ) tetapi ada tidak perlu: aplikasi saya tidak mengakses kelas PdoAdapter , dan karena PSR-4 , tidak pernah dimuat.

Delapan paket ini agak kecil, dan PHP 7.2 hanya memperkenalkan beberapa fitur baru , jadi mencari kemunculan kode PHP 7.2 di dalamnya tidak terlalu sulit. Tetapi memiliki paket yang lebih besar, atau menargetkan versi PHP dengan lebih banyak fitur, akan membuat tugas menjadi lebih sulit.

Set downgrade

Selanjutnya, kami menentukan set atau aturan apa yang akan diterapkan pada kode:

 // di sini kita dapat menentukan kumpulan aturan apa yang akan diterapkan   $ parameter-> set (Option :: SETS, [    // @todo Uncomment when PHP 8.0 released    // SetList::DOWNGRADE_PHP80,    SetList::DOWNGRADE_PHP74,    SetList::DOWNGRADE_PHP73,    SetList::DOWNGRADE_PHP72,  ]); 

Pernahkah Anda melihat yang dikomentari SetList :: DOWNGRADE_PHP80 baris? Pada hari yang sama ketika PHP 8.0 dirilis, hanya dengan menghapus komentar pada baris tersebut, plugin saya dapat mulai menggunakan tipe gabungan 😎.

Mengenai urutan eksekusi set, kode harus diturunkan dari versi yang lebih tinggi ke versi yang lebih rendah:

  • Dari PHP 7,4 hingga 7,3
  • Dari PHP 7,3 hingga 7,2
  • Dari PHP 7,2 hingga 7,1

Dengan aturan saat ini, ini tidak membuat perbedaan, tetapi akan terjadi jika kode yang diturunkan harus dimodifikasi oleh aturan lain dari versi PHP yang lebih rendah.

Misalnya, operator penetapan penggabungan nol ??= yang diperkenalkan di PHP 7.4 adalah diturunkan seperti ini :

 $ array=[];  - $ array ['user_id'] ??='nilai';   + $ array ['user_id']=$ array ['user_id'] ?? 'nilai';

Kemudian, jika menurunkan versi sepenuhnya ke PHP 5.6, kode yang ditranspilasi dengan operator penggabungan nol ?? juga harus diturunkan, seperti ini:

 $ array=[];  - $ array ['user_id']=$ array ['user_id'] ?? 'nilai';  + $ array ['user_id']=isset ($ array ['user_id'])? $ array ['user_id']: 'nilai';  

Memuat WordPress

Karena WordPress tidak menggunakan pemuatan otomatis Komposer, kami harus menyediakan jalur ke file sumbernya, jika tidak, Rektor akan memberikan kesalahan setiap kali menemukan kode WordPress (seperti menjalankan fungsi WordPress , diperluas dari kelas dari WordPress, atau lainnya):

 // Rektor mengandalkan pengaturan muat otomatis proyek Anda; Pemuatan otomatis komposer disertakan secara default; untuk menambahkan lebih banyak:   $ parameter-> set (Option :: AUTOLOAD_PATHS, [    // full directory    __DIR__ . '/vendor/wordpress/wordpress',  ]); 

Untuk mengunduh file sumber WordPress, kami menambahkan WordPress sebagai ketergantungan Komposer (tetapi hanya untuk pengembangan), dan kami menyesuaikan lokasinya ke vendor / wordpress / wordpress . Composer.json kami akan terlihat seperti ini:

 {   "membutuhkan-dev": {     "johnpbloch / wordpress": ">=5.5"   },   "ekstra": {     "wordpress-install-dir": "vendor / wordpress / wordpress"   } } 

Berurusan dengan WordPress

Hanya memasukkan jalur muat otomatis untuk WordPress mungkin tidak cukup. Misalnya, ketika menjalankan Rektor, saya akan mendapatkan kesalahan ini (yang menelusuri kembali ke kelas referensi kode saya WP_Upgrader ):

 Peringatan PHP: Penggunaan ABSPATH konstan yang tidak ditentukan - diasumsikan 'ABSPATH' (ini akan memunculkan Kesalahan dalam versi PHP yang akan datang ) di ... / graphql-api-for-wp / vendor / wordpress / wordpress / wp-admin / include / class-wp-upgrader.php on line 13 

Saya tidak menggali lebih dalam mengapa ini terjadi, tetapi tampaknya kode WordPress yang mendefinisikan konstanta ABSPATH (dalam wp-load.php ) entah bagaimana tidak dieksekusi. Jadi saya hanya mereplikasi logika ini di konfigurasi Rektor saya, dengan menunjuk ke file sumber WordPress:

 / Tentukan ABSPATH sebagai direktori file ini /   if (! didefinisikan ('ABSPATH')) {     definisikan ('ABSPATH', __DIR__. '/ vendor / wordpress / wordpress /');   } 

Rektor Pelaksana

Konfigurasi Rektor sudah diatur, jadi mari kita mulai mentransformasikan beberapa kode!

Untuk menjalankan Rector, di root folder plugin kita jalankan:

 proses vendor / bin / rektor --dry-run 

Kita harus menggunakan --dry-run karena kami menurunkan kode, dan kami tidak melakukannya ingin mengganti file sumber. Proses tanpa - uji coba harus dijalankan dalam proses integrasi berkelanjutan kami saat memproduksi aset untuk produksi (lebih lanjut tentang ini nanti).

Untuk plugin saya, Rektor membutuhkan waktu sekitar 1 menit untuk memproses 16 aturan downgrade pada 4.188 file yang terdapat pada path yang ditentukan, setelah itu akan ditampilkan bagaimana kode dari 173 file nantinya. diubah:

Running Rector on the Plugin
Menjalankan Rektor di plugin.

Menguji kode yang ditranspilasi

Setelah kami membuat kode transparan, bagaimana kami tahu bahwa kode itu berfungsi dengan baik? Artinya, jika kami menargetkan PHP 7.1, bagaimana kami dapat memastikan bahwa semua bagian kode dari PHP 7.2 dan di atasnya telah diturunkan versinya?

Cara saya menemukan adalah dengan menggunakan PHP 7.1 untuk menjalankan kode yang diturunkan. Jika ada kode PHP 7.2 atau di atasnya masih tetap ada, dan itu refe dirusak, mesin PHP tidak akan mengenalinya dan membuat kesalahan.

Saya telah menerapkan solusi ini dengan Travis sebagai bagian dari proses integrasi berkelanjutan saya. Setiap kali kode baru didorong ke repo, itu memvalidasi bahwa itu dapat diturunkan dengan benar. Untuk menegaskan ini, saya hanya menjalankan PHPStan pada kode transparan; jika proses PHPStan keluar tanpa kesalahan, itu berarti semua kode yang ditranspilasi kompatibel dengan PHP 7.1.

Solusi yang menghasilkan hasil ini (perhatikan penghapusan kode transparan dengan warna merah, dan penambahan dengan warna hijau), diimplementasikan di sini :

 bahasa: php os:   - linux dist: bionik  php:   - 7.4  pekerjaan:   termasuk:     - name: "Test downgrade"       naskah:         - proses vendor / bin / rektor         - Composer config platform-check false         - komposer dumpautoload         - phpenv lokal 7.1         - analisis vendor / bin / phpstan -c phpstan.neon.dist src /       after_script: lewati  naskah:   - vendor / bin / phpunit --coverage-text --coverage-clover=coverage.clover 

Mari kita lihat cara kerja solusi ini.

Pertama-tama kita menurunkan kode melalui Rektor dengan menjalankan proses vendor / bin / rektor . Karena file sumber berisi kode PHP 7.4, menjalankan Rector harus dilakukan pada PHP 7.4, atau jika tidak, mesin PHP akan membuat kesalahan saat mengurai file.

Composer v2 (dirilis beberapa hari yang lalu) diperkenalkan pemeriksaan platform . Sejak composer.json membutuhkan PHP 7.4, tetapi kami akan menjalankan PHP 7.1, kami harus menonaktifkannya, atau mengeksekusi phpstan akan memicu kesalahan. Untuk itu, pertama-tama kita jalankan komposer config platform-check false , lalu komposer dumpautoload untuk menghapus file vendor / komposer / platform_check.php , dimana validasi terjadi.

Setelah menurunkan kode, kami mengalihkan versi PHP lingkungan dari 7.4 ke 7.1. Untuk alasan ini kami menggunakan Ubuntu 18.04 LTS, Bionic sebagai lingkungan build karena dilengkapi dengan PHP 7.1 sudah diinstal sebelumnya , dan kita dapat beralih ke PHP 7.1 dengan menjalankan phpenv lokal 7.1 .

Perintah vendor / bin / phpstan menganalisis -c phpstan.neon.dist src / lalu menjalankan PHPStan pada kode yang diturunkan. Proses ini keluar dengan 0 berarti bahwa penurunan telah berhasil, jika tidak, pesan kesalahan akan ditampilkan menunjuk ke kode yang gagal.

Plugin saya menggunakan versi terbaru PHPUnit (versi 9.4), yang membutuhkan PHP 7.3 atau lebih tinggi. Oleh karena itu, proses ini tidak dapat menjalankan PHPUnit atau akan gagal, itulah sebabnya proses ini dilewati. Kemudian, Travis harus menggunakan matriks untuk melakukan pengujian yang berbeda, dan PHPUnit dijalankan pada proses terpisah.

Berurusan dengan keanehan

Kami terkadang menemukan keanehan yang mungkin perlu kami perbaiki.

Misalnya, saya menjalankan PHPStan pada kode sumber untuk menghindari potensi bug dari ketidakcocokan jenis (menggunakan mode paling ketat , level 8 ). PHPStan saat ini memiliki bug yang meneruskan fungsi anonim ke array_filter mungkin menampilkan kesalahan yang tidak ada , tetapi meneruskan fungsi panah bekerja dengan baik .

Akibatnya, perilaku PHPStan pada kode sumber yang berisi fungsi panah, dan pada versi transparannya yang berisi fungsi anonim, mungkin berbeda. Untuk plugin saya, PHPStan tidak akan menampilkan kesalahan apa pun untuk panah ini fungsi :

 $ skipSchemaModuleComponentClasses=array_filter (   $ maybeSkipSchemaModuleComponentClasses,   fn ($ module)=>! $ moduleRegistry-> isModuleEnabled ($ module),   ARRAY_FILTER_USE_KEY ); 

Tapi itu akan memunculkan kesalahan untuk kode transparannya:

 $ skipSchemaModuleComponentClasses=array_filter (   $ maybeSkipSchemaModuleComponentClasses,   function ($ module) use ($ moduleRegistry) {       return! $ moduleRegistry-> isModuleEnabled ($ module);   },   ARRAY_FILTER_USE_KEY ); 

Untuk memperbaikinya, saya mengkonfigurasi PHPStan untuk mengabaikan kesalahan (untuk kode yang diturunkan) dan menonaktifkan kegagalan jika ada kesalahan yang tidak cocok (untuk kode sumber) :

 parameter:   reportUnmatchedIgnoredErrors: false   ignoreErrors:     -       pesan: '# ^ Parameter  # 1  $ modul metode GraphQLAPI \ GraphQLAPI \ Registries \ ModuleRegistryInterface :: isModuleEnabled  () mengharapkan string, array   diberikan . $ # '       jalur: src / PluginConfiguration.php 

Sebagai kesimpulan, kita harus selalu memeriksa ulang bahwa kode sumber dan versi transparansinya menghasilkan perilaku yang sama saat menjalankan proses pada mereka untuk menghindari kejutan yang tidak menyenangkan.

Menghasilkan aset untuk produksi melalui GitHub Actions

Kita hampir selesai. Sekarang, kami telah mengkonfigurasi transpiling dan mengujinya. Yang harus dilakukan hanyalah mentranspilasi kode saat menghasilkan aset untuk produksi. Aset ini akan menjadi plugin WordPress yang sebenarnya, untuk didistribusikan untuk instalasi.

Karena kode plugin saya dihosting di GitHub, saya telah membuat tindakan GitHub yang, setelah menandai kode, akan menghasilkan aset transparan. Tindakan tersebut memiliki konten ini :

 nama: Hasilkan Plugin yang Dapat Diinstal dan Unggah sebagai Aset Rilis di:   melepaskan:     jenis: [published] pekerjaan:   membangun:     nama: Build, Downgrade dan Upload Release     berjalan-di: ubuntu-terbaru     Langkah:       - nama: Kode keluar         penggunaan: tindakan / checkout @ v2       - name: Kode downgrade untuk produksi (ke PHP 7.1)         jalankan: |           penginstalan komposer           proses vendor / bin / rektor           sed -i 's / Membutuhkan PHP: 7.4 / Membutuhkan PHP: 7.1 /' graphql-api.php       - name: Bangun proyek untuk produksi         jalankan: |           komposer instal --no-dev --optimize-autoloader           mkdir membangun       - name: Buat artefak         penggunaan: montudor/action-zip@v0.1.0         dengan:           args: zip -X -r build / graphql-api.zip. -x .git node_modules /  *. "/ . *" CODE_OF_CONDUCT.md CONTRIBUTING.md ISSUE_TEMPLATE.md PULL_REQUEST_TEMPLATE.md rector.php .dist composer. dev-helpers build - nama: Unggah artefak         menggunakan: tindakan / upload-artefak @ v2         dengan:             nama: graphql-api             jalur: build / graphql-api.zip       - nama: Unggah untuk merilis         menggunakan: JasonEtco / upload-to-release @ master         dengan:           args: aplikasi build / graphql-api.zip / zip         env:           GITHUB_TOKEN: $ {{secret.GITHUB_TOKEN}} 

Aku sudah didokumentasikan di blog saya sebagian besar langkah dari tindakan ini: bagaimana itu dipicu, bagaimana itu membuat yang baru .zip yang berisi semua dependensi Composer, dan bagaimana file itu diunggah sebagai aset rilis ke repo GitHub.

Satu-satunya tambahan baru adalah langkah untuk menurunkan versi kode, yang terjadi di sini:

 - nama: Kode downgrade untuk produksi (ke PHP 7.1)         jalankan: |           penginstalan komposer           proses vendor / bin / rektor           sed -i 's / Membutuhkan PHP: 7.4 / Membutuhkan PHP: 7.1 /' graphql-api.php 

Harap perhatikan caranya pemasangan komposer dijalankan dua kali dalam tindakan: pertama kali tanpa - tanpa-dev karena Rektor dipasang sebagai ketergantungan dev , dan kemudian lagi dengan - tanpa-dev untuk menghapus semua dependensi dev dari bawah vendor / sebelum menghasilkan aset untuk produksi.

Setelah menginstal dependensi, kami menjalankan proses vendor / bin / rektor untuk mentranspilasi kode. Tidak ada - uji coba di sini, sehingga Rektor tidak hanya menampilkan transformasi, tetapi juga menerapkannya pada file masukan.

Kemudian, kita harus memodifikasi Membutuhkan header PHP di file utama plugin (yang diandalkan WordPress untuk memvalidasi apakah plugin dapat diinstal) dari 7.4 hingga 7.1 . Kami melakukan ini dengan menjalankan sed -i 's / Membutuhkan PHP: 7.4 / Membutuhkan PHP: 7.1 / 'graphql-api.php .

Langkah terakhir ini mungkin tampak detail. Bagaimanapun, saya bisa mendefinisikan header Membutuhkan PHP: 7.1 sudah ada di kode sumber. Namun, kami juga dapat menginstal plugin langsung dari repo (memang, itu kasus pengembangan). Jadi, untuk konsistensi, baik kode sumber maupun yang dihasilkan . Zip plugin file harus menunjukkan versi PHP masing-masing.

Terakhir, saat membuat . zip file, kita harus mengecualikan file rector.php (bersama dengan semua file lain untuk dikecualikan):

 - nama: Buat artefak         penggunaan: montudor/action-zip@v0.1.0         dengan:           args: zip -X -r build / graphql-api.zip. -x rector.php ... 

Saat tindakan GitHub ini dipicu, ini akan menghasilkan aset plugin graphql-api.zip dan unggah ke halaman rilis :

The Generated Plugin Asset
Aset plugin yang dihasilkan.

Mari kita periksa apakah pembuatan aset berhasil. Untuk itu, saya unduh plugin transparan graphql-api.zip , instal di Situs WordPress yang menjalankan PHP 7.1, lalu menjalankan fungsinya (dalam hal ini, eksekusi kueri GraphQL):

WordPress di PHP 7.1 menjalankan plugin transparan.

Berhasil!

Kesimpulan

Plugin dikodekan menggunakan fitur dari PHP 7.4, dan dapat diinstal di WordPress yang menjalankan PHP 7.1. Tujuan tercapai 🙏.

Transparansi kode PHP memberi kami kesempatan untuk memisahkan pengembangan aplikasi dari aplikasi itu sendiri, sehingga kami dapat menggunakan fitur PHP terbaru meskipun klien atau CMS kami tidak dapat dukung mereka. PHP 8.0 sudah dekat. Ingin menggunakan tipe serikat? Sekarang Anda bisa melakukannya!

Anda sering datang ke sini! Kami harap Anda menikmati Blog LogRocket . Bisakah Anda mengisi survei tentang apa yang Anda ingin kami tulis?

LogRocket : Visibilitas penuh ke Anda aplikasi web

LogRocket Dashboard Free Trial Banner

LogRocket adalah solusi pemantauan aplikasi frontend yang memungkinkan Anda memutar ulang masalah seolah-olah terjadi di browser Anda sendiri. Alih-alih menebak mengapa kesalahan terjadi, atau meminta pengguna untuk tangkapan layar dan log dump, LogRocket memungkinkan Anda memutar ulang sesi untuk memahami dengan cepat apa yang salah. Ini berfungsi sempurna dengan aplikasi apa pun, apa pun kerangka kerjanya, dan memiliki plugin untuk mencatat konteks tambahan dari Redux, Vuex, dan @ ngrx / store.

Selain mencatat tindakan dan status Redux, LogRocket mencatat log konsol, kesalahan JavaScript, pelacakan tumpukan, permintaan / tanggapan jaringan dengan header + badan, metadata browser, dan log khusus. Ini juga memperlengkapi DOM untuk merekam HTML dan CSS pada halaman, membuat ulang video dengan piksel sempurna bahkan dari aplikasi satu halaman yang paling kompleks.

Coba gratis .

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments