Empacote um plugin Discourse como uma gem

Wiki da comunidade Desenvolvedores
,
1

O Pavilion começou a empacotar alguns plugins do Discourse como gems ruby, começando com nosso cliente de assinatura.

Nosso cliente de assinatura ainda é um plugin separado que agora carrega este gem, mas seu backend agora está totalmente empacotado como um gem e o plugin separado será em breve descontinuado. Este é um pequeno guia sobre como fazer o mesmo com seus plugins que são mais adequados para serem gems.

Como trabalhar com gems

Primeiro, você precisa entender como trabalhar com gems ruby. Se você nunca criou um gem antes, recomendo criar seu próprio gem padrão isoladamente antes de tentar trabalhar com um plugin do Discourse como um gem. Eu recomendo este guia

Como os plugins injetam código no Discourse

A maneira como um gem de plugin do Discourse injeta código no Discourse é exatamente a mesma maneira que um plugin padrão faz. A única diferença é o empacotamento. Portanto, para trabalhar com um plugin como um gem, você também precisará entender como um plugin padrão injeta código no Discourse. Existem essencialmente duas coisas para entender aqui

  1. Um plugin do Discourse é um motor rails. Você provavelmente já está ciente disso, mas precisará realmente entender o que isso significa. Recomendo passar por este guia sobre motores Rails. Por exemplo, você precisará entender por que muito código no arquivo plugin.rb de um plugin do Discourse está envolvido em um callback after_initialize.

  2. Como funciona o processo de inicialização do Discourse. Há realmente apenas um arquivo para ler e entender aqui, a saber, o arquivo discourse/discourse/config/application.rb. É aí que a maior parte do código rails é carregada, onde todo o código do plugin é carregado e onde os plugins são inicializados. Percorra esse arquivo em profundidade e entenda onde e como os arquivos do plugin são requeridos e, em seguida, inicializados.

Como funciona um plugin do Discourse como gem

Para juntar tudo, você precisará entender como os dois tópicos acima são sintetizados em um gem de plugin do Discourse. Em particular, observe o seguinte:

  1. Em um gem de plugin do Discourse, o arquivo engine.rb desempenha um papel semelhante ao arquivo plugin.rb, com algumas diferenças de configuração. Confira o arquivo subscription client gem engine.rb e compare-o com um arquivo plugin.rb padrão.

  2. Em um gem de plugin do Discourse, você precisa simular discourse/discourse em seus testes rspec para testar adequadamente o gem. Você não precisa simular todo o aplicativo Discourse, apenas as partes contra as quais você está testando. Você faz isso criando um aplicativo rails esqueleto com as classes e endpoints específicos do Discourse que você precisa e carregando-o como um suporte rspec. Veja o app Discourse simulado do gem do cliente de assinatura e onde ele é carregado no rails_helper.rb do spec.

Como carregar um gem local em um plugin do Discourse

Para carregar sua versão local de um gem em um plugin do Discourse ao trabalhar com esse plugin e gem em desenvolvimento, você precisa fazer o seguinte.

Crie um link simbólico para sua pasta de gem na pasta de gem do plugin relevante. Por exemplo, para trabalhar com minha versão local do gem discourse_subscription_client no plugin discourse-subscription-client, eu faço o seguinte

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

Em seguida, altere a pasta de gem com link simbólico no plugin para usar o mesmo padrão de nome de uma pasta de gem padrão, por exemplo.

discourse_subscription_client-0.1.0.pre11

Agora, quando seu plugin carregar seu gem de plugin do Discourse, ele carregará sua versão local em vez daquela no rubygems.

Se você tiver alguma dúvida ou ficar preso, poste aqui e eu o ajudarei.

14 curtidas
2

Parece que essa abordagem não é possível para cobrir qualquer coisa de tema do Discourse em um plugin? Talvez um título melhor seja “Empacotar um Rails Engine específico do Discourse como uma gem”

1 curtida
3

Isso está correto, você precisa lidar com as coisas do framework JS do front-end separadamente

Embora tecnicamente preciso, eu não concordaria que esse título seria melhor, pois isso afastaria algumas das pessoas certas de ler o Tópico: a maioria das pessoas que escrevem plugins pode não identificá-los como “Rails Engines específicos do Discourse”

Na verdade, eu separo meu código com mais frequência em plugins de back-end e componentes de tema de front-end agora, para que eu possa iterar as coisas de front-end muito rapidamente em implantações para ambientes de staging e produção.

3 curtidas
4

Concordo com isso, embora este documento possa ser útil apenas para alguns desenvolvedores avançados, ele deve abranger todas as pessoas.

E obrigado por compartilhar isso.

1 curtida
5

Concordo que é um tópico avançado.