A nova edição do Technology Radar da ThoughtWorks listou pela primeira vez um projeto em PHP e foi o Composer. Entretanto, eles listaram o composer no quadrante Trial (tentar, experimentar), enquanto eu acredito que deveria ter sido listado no quadrante Adopt (adotar). E eu quero dizer a você o por quê.

Primeiro, é importante ressaltar que o Technology Radar não é uma lista das tecnologias aprovadas pela ThoughtWorks. É uma compilação de tecnologias baseado apenas em opiniões e experiência de técnicos seniores. É uma publicação repleta de insights ao qual recomendo a leitura.

Quando eu penso no nome “ThoughtWorks”, PHP não me vem à mente. Eu não lembro de nenhuma publicação deles mencionando a linguagem. Com isto em mente, fiquei surpreso ao ver que o Composer havia sido listado. Talvez essa falta de intimidade com o ecossistema PHP seja a razão do porque o Composer foi posicionado no quadrante Trial.

O Composer foi lançado no final de 2011. Até então, instalar dependências em projetos PHP era limitado a duas escolhas: funcionalidades de sistemas de versão de controle como o SVN externals ou submodules Git ou, se disponível, através do instalador PEAR.

Ainda naquele ano, o Symfony2 tinha sido lançado em julho, empurrando o ecossistema PHP. Uma onda de bibliotecas e ferramentas haviam sido lançadas, renovando o interesse na linguagem. Composer, lançado meses depois, era a ferramenta que precisávamos para nos beneficiar facilmente dessas novas bibliotecas e ferramentas.

Em algumas semanas, 227 pacotes estavam listados no Packagist (o principal repositório de pacotes do Composer) enquanto o repositório PEAR tinha 592 pacotes. O que foi impressionante foi o fato que esses pacotes eram para o PHP 5.3+ enquanto que no PEAR apenas 192 pacotes eram PHP 5+. O impacto talvez tenha sido mais rápido do que Jordi Boggiano (um dos desenvolvedores líderes do Composer) previu.

Hoje, 45 mil pacotes estão registrados no Packagist. Rubygems, que remonta a 2003, tem 93 mil gems. Brechas de segurança foram discutidas, corrigidas e alternativas foram propostas. Ferramentas adicionais lançadas por desenvolvedores da comunidade ajudam a garantir maior segurança. A boa documentação provê um ponto de partida seguro e sempre tem alguém ajudando você a usá-lo da forma correta.

Por último e não menos importante, milhares de organizações estão usando o Composer para gerenciar dependências. Milhões de execuções em ambientes de Integração Contínua aconteceram além de outras milhões de milhões em ambientes de desenvolvedores. Como não recomendar uma ferramenta que é a solução de-facto na caixa de ferramentas do ecossistema?

Não faça com que as pessoas riam de você num bar ao dizê-las que você não usa o Composer.