es

Introducción

Qué hace PCPM por ti, los problemas que resuelve y cómo se relaciona con pnpm, CPM y el ecosistema NuGet.

PCPM es un gestor de paquetes direccionable por contenido para .NET, construido sobre Central Package Management. Lleva al ecosistema NuGet las partes de pnpm que de verdad mueven la aguja: un store global, hardlinks, un lockfile con hash de contenido y resolución estricta.

PCPM no inventa un nuevo formato de manifiesto. Escribe el mismo Directory.Packages.props y los mismos <PackageReference /> que ya usas. dotnet restore sigue haciendo el restore; MSBuild sigue compilando. PCPM solo cambia de dónde vienen los bytes, qué versión se fija y qué se ejecuta en CI.

Qué hace por ti, concretamente

Estas son las razones por las que la gente se pasa a PCPM. El resto de la documentación entra en detalle sobre cada una.

70–90% menos de disco en la caché de NuGet

Sin PCPM, cada (id, version) distinto se desempaqueta una vez por proyecto en ~/.nuget/packages. En un monorepo de 30 proyectos con 200 paquetes únicos, eso son ~8 GB de bytes duplicados aunque el contenido sea byte-idéntico.

Con PCPM, cada .nupkg distinto vive una sola vez en un store direccionable por contenido, enlazado con hardlinks a ~/.nuget/packages. El store no crece con el número de proyectos.

Builds reproducibles, de verdad

pcpm.lock registra la versión resuelta y el sha256 del .nupkg de cada entrada. pcpm ci es el comando para el build server: rechaza continuar si el lockfile está obsoleto, falta o tiene hashes que no coinciden con el store. Un run limpio de CI que resuelva un transitivo nuevo se convierte en fallo de build, no en regresión silenciosa.

Restauraciones limpias en CI que no son lentas

La primera install descarga el mundo. Cada install posterior — incluso en un runner limpio con caché caliente — solo trae los deltas. El paso del hardlink es solo metadatos.

Te dice quién metió qué

pcpm why <paquete> recorre el lockfile y muestra la cadena completa de dependientes que trajo <paquete> a tu build. Cuando un bump transitivo te sorprende, sabes exactamente con qué dependencia directa negociar.

Diagnostica tu CPM antes de que CI lo haga por ti

pcpm doctor ejecuta una batería de comprobaciones contra el workspace actual y sale con código distinto de cero ante problemas reales: falta de ManagePackageVersionsCentrally, versiones flotantes, Version= hardcodeado en <PackageReference />, entradas huérfanas, entradas faltantes, drift del lockfile y CVEs conocidos desde el feed de NuGet. Conéctalo a la puerta de calidad de tu build.

Audita seguridad y licencias, y entrega un SBOM

pcpm audit escanea el grafo resuelto contra avisos de vulnerabilidades y metadatos de licencia. --output <dir> escribe un SBOM CycloneDX y un informe de licencias. Tiene modo de salida JSON para pipe en CI.

Migra soluciones existentes con un comando

pcpm convert recorre una solución (con o sin CPM) y la reescribe in-place: sube cada Version= por proyecto a un <PackageVersion />, adopta un Directory.Packages.props existente si lo hay y escribe pcpm.json + pcpm.lock. --dry-run previsualiza el diff; --revert deshace un convert anterior.

Cómo funciona por dentro

PCPM es una capa fina sobre el SDK de .NET. El flujo es:

  1. pcpm install lee Directory.Packages.props y los .csproj descubiertos, y resuelve el grafo transitivo completo usando la misma librería NuGet.Versioning que usa dotnet restore — por eso el parseo de rangos, el manejo de pre-releases y la semántica de flotantes se mantienen consistentes.
  2. Cada .nupkg resuelto se descarga una vez, se hashea y se almacena bajo su hash de contenido en el store global.
  3. El paquete se enlaza con hardlinks (NTFS / APFS / ext4) desde el store hasta el layout estándar ~/.nuget/packages/<id>/<version>/.
  4. dotnet restore lee el layout estándar; nada en el lado del consumidor es custom.
  5. pcpm.lock registra la versión resuelta y el sha256 del .nupkg de cada entrada.

Los hardlinks son gratis — cero disco extra, materialización instantánea. dotnet restore ve un layout de NuGet perfectamente normal, así que toda la magia de MSBuild sigue funcionando.

Un tour de 30 segundos

# En un checkout fresco de tu proyecto .NET:
pcpm convert                     # migra una solución existente, o…
pcpm init                        # …arranca limpio en un workspace nuevo

pcpm add Serilog                 # última estable → CPM + .csproj
pcpm install                     # hidrata el store, hardlinks, dotnet restore

pcpm why Serilog                 # quién la trajo
pcpm doctor                      # chequeo de CPM + lockfile + CVEs
pcpm audit                       # vulnerabilidades + informe de licencias + SBOM
pcpm outdated                    # versiones más nuevas en el feed
pcpm ci                          # instalación estricta para CI

Sin demonio, sin servicio en segundo plano, sin migración de manifiestos.

Siguientes pasos

Editar esta página en GitHub