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.