Caso você esteja pensando em criar um pacote em php, este guia pode ajuda-lo. Principalmente se este pacote for open source.
Para conseguir alcançar seu objetivo, recomendo que você estude alguns pontos antes de avançar:
- Git
- Composer
- PSR's (as PSR's 0, 1, 2, 4, 5 devem ser seguidas para todo pacote)
- SOLID
- KISS
- TDD (Ou ao menos saiba sobre testes automatizados)
- Semver (Versionamento semântico)
Depois de conseguir as skill's descritas a cima é hora de criar a estrutura. Não existe uma regra para a estrutura de pastas, porém neste exemplo iremos utilizar o skeleton da Liga dos Pacotes Extraordinários. Vamos a um overview sobre o skeleton:
- /src - todas as classes do pacote (Dentro desta pasta fica a seu critério como organizar suas classes em subpastas, só seja organizado)
- /testes - todos os testes do pacote
- .editorconfig - arquivo de configuração do editorconfig, este arquivo garante com que espaços inúteis sejam removidos, que a indentação seja seguida entre outras normalizações. Se você não sabe nem o básico sobre isso, recomendo a leitura.
- .gitattributes - este arquivo seta o comportamento do seu pacote caso o mesmo seja instalado via git submodules.
- .gitignore - espero que você já saiba, mais é o arquivo que seta o que será ignorado pelo git, e não será enviado ao repositório.
- .scrutinizer.yml - arquivo de configuração do scrutinizer-ci.
- .travis.yml - arquivo de configuração do scrutinizer-ci.
- .styleci.yml - arquivo de configuração do style-ci.
- CHANGELOG.md - arquivo onde você irá descrever todas as alterações que ocorreram no seu pacote, de acordo com o descrito no semver.
- CODE_OF_CONDUCT.md - descrição do código de condulta esperado dos contribuidores e utilizadores do seu projeto.
- CONTRIBUTING.md - manual de contribuição do pacote.
- ISSUE_TEMPLATE.md - modelo a ser seguido para abrir issues no pacote.
- LICENSE.md - descritivo da licença do pacote.
- PULL_REQUEST_TEMPLATE.md - modelo a ser seguido para abrir pull requests no seu pacote.
- README.md - descrição do pacote, como usar, features, todo e tudo que quem for utilizar seu pacote precisa saber.
- composer.json - arquivo de configuração do composer do seu pacote.
- phpunit.xml.dist - arquivo de configuração do phpunit, framework de testes unitários do php.
- prefill.php - este arquivo serve para iniciar a criação do seu pacote, ao roda-lo no terminal ele substitui todas as informações de sandbox por informações pertinentes ao seu projeto. Após utiliza-lo é necessário apaga-lo, este arquivo não deve estar presente no repositório do seu projeto.
Como vimos acima, existem 3 arquivos de configuração de serviços de CI (Continuous Integration | Integração Continua), sendo eles: styleci, scrutinizer e travis. Vamos a um resumo do que cada um desses caras faz:
O StyleCI validará todas as PSR's pertinentes a estilo de código, e irá informar se seu código está ou não, de acordo com as padronizações.
O Travis vai cuidar de toda a parte de testes automatizados, e vai informar se os testes do seu pacote estão passando ou não. O legal deste cara é que você pode configurar para rodar seus testes em vários ambientes diferentes como múltiplas versões do php por exemplo.
O Scrutinizer validará todo o código em busca de falhas de segurança, duplicação de código, entre outras regras de avaliação. Ele também apresentará o relatório de code coverage de seus testes, e dará uma nota de 0 a 10 para o mesmo.
Agora que você já sabe o que fazer, e onde colocar seus arquivos, é só colocar a mão na massa e desenvolver seu pacote. Para isso basta criar suas classes dentro da pasta src, e colocar os testes na pasta test. Depois disso é só apontar o autoload do seu pacote, no arquivo composer.json, para a pasta src e seu pacote está pronto para ser chamado pelo composer via namespace.
Obrigado pela força 0/