Nueva propuesta pide a los contribuyentes que dejen de fusionar las API experimentales de Gutenberg con el núcleo de WordPress

La práctica de fusionar las API experimentales de Gutenberg con el núcleo de WordPress pronto podría llegar a su fin. Una nueva propuesta, publicada por el colaborador patrocinado por Automattic, Adam Zielinski, pide a los colaboradores que estabilicen las API antes de fusionarlas en el núcleo.

A lo largo de los años, se fusionaron aproximadamente 280 API experimentales del complemento de Gutenberg, que Zielinski auditó en un ticket que abrió para el problema en abril. Al equilibrar el impulso para moverse rápido con la iteración de los editores contra el compromiso de WordPress con la compatibilidad con versiones anteriores, la cantidad de API experimentales se ha vuelto insostenible y la práctica de fusionarlas en el núcleo ahora se está reconsiderando activamente.

Oficialmente, las API experimentales están marcadas como tales para desalentar el uso de terceros, ya que se espera que cambien. En la práctica, las personas que crean para el editor de bloques los usan de todos modos porque están en el núcleo y quieren ampliar las funciones que habilitan estas API.

“Los autores de complementos y temas se ven obligados a confiar en las características __experimental que podrían eliminarse o cambiarse de manera incompatible con versiones anteriores en cualquier momento”, dijo Zielinski, haciéndose eco de la frustración y las preocupaciones que muchos desarrolladores han tenido con el proyecto en los últimos años. “Es una carga de mantenimiento seria. Cada nuevo lanzamiento de Gutenberg/WordPress significa cambios potencialmente importantes”.

El responsable principal de WordPress, Peter Wilson, comentó sobre el ticket y dijo que está a favor de limitar las API experimentales a productos de última generación. Refiriéndose a la necesidad de este cambio, citó una serie de impactos negativos que estas API experimentales centrales han tenido en el ecosistema:

• los encargados principales no están dispuestos a usar ciertas características de la biblioteca para facilitar las tareas principales porque no confían en la confiabilidad
• los desarrolladores ya no actualizan los sitios de clientes de WP. Como un usuario principal que se ha esforzado por mantener la compatibilidad con versiones anteriores durante años, esto me decepciona. Como miembro del equipo de seguridad, es muy preocupante
• los desarrolladores deciden incluir copias de paquetes en temas y complementos en lugar de confiar en los globales wp.* . Nuevamente, esto me preocupa desde una perspectiva de seguridad, pero también aumenta la carga útil de JavaScript significativamente más que mantener la compatibilidad con versiones anteriores.
• informes de interrupciones de compatibilidad con versiones anteriores en versiones menores: "no espera que una versión 5.9.1 rompa la capacidad de respuesta de un montón de imágenes en nuestros sitios fuera del editor de bloques"
• desarrolladores que consideran no usar nunca bloques centrales porque son demasiado inestables: "Dejé de usar/ampliar bloques centrales porque estaban cambiando demasiado y he estado usando bloques ACF para que al menos sepa que puedo hacer bloques que no descanso. De acuerdo, la interfaz de usuario no es tan buena como los bloques centrales, pero tomaré la estabilidad sobre los bloques que se rompen en cualquier momento”.

El complemento de Gutenberg estaba destinado a funcionar como un complemento de funciones donde se esperan interrupciones en la compatibilidad con versiones anteriores mientras los contribuyentes pulen las funciones antes de fusionarlas en el núcleo. Volver a las raíces de este enfoque y hacer que el editor sea menos experimental es el centro de esta propuesta.

“La inestabilidad entre las versiones ya está comenzando a alienar a algunos de los principales defensores externos de los editores de bloques”, dijo Wilson.

Mantener este nivel de inestabilidad podría desalentar a las personas a construir en WordPress, alejándolos a otros proyectos más sencillos que se administran de una manera diferente. Es posible que la necesidad de confiar en las API experimentales haya desanimado a los desarrolladores a crear más productos, lo que ha ralentizado la adopción del editor de bloques.

“Como autor de complementos que actualmente usa muchas API __experimental , me encantaría verlas estabilizadas”, dijo Nick Diego, colaborador patrocinado por WP Engine. “La mayoría brinda una funcionalidad crucial, pero crear un producto que se basa en una API __experimental siempre es un poco desconcertante. Siempre que el proceso sea extremadamente transparente, esté bien publicitado y proporcionemos a los autores de complementos/temas una guía sobre cómo migrar a versiones estables, entonces me gusta esta iniciativa”.

Después de meses de discusión sobre el ticket, Zielinski destiló las preocupaciones de los colaboradores en el plan de acción propuesto en el blog Make WordPress Core.

La propuesta indica que la mayoría de las API experimentales existentes ya fusionadas en el núcleo obtendrían un alias estable.

“Preservaría la compatibilidad con versiones anteriores y no debería afectar notablemente el tamaño del paquete”, dijo Zielinski. “Algunos necesitarán un tratamiento diferente; discutamos eso caso por caso”. También recomendó a los contribuyentes que consideren si es necesario eliminar una API experimental existente que ya está en el núcleo. Él no anticipa muchos casos de esto, pero recomienda que estos usen prácticas establecidas para contactar a los autores de complementos, usar desuso suaves y publicar publicaciones de Core.

"También veo dos cosas en juego aquí: el uso y abuso de las API experimentales durante el diseño de la API (generalmente para usarse y probarse en el complemento de Gutenberg) y la falta de un proceso diligente para estabilizarlas cuando cumplen con los criterios de diseño". El arquitecto principal de Gutenberg, Matias Ventura, comentó sobre el boleto original. “Los que deben considerarse públicos de facto son aquellos que han existido durante muchos lanzamientos en forma estable a pesar de su nomenclatura”.

Con el interés de preservar la capacidad de WordPress para cumplir con sus promesas de compatibilidad con versiones anteriores, la propuesta recomienda que las API experimentales se restrinjan al complemento de Gutenberg y nunca se fusionen con el núcleo. En los casos en que una característica estable depende de una API experimental, Zielinski identificó una respuesta simple:

“Entonces no es realmente estable. Primero estabilicemos las dependencias”.

Esta es esencialmente una nueva forma de avanzar que debería aumentar la estabilidad y la confianza en las API y actualizaciones de WordPress, pero tiene algunos inconvenientes.

Los usuarios y colaboradores pueden esperar que las características de Gutenberg se fusionen más lentamente con el núcleo, ya que no pueden confiar en las API experimentales cuando alcanzan la distribución en horario de máxima audiencia en las versiones principales. Zielinski también señaló que los contribuyentes también pueden tener dificultades para refactorizar estas API una vez que se hayan enviado y se utilicen en millones de sitios de WordPress.

Hasta ahora, la propuesta ha tenido un apoyo abrumadoramente positivo, ya que muchos creen que estas API nunca deberían haber llegado al núcleo en primer lugar mientras aún se encontraban en la etapa experimental.

“Estoy muy a favor de este enfoque”, dijo el desarrollador de WordPress Mark Root-Wiley. “Creo temas personalizados y tengo algunos complementos simples. Para ambos, me he visto forzado con cierta frecuencia a lidiar con API experimentales y las dificultades de mantenerme actualizado con ellas cuando las funciones se instalan en el núcleo que solo se pueden desactivar, ajustar o ampliar a través de una API experimental.

“Un regreso a este tipo de estabilidad en el núcleo contribuiría en gran medida a recuperar la buena voluntad de los desarrolladores”, comentó el colaborador de WordPress, Dovid Levine, sobre la propuesta.

La fecha límite para comentar sobre la propuesta es el 7 de septiembre, lo que cerraría la discusión apenas tres semanas antes de que se espere WordPress 6.1 Beta 1. Esto les da a los contribuyentes algo de tiempo para auditar más profundamente las API experimentales antes del próximo lanzamiento importante, en caso de que lleguen a un consenso sobre restringirlas al complemento de Gutenberg.