Corré du -sh node_modules en dos proyectos: uno chico, con quince dependencias, y un monorepo con cuatro apps que comparten paquetes internos. En el primero, no vas a notar diferencia entre npm y pnpm. En el segundo, si seguís con npm, vas a tener la misma copia de React, TypeScript y las mismas devDependencies repetidas cuatro veces en disco — una por cada paquete del workspace que las declara.
Ese es el problema real. No es "pnpm es más rápido" en abstracto. Es que el ahorro de espacio y tiempo depende de cuánta duplicación tenía tu instalación original, y esa duplicación crece con la cantidad de paquetes del monorepo, no con la cantidad de dependencias totales.
Mi tesis: pnpm gana en monorepos y en CI por el modelo de symlinks, pero npm sigue siendo la opción sin fricción para proyectos chicos donde la curva de aprendizaje no vale la pena. No es una preferencia estética. Es una cuenta que cambia según el tamaño del repo.
Diferencia entre npm y pnpm: qué guarda cada uno en disco
npm instala cada dependencia como una copia física dentro de node_modules. Si tenés cuatro paquetes en un workspace y los cuatro dependen de lodash@4.17.21, npm — salvo con hoisting agresivo que trae sus propios problemas de fantom dependencies — puede terminar con esa misma versión copiada en más de un lugar del árbol.
