Llego un poco tarde al juego, pero con respecto a la migración de complementos populares al núcleo de Discourse, ¿qué debe hacer uno si estaba utilizando una bifurcación modificada de un complemento que se fusionó?
El complemento de integración de chat de Discourse existente no tenía esta característica, y todavía no la tiene.
Hace un tiempo, otro miembro de mi equipo actualizó nuestro servidor de Discourse y, al notar que el complemento ahora estaba incluido de forma nativa con Discourse, porque la compilación falló en la actualización, simplemente eliminó el clon de mi bifurcación.
Y ahora me he dado cuenta de que mi característica ha desaparecido.
Entonces, ¿cuál es la mejor práctica cuando una instalación autoalojada estaba utilizando un complemento modificado para restaurar las características del complemento modificado?
[quote=“pfaffman, post:2, topic:394718”]Lo mejor que puedes hacer es escribir un plugin que anule el plugin.
[/quote]
¿Escribir un plugin completamente nuevo? Eso parece excesivo.
[quote=“pfaffman, post:2, topic:394718”]Otra cosa que puedes hacer es, en la línea anterior a clonar tu bifurcación (fork), hacer un “rm -rf” del plugin fusionado.
[/quote]
Esta es probablemente la respuesta.
[quote=“pfaffman, post:2, topic:394718”]Así que haz eso en tu nuevo plugin en lugar de bifurcar el principal. No habrá un hook para hacer eso.
[/quote]
Realmente no entiendo nada de esto. Quería la funcionalidad del plugin existente con la adición de poder indicarle que envíe por pipe las publicaciones marcadas al cliente de chat, en mi caso Discord. ¿Estás sugiriendo de nuevo que escriba, desde cero, un plugin completamente nuevo que duplique gran parte de la funcionalidad del plugin existente y añada la nueva característica que quería? De nuevo, parece excesivo.
Hasta cierto punto, puedes reemplazar/extender la lógica en clases existentes. Esta podría ser una opción para extender el plugin incluido. Escribirías un nuevo plugin que simplemente añada la lógica modificada. Usando module prepend (Ruby Modules: include vs extend vs prepend - DEV Community).
enabled_site_setting :myoverridingplugin_enabled
module ::MyOverridingPlugin
PLUGIN_NAME = "my-overriding-plugin"
class Engine < ::Rails::Engine
engine_name MyOverridingPlugin::PLUGIN_NAME
isolate_namespace MyOverridingPlugin
end
module SomeClassOverrides
def overriding_method(foo, bar)
if foo == "something"
# haz algo personalizado
else
# esto llamará a la lógica original
super(f00, bar)
end
end
end
end
after_initialize do
SomeClass.prepend(MyOverridingPlugin::SomeClassOverrides)
end
Usé este constructor para limitar algunos controladores bajo ciertas condiciones.
Entiendo, y he encontrado que esta es una de las complicaciones técnicas más impactantes de “incluir complementos con el núcleo” también. Teníamos algunos complementos bifurcados y era muy complicado hacer que funcionaran sin eliminar el complemento incluido.
No creo que Jay esté sugiriendo eso. Un complemento también puede anular partes muy específicas de otro complemento.
El mejor enfoque sería convencer al equipo de que su código merece ser fusionado con el complemento oficial. Eso funcionará si su modificación es lo suficientemente genérica o flexible. Veo que ya ha hecho una bifurcación y sus cambios/adiciones son bastante limpios. Quizás la cadena “Flagged” codificada podría estar en un archivo de traducción y si hace que :flagged sea falso por defecto, no tendrá que modificar el controlador de eventos original con un parámetro adicional, pero aparte de eso, parece valioso. Si yo fuera usted, lo pondría al día, abriría un PR y discutiría esto en el tema del complemento.
Si esa vía falla, podría simplemente crear un complemento que anule esas tres funciones que cambió y agregue el manejador on(:reviewable_created).
El propósito de los plugins es que no tengas que bifurcar Discourse. No es excesivo, es la razón por la que existen los plugins.
No. Tu plugin simplemente añadirá la nueva característica para enviar publicaciones marcadas a Discord, y llamará al código existente para hacerlo. Probablemente sean diez líneas de código y no requerirá que fusiones cambios principales en tu plugin. EDICIÓN: Como sugirieron las últimas dos publicaciones que no leí antes de responder.
