empaqueter un plugin Discourse en tant que gem

Wiki de la communauté Développeurs
,
1

Pavilion a commencé à empaqueter certains plugins Discourse sous forme de gems ruby, en commençant par notre client d’abonnement.

Notre client d’abonnement est toujours un plugin séparé qui charge maintenant cette gem, mais son backend est maintenant entièrement empaqueté en tant que gem et le plugin séparé sera bientôt complètement déprécié. Voici un petit guide sur la façon de faire de même avec vos plugins qui sont plus adaptés pour être des gems.

Comment travailler avec des gems

Tout d’abord, vous devez comprendre comment travailler avec des gems ruby. Si vous n’avez jamais créé de gem auparavant, je vous recommande de créer votre propre gem standard isolément avant de vous attaquer à un plugin Discourse en tant que gem. Je recommande ce guide :

Comment les plugins injectent du code dans Discourse

La façon dont une gem de plugin Discourse injecte du code dans Discourse est exactement la même que celle d’un plugin standard. La seule différence est l’empaquetage. Donc, pour travailler avec un plugin en tant que gem, vous devrez également comprendre comment un plugin standard injecte du code dans Discourse. Il y a essentiellement deux choses à comprendre ici :

  1. Un plugin Discourse est un moteur Rails. Vous en êtes probablement déjà conscient, mais vous devrez vraiment comprendre ce que cela signifie. Je vous recommande de parcourir ce guide sur les moteurs Rails. Par exemple, vous devrez comprendre pourquoi une grande partie du code du fichier plugin.rb d’un plugin Discourse est encapsulée dans un rappel after_initialize.

  2. Comment fonctionne le processus d’initialisation de Discourse. Il n’y a vraiment qu’un seul fichier à lire et à comprendre ici, à savoir le fichier discourse/discourse/config/application.rb. C’est là que la plupart du code Rails est chargé, que tout le code du plugin est chargé et que les plugins sont initialisés. Parcourez ce fichier en profondeur et comprenez où et comment les fichiers de plugin sont requis, puis initialisés.

Comment fonctionne un plugin Discourse en tant que gem

Pour tout rassembler, vous devrez alors comprendre comment les deux sujets ci-dessus sont synthétisés dans une gem de plugin Discourse. Notez en particulier ce qui suit :

  1. Dans une gem de plugin Discourse, le fichier engine.rb joue un rôle similaire à celui du fichier plugin.rb, avec quelques différences de configuration. Consultez le fichier engine.rb de la gem du client d’abonnement et comparez-le à un fichier plugin.rb standard.

  2. Dans une gem de plugin Discourse, vous devez simuler discourse/discourse dans vos tests rspec afin de tester correctement la gem. Vous n’avez pas besoin de simuler l’ensemble de l’application Discourse, juste les parties sur lesquelles vous effectuez des tests. Vous le faites en créant une application Rails squelettique avec les classes et les points d’accès Discourse spécifiques dont vous avez besoin et en la chargeant comme support rspec. Voir l’application Discourse simulée de la gem du client d’abonnement, et où elle est chargée dans le rails_helper.rb de spec.

Comment charger une gem locale dans un plugin Discourse

Pour charger votre version locale d’une gem dans un plugin Discourse lorsque vous travaillez avec ce plugin et cette gem en développement, vous devez faire ce qui suit :

Créez un lien symbolique de votre dossier de gem vers le dossier de gem du plugin concerné. Par exemple, pour travailler avec ma version locale de la gem discourse_subscription_client dans le plugin discourse-subscription-client, je fais ce qui suit :

ln -s /Users/angus/discourse/gems/discourse_subscription_client /Users/angus/discourse/discourse/plugins/discourse-subscription-client/gems/3.2.1/gems

Ensuite, modifiez le nom du dossier de gem lié symboliquement dans le plugin pour utiliser le même modèle de nom qu’un dossier de gem standard, par exemple :

discourse_subscription_client-0.1.0.pre11

Maintenant, lorsque votre plugin chargera votre gem de plugin Discourse, il chargera votre version locale au lieu de celle sur rubygems.

Si vous avez des questions ou si vous êtes bloqué, postez ici et je vous aiderai.

14 « J'aime »
2

Il semble que cette approche ne permette pas de couvrir les éléments du thème Discourse dans un plugin ? Peut-être qu’un meilleur titre serait « Empaqueter un moteur Rails spécifique à Discourse sous forme de gem »

1 « J'aime »
3

C’est exact, vous devez gérer séparément les éléments du framework JS front-end.

Bien que techniquement exact, je ne pense pas que ce titre soit meilleur, car il pourrait dissuader certaines personnes de lire le sujet : la plupart des personnes qui écrivent des plugins ne les identifieraient pas comme des « moteurs Rails spécifiques à Discourse ».

En fait, je sépare plus régulièrement mon code en plugins back-end et composants thématiques front-end maintenant, afin de pouvoir itérer très rapidement sur les éléments front-end lors des déploiements dans les environnements de staging et de production.

3 « J'aime »
4

Je suis d’accord avec cela, bien que ce document ne puisse être utile qu’à certains développeurs avancés, il devrait couvrir tout le monde.

Et merci d’avoir partagé cela.

1 « J'aime »
5

Je suis d’accord, c’est un sujet avancé.