Espacio de trabajo
pnpm tiene soporte incorporado para monorepos (también conocidos como repositorios de paquetes múltiples, repositorios de proyectos múltiples o repositorios monolíticos). Puede crear un espacio de trabajo para unir varios proyectos dentro de un único repositorio.
Un espacio de trabajo debe tener un archivo pnpm-workspace.yaml en su raíz. Un espacio de trabajo también puede tener un .npmrc en su raíz.
Si está indagando en la administración de monorepos, puede también darle un vistazo a Bit. Bit usa pnpm en su interior, pero automatiza muchas de las cosas que actualmente se hacen manualmente en un espacio de trabajo tradicional administrado por pnpm/npm/Yarn. Existe un artículo acerca de bit install que habla sobre eso: Painless Monorepo Dependency Management with Bit.
Protocolo de espacio de trabajo (workspace:)
If link-workspace-packages is set to true, pnpm will link packages from the workspace if the available packages match the declared ranges. Por ejemplo, foo@1.0.0 está vinculado a bar si bar tiene "foo": "^1.0.0" en sus dependencias y foo@1.0.0 está en el espacio de trabajo. Sin embargo, si bar tiene "foo": "2.0.0" en las dependencias y foo@2.0.0 no está en el espacio de trabajo, entonces foo@2.0.0 se instalará desde el registro. Este comportamiento presenta algo de incertidumbre.
Afortunadamente, pnpm admite el protocolo workspace:. Cuando se usa este protocolo, pnpm se negará a resolver cualquier cosa que no sea un paquete de espacio de trabajo local. Por lo tanto, si establece "foo": "workspace: 2.0.0", esta vez la instalación fallará porque " foo@2.0.0 " no está presente en el espacio de trabajo.
Este protocolo es especialmente útil cuando la opción link-workspace-packages está en false. En ese caso, pnpm solo vinculará paquetes desde el espacio de trabajo si se usa el protocolo workspace:.
Referenciando paquetes de espacio de trabajo a través de alias
Supongamos que tiene un paquete en el espacio de trabajo llamado foo. Por lo general, lo referenciaría como "foo": "workspace:*".
Si desea utilizar un alias diferente, la siguiente sintaxis también funcionará: "bar": "workspace:foo@*".
Antes de publicar, los alias se convierten en dependencias con alias regulares. El ejemplo anterior se convertirá en: "bar": "npm:foo@1.0.0".
Referenciando paquetes de espacio de trabajo a través de su ruta relativa
En un espacio de trabajo con 2 paquetes:
+ packages
+ foo
+ bar
bar puede tener foo en sus dependencias declaradas como "foo": "workspace:../foo". Antes de publicar, estas especificaciones se convierten a las especificaciones de versión regular soportadas por todos los gestores de paquetes.
Publicando paquetes del espacio de trabajo
Cuando un paquete de espacio de trabajo se empaqueta en un archivo (ya sea a través de pnpm pack o uno de los comandos de publicación como pnpm publique), reemplazamos dinámicamente cualquier dependencia de workspace: por:
- La versión correspondiente en el espacio de trabajo de destino (si usa
workspace:*,workspace:~oworkspace:^) - El rango de versión semántica asociado (para cualquier otro tipo de rango)
Así, por ejemplo, si tenemos foo, bar, qar, zoo en el espacio de trabajo y todos están en la versión 1.5.0, lo siguiente:
{
"dependencies": {
"foo": "workspace:*",
"bar": "workspace:~",
"qar": "workspace:^",
"zoo": "workspace:^1.5.0"
}
}
Será transformado en:
{
"dependencies": {
"foo": "1.5.0",
"bar": "~1.5.0",
"qar": "^1.5.0",
"zoo": "^1.5.0"
}
}
Esta característica le permite depender de sus paquetes espacios de trabajo locales mientras aún puede publicar los paquetes resultantes en el registro remoto sin necesidad de pasos intermedios de publicación. Sus consumidores podrán utilizar sus espacios de trabajo publicados como cualquier otro paquete, beneficiándose de las garantías que ofrece el versionado semántico.
Flujo de trabajo de lanzamiento
Versionar paquetes dentro de un espacio de trabajo es una tarea compleja y pnpm actualmente no proporciona una solución integrada para ello. Sin embargo, existen 2 herramientas bien probadas que manejan el control de versiones y admiten pnpm:
Para saber cómo configurar un repositorio usando Rush, lea esta página.
Para usar Changesets con pnpm, lea esta guía.
Resolución de problemas
pnpm no puede garantizar que los scripts se ejecuten en orden topológico si existen ciclos entre las dependencias del espacio de trabajo. Si pnpm detecta dependencias cíclicas durante la instalación, generará una advertencia. Si pnpm puede averiguar qué dependencias están causando los ciclos, también las mostrará.
Si ve el mensaje There are cyclic workspace dependencies, inspeccione las dependencias de espacio de trabajo declaradas en dependencies, optionalDependencies y devDependencies.
Ejemplos de uso
Estos son algunos de los proyectos de código abierto más populares que utilizan la función de espacio de trabajo de pnpm:
