Una nuova proposta invita i collaboratori a interrompere l'unione di API sperimentali da Gutenberg a WordPress Core

La pratica di unire le API sperimentali di Gutenberg nel core di WordPress potrebbe presto finire. Una nuova proposta, pubblicata dal collaboratore sponsorizzato da Automattic Adam Zielinski, chiede ai contributori di stabilizzare le API prima di unirle nel core.

Nel corso degli anni, circa 280 API sperimentali sono state unite dal plugin Gutenberg, che Zielinski ha verificato in un ticket che ha aperto per l'emissione ad aprile. Nel bilanciare la spinta a muoversi velocemente con l'iterazione degli editor e l'impegno di WordPress per la compatibilità con le versioni precedenti, il numero di API sperimentali è diventato insostenibile e la pratica di unirle nel core viene ora attivamente riconsiderata.

Ufficialmente, le API sperimentali sono contrassegnate come tali per scoraggiare l'uso di terze parti, poiché dovrebbero cambiare. In pratica, le persone che creano per l'editor di blocchi li usano comunque perché sono nel core e vogliono estendere le funzionalità abilitate da queste API.

"Gli autori di plugin e temi sono costretti a fare affidamento sulle funzionalità __experimental che potrebbero essere rimosse o modificate in modo incompatibile con le versioni precedenti in qualsiasi momento", ha affermato Zielinski, facendo eco alla frustrazione e alle preoccupazioni che molti sviluppatori hanno avuto con il progetto negli ultimi anni. “Si tratta di un grave onere di manutenzione. Ogni nuovo comunicato di Gutenberg/WordPress significa cambiamenti potenzialmente interrotti".

Il core committer di WordPress Peter Wilson ha commentato il ticket, dicendo che è favorevole a limitare le API sperimentali a prodotti all'avanguardia. Portando a casa la necessità di questo cambiamento, ha citato una serie di impatti negativi che queste API sperimentali di base hanno avuto sull'ecosistema:

• i committenti principali non sono disposti a utilizzare determinate funzionalità della libreria per semplificare le attività principali perché non si fidano dell'affidabilità
• gli sviluppatori non aggiornano più i siti client WP. Come committente principale che si è sforzato di mantenere la compatibilità con le versioni precedenti per anni, questo mi delude. Come membro del team di sicurezza è molto preoccupante
• sviluppatori che decidono di includere copie di pacchetti in temi e plugin piuttosto che fare affidamento su wp.* globals. Ancora una volta questo mi preoccupa dal punto di vista della sicurezza, ma aumenta anche il carico utile di JavaScript in modo significativo più del mantenimento della compatibilità con le versioni precedenti
• segnalazioni di interruzioni della compatibilità con le versioni precedenti: "non ti aspetti che una versione 5.9.1 interrompa la reattività di un gruppo di immagini nei nostri siti al di fuori dell'editor di blocchi"
• sviluppatori che stanno pensando di non utilizzare mai i blocchi principali perché troppo instabili: "Ho smesso di usare/estendere i blocchi principali perché stavano cambiando troppo e ho utilizzato i blocchi ACF in modo da sapere almeno che posso creare blocchi che non lo faranno rompere. Concesso che l'interfaccia utente non è buona come i blocchi principali, ma prenderò stabilità in caso di blocchi che si rompono in qualsiasi momento".

Il plug-in Gutenberg doveva funzionare come un plug-in di funzionalità in cui sono previste interruzioni nella compatibilità con le versioni precedenti mentre i contributori lucidano le funzionalità prima di unirle nel core. Tornare alle radici di questo approccio, e rendere l'editor meno sperimentale, è al centro di questa proposta.

"L'instabilità tra le versioni sta già iniziando ad alienare alcuni dei più grandi sostenitori esterni degli editori di blocchi", ha detto Wilson.

Mantenere questo livello di instabilità potrebbe scoraggiare le persone dal costruire su WordPress, spingendole ad altri progetti più semplici che vengono gestiti in modo diverso. È possibile che la necessità di fare affidamento su API sperimentali abbia scoraggiato gli sviluppatori dal creare più prodotti, rallentando l'adozione dell'editor di blocchi.

"Come autore di plugin che attualmente utilizza molte __experimental , mi piacerebbe vederle stabilizzate", ha affermato Nick Diego, collaboratore sponsorizzato da WP Engine. “La maggior parte fornisce funzionalità cruciali, ma la creazione di un prodotto che si basa su un'API __experimental è sempre un po' sconcertante. Finché il processo è estremamente trasparente, è ben pubblicizzato e forniamo agli autori di plugin/temi una guida su come migrare a versioni stabili, questa iniziativa mi piace".

Dopo mesi di discussioni sul ticket, Zielinski ha distillato le preoccupazioni dei contributori nel piano d'azione proposto sul blog Make WordPress Core.

La proposta indica che la maggior parte delle API sperimentali esistenti già unite nel core otterrebbero un alias stabile.

"Conserverebbe la compatibilità con le versioni precedenti e non dovrebbe influire in modo significativo sulle dimensioni del pacchetto", ha affermato Zielinski. “Alcuni avranno bisogno di un trattamento diverso; discutiamolo caso per caso". Ha anche raccomandato ai contributori di considerare se un'API sperimentale esistente già nel core deve essere rimossa. Non prevede molti casi di ciò, ma consiglia di utilizzare pratiche consolidate per contattare gli autori di plug-in, utilizzare deprecazioni soft e pubblicare post principali.

"Vedo anche due cose in gioco qui: l'uso e l'abuso di API sperimentali durante la progettazione dell'API (generalmente da utilizzare e testare nel plug-in Gutenberg) e la mancanza di un processo diligente per stabilizzarle quando soddisfano i criteri di progettazione", L'architetto capo Gutenberg Matias Ventura ha commentato il biglietto originale. "Quelli che devono essere considerati de facto pubblici sono quelli che sono esistiti per molte versioni in una forma stabile nonostante la loro nomenclatura".

Nell'interesse di preservare la capacità di WordPress di mantenere le promesse di compatibilità con le versioni precedenti, la proposta raccomanda che le API sperimentali siano limitate al plug-in Gutenberg e non vengano mai unite nel core. Nei casi in cui una funzionalità stabile dipende da un'API sperimentale, Zielinski ha identificato una risposta semplice:

“Allora non è effettivamente stabile. Stabilizziamo prima le dipendenze.

Questo è essenzialmente un nuovo modo di andare avanti che dovrebbe aumentare la stabilità e la fiducia nelle API e negli aggiornamenti di WordPress, ma presenta alcuni inconvenienti.

Utenti e collaboratori possono aspettarsi che le funzionalità di Gutenberg possano essere più lente nell'unione nel core, poiché non possono fare affidamento su API sperimentali quando raggiungono la distribuzione in prima serata nelle versioni principali. Zielinski ha anche notato che i contributori potrebbero anche avere difficoltà a refactoring di queste API una volta che sono state spedite e utilizzate su milioni di siti WordPress.

Finora la proposta ha avuto un sostegno estremamente positivo, poiché molti credono che queste API non avrebbero mai dovuto arrivare al nucleo in primo luogo mentre erano ancora nella fase sperimentale.

"Sono molto favorevole a questo approccio", ha affermato lo sviluppatore di WordPress Mark Root-Wiley. “Costruisco temi personalizzati e ho alcuni semplici plugin. Per entrambi, mi sono trovato piuttosto frequentemente costretto a gestire API sperimentali e le difficoltà di tenermi aggiornato con loro quando vengono inserite funzionalità che possono essere disattivate, regolate o estese solo tramite un'API sperimentale".

"Un ritorno a questo tipo di stabilità nel core farebbe molto per riconquistare la buona volontà degli sviluppatori", ha commentato la proposta Dovid Levine, collaboratore di WordPress.

La scadenza per commentare la proposta è il 7 settembre, il che chiuderebbe la discussione poco meno di tre settimane prima che WordPress 6.1 Beta 1 sia previsto. Ciò offre ai contributori un po' di tempo per controllare in modo più approfondito le API sperimentali prima della prossima versione principale, nel caso in cui dovessero raggiungere un consenso sul limitarle al plug-in Gutenberg.