Regras de independência

Prefixos de tabela, comportamento de desinstalação, módulos-filhos e os estados de compatibilidade, em detalhe.

O kernel impõe estas regras. Elas existem para que um comprador possa instalar, desativar e remover qualquer módulo sem nunca colocar o core em risco.

1. Suas tabelas, e só suas tabelas#

Toda tabela que suas migrações criam tem o prefixo mod_<slug>_, com hífens virando underscores. Para um módulo com slug members-plus, isso é mod_membersplus_ ou mod_members_plus_ dependendo do slug que você escolheu, e isso é verificado no momento da instalação.

Ler dado do core é permitido. Escritas estruturais em qualquer coisa fora do seu prefixo não são, e um pacote cujas migrações alcançam fora dele é recusado.

2. Desinstalar remove só o seu módulo e nada mais#

onUninstall(bool $purge) apaga suas tabelas e limpa seus registros de migração. O core não é tocado, então reinstalar começa do zero.

Desativar é a operação reversível: nada é excluído e o módulo volta exatamente como estava. Garanta que onDisable() não esteja fazendo nenhuma limpeza que onEnable() não consiga desfazer.

3. Nenhuma chave estrangeira entre módulos#

Nunca aponte uma chave estrangeira para a tabela de outro módulo. Aquele módulo pode ser desinstalado enquanto o seu está rodando, e uma restrição pendurada derrubaria o site inteiro.

Use uma referência polimórfica com um alias em string, e resolva através de uma guarda.

4. Arquivos de idioma próprios#

Código

modules/<slug>/resources/lang/en/<file>.php

Carregados sob um namespace e referenciados como slug::file.key. Nada seu entra nos arquivos de idioma do core, e toda string é escrita em inglês.

5. A falha é isolada#

O boot é resiliente: um módulo que estoura é ignorado e a requisição continua. Não conte com isso como tratamento de erro, mas conte com isso pela garantia que dá aos seus compradores.

6. Módulos-filhos#

parent: "<slug>" declara que o seu módulo estende outro módulo em vez do core.

Um filho exige o pai instalado e ativo.
Desativar o pai desativa os filhos dele em cascata.
Desinstalar um pai é bloqueado enquanto um filho estiver instalado.
Filhos são listados indentados sob o pai no painel.

Os gateways de pagamento são o exemplo canônico: cada um é filho de payments e registra o próprio driver só enquanto o pai está ativo.

7. Estados de compatibilidade#

Estado	Gatilho	Efeito
Atualizado	`tested_up_to` está no nível do core rodando ou acima	Normal
Desatualizado	`tested_up_to` está abaixo do core rodando	Aviso âmbar, continua funcionando
Incompatível	Uma entrada de `requires` não é mais satisfeita	Desativado no boot, não pode ser ativado até ser atualizado

Mantenha tested_up_to honesto. É o que diz a um comprador se deve esperar problema.

8. Configurações próprias#

Um módulo pode ter as próprias telas de configuração, independentes das do core. Declare o nome da rota em settings no manifesto e a lista de módulos mostra o atalho enquanto o módulo está ativo.

Checklist#

Tabelas prefixadas e removidas na desinstalação.
Nenhuma chave estrangeira para outro módulo.
Toda string nos seus próprios arquivos de idioma, escrita em inglês.
Toda chamada entre módulos atrás de class_exists ou Route::has.
Assets compilados no pacote, nenhum build no host do comprador.
Nenhum script inline em lugar nenhum.