phpm: Uma Camada 'pnpm' com Rust para o Gerenciamento de Dependências do Composer

Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje a gente vai falar de um assunto que mexe com o calo de todo desenvolvedor PHP: o gerenciamento de dependências. Se você já ficou ali olhando para a tela, esperando aquele `composer install` terminar enquanto tomava o seu terceiro café do dia, ou se já viu o seu HD pedindo socorro por causa de dez pastas `vendor` gigantescas em projetos diferentes... cara, este episódio é para você. Apresentadora: Hoje eu recebo aqui no Allur o Rafael Costa. O Rafa é desenvolvedor sênior, entusiasta de Rust e um cara que está sempre de olho em como otimizar o fluxo de trabalho no ecossistema PHP. Rafa, seja muito bem-vindo ao Allur! Valeu demais por aceitar o convite. Convidado: Valeu, Juliana! O prazer é todo meu. Sou fã do podcast e falar de PHP com Rust é tipo unir o útil ao agradável, né? É um tema que eu sou apaixonado porque resolve problemas reais que a gente enfrenta todo santo dia nas empresas. Apresentadora: Com certeza! E vamos começar direto no ponto sensível: o Composer. Ele é o padrão de fato, a gente ama o Composer, mas ele tem seus momentos de lentidão, né? Explica pra gente: o que é o phpm e como ele surgiu com essa proposta de "revolucionar" o que o Composer já faz? Convidado: Pois é, Ju. O Composer é incrível, ele amadureceu o PHP de um jeito absurdo. Mas o problema é que o modelo tradicional dele é "copiar e colar". Você tem 10 projetos Laravel na sua máquina, você vai ter 10 cópias físicas dos mesmos pacotes do Symfony, do Laravel Framework, do Ignition... isso consome um espaço bizarro. O phpm, que foi apresentado recentemente pelo Lemos lá no TabNews, chega com uma pegada diferente. Ele é um *wrapper* feito em Rust. Ou seja, ele não substitui o Composer, ele "veste" o Composer por cima. Ele usa a inteligência do Composer para resolver as dependências, mas na hora de baixar e salvar no disco, ele usa a lógica do pnpm. Apresentadora: E aí entra a tal da "filosofia pnpm", né? Eu confesso que quando ouvi falar de Rust no gerenciamento de pacotes PHP eu tomei um susto, mas faz todo o sentido pela velocidade. Como funciona essa mágica de economizar espaço que você mencionou? Convidado: Cara, a mágica tem dois pilares: o Armazenamento Endereçável por Conteúdo e os Symlinks. Traduzindo do "tecniquês": o phpm tem um cache global na sua máquina. Quando você baixa um pacote, ele gera um hash, um código único baseado no conteúdo daquele arquivo. Se você tiver 50 projetos usando a mesma versão daquele pacote, o phpm guarda só UMA cópia física no seu disco. Apresentadora: Caramba, uma cópia só? Mas e como o projeto enxerga isso na pasta `vendor`? Convidado: Aí que tá a sacada! Em vez de copiar os arquivos, ele cria *symlinks* — os famosos links simbólicos. Na sua pasta `vendor/`, vai parecer que os arquivos estão lá, o PHP vai ler normal, o Autoload vai funcionar perfeitamente. Mas, na verdade, aqueles arquivos são apenas "ponteiros" para aquela cópia única no cache global. É por isso que é tão rápido. O Rust entra aí para gerenciar esse I/O de arquivos, essa criação de links e a checagem de hashes com uma velocidade que o PHP, por ser uma linguagem de script, teria muito mais dificuldade de fazer com a mesma performance. Apresentadora: Massa! Eu fico imaginando o impacto disso em times que usam Monorepos. Sabe quando você tem aquele repositório gigante com vários pacotes internos e cada um precisa de suas dependências? Deve ser um ganho de tempo absurdo, né? Convidado: Total! Em monorepos é onde o phpm brilha mais forte. Imagina um pipeline de CI/CD. Toda vez que você roda um build, o Composer tem que baixar tudo ou gerenciar um cache que às vezes é pesado. Com o phpm, se o servidor de CI já tem aquelas dependências no cache global, a "instalação" é praticamente instantânea, porque é só criar link simbólico. É papo de reduzir o tempo de build de minutos para segundos em alguns casos. Fora que evita aquela zona de ter versões duplicadas gastando recursos à toa. Apresentadora: Nossa, sensacional. Agora, uma dúvida que muita gente deve ter: eu preciso mudar meu `composer.json`? Como que eu começo a usar isso sem quebrar o que já tenho? Convidado: Essa é a melhor parte, Ju. Você não muda nada no seu projeto. O phpm lê o seu `composer.json` e o seu `composer.lock` original. Ele delega para o Composer a parte difícil, que é decidir: "Ah, o pacote A precisa da versão X do pacote B". Depois que o Composer decide isso, o phpm assume o volante e fala: "Beleza, agora deixa que eu guardo e ligo esses arquivos do meu jeito ultra-rápido". Para instalar, se você tiver o Rust instalado, é só dar um `cargo install phpm`. Depois, em vez de digitar `composer install`, você digita `phpm install`. Simples assim. Apresentadora: Tipo assim, é um "drop-in replacement" no terminal, mas que mantém a base que a gente já confia. Achei muito massa essa abordagem de não tentar reinventar a roda da resolução de dependências, mas sim otimizar a parte chata que é o armazenamento. Mas vem cá, o projeto ainda é novo, né? O que você tem visto sobre a estabilidade e o futuro dele? Convidado: Com certeza, ele está em desenvolvimento ativo. É importante dizer que é um projeto que está buscando feedback. O Lemos e a galera que está contribuindo no GitHub estão focados em pegar esses casos de borda. Eu não diria para você chegar amanhã e mudar o processo de deploy da sua empresa inteira sem testar, mas para o ambiente de desenvolvimento local? Cara, já vale muito a pena. O futuro disso é muito promissor porque mostra que o ecossistema PHP está parando de ser "fechado em si mesmo" e começando a usar ferramentas de sistema como Rust para elevar o nível das nossas ferramentas. Apresentadora: É o que eu sempre digo, né? A gente tem que usar a melhor ferramenta para o trabalho. Se o Rust é animal para lidar com arquivos e concorrência, por que não trazer isso para o mundo PHP? Rafa, teve algum desafio que você sentiu ou alguma curiosidade quando começou a brincar com o phpm? Convidado: Acho que o maior "estalo" foi perceber como a gente se acostumou com o desperdício de espaço. Quando eu rodei o phpm num projeto e vi que a pasta `vendor` virtual ocupava quase nada de espaço real, eu pensei: "Gente, como a gente não fez isso antes?". Um desafio técnico que a galera às vezes encontra é a questão de permissões de symlinks em alguns ambientes Windows, mas o Rust lida bem com isso na maioria das vezes. É mais uma questão de mudar o mindset de como a gente enxerga as dependências. Elas não precisam estar "presas" dentro da pasta do projeto, elas podem ser um recurso compartilhado do sistema. Apresentadora: Perfeito! Olha, o papo está incrível, mas a gente já está chegando no fim. Rafa, para quem ouviu a gente e ficou com aquela coceira de "preciso testar isso agora", qual o seu conselho final? Convidado: Meu conselho é: teste. Instala o Rust, dá um `cargo install phpm` e roda num projeto paralelo. Sente a velocidade. Se você trabalha com microserviços ou monorepos, você vai sentir a diferença na hora. E o mais importante: se encontrar um bug ou tiver uma ideia, contribui lá no GitHub. O projeto é open source e a comunidade PHP é o que faz essas ferramentas ficarem maduras de verdade. Apresentadora: Show de bola! Rafael, valeu demais pela aula de hoje. Foi um prazer ter você aqui no Allur. Convidado: Valeu, Juliana! Até a próxima, pessoal! Apresentadora: E para você que acompanhou a gente, as notas do episódio com o link para o repositório do phpm e as instruções de instalação estão no nosso site. Se você quer economizar espaço no disco e parar de sofrer com o tempo de instalação, o phpm parece ser um caminho sem volta.