Los espacios de trabajo son una nueva forma de configuración de su arquitectura del paquete que está disponible de forma predeterminada a partir de Yarn 1.0. Permite instalar varios paquetes de tal manera que sólo necesita ejecutar una vez yarn install para instalarlos todos en un solo paso.

¿Por qué querrias hacer esto?

  • Se pueden vincular juntas sus dependencias, lo que significa que sus espacios de trabajo pueden depender el uno del otro y al mismo tiempo utilizar siempre el código más actualizado disponible. Esto es también un mecanismo mejor que el yarn link ya que sólo afecta a su árbol del espacio de trabajo en lugar de todo su sistema.

  • Todas las dependencias de su proyecto, se instalarán dando a Yarn más latitud para optimizarlo mejor.

  • Yarn utilizará un lockfile sola en lugar de uno diferente para cada proyecto, lo que significa menos conflictos y más fácil Comentarios.

¿Com usarlo?

Agregue lo siguiente en un archivo de package.json. A partir de ahora en adelante, llamaremos a este directorio “raíz de espacio de trabajo”:

package.json

{
  "private": true,
  "workspaces": ["workspace-a", "workspace-b"]
}

Tenga en cuenta que el private: true es necesario! Espacios de trabajo, no pretenden ser publicado, así que hemos añadido esta medida de seguridad para asegurarse de que no accidentalmente puede exponerlos.

Después de haber creado este archivo, crear dos subcarpetas nuevo llamadas <workspace-a y workspace-b. En cada uno de ellos, crear otro archivo package.json con el siguiente contenido:

espacio de trabajo-a/package.json:

{
  "name": "workspace-a",
  "version": "1.0.0",

  "dependencies": {
    "cross-env": "5.0.5"
  }
}

espacio de trabajo-b/package.json:

{
  "name": "workspace-b",
  "version": "1.0.0",

  "dependencies": {
    "cross-env": "5.0.5",
    "workspace-a": "1.0.0"
  }
}

A continuación, ejecute yarn install en algún lugar, idealmente dentro de la raíz del espacio de trabajo. Si todo funciona bien, ahora debería tener una jerarquía de archivos similares:

/package.json
/yarn.lock

/node_modules
/node_modules/cross-env
/node_modules/workspace-a -> /workspace-a

/workspace-a/package.json
/workspace-b/package.json

¡Y eso es todo! Que requieren workspace-a desde un archivo ubicado en el workspace-b ahora utilizará el código exacto ubicado actualmente dentro de su proyecto en lugar de lo que está publicado en Github, y el paquete de la cross-env ha sido deduped correctamente y poner en la raíz de su proyecto para ser utilizado tanto por workspace-a y workspace-b.

¿Cómo se compara a Lerna?

Los espacios de trabajo de Yarn son las primitivas de bajo nivel que utilizan herramientas como Lerna puede (and do!)) usar. Nunca tratarán de apoyar la función de alto nivel que ofrece Lerna, pero por aplicación de la lógica de la base de la resolución y enlazan a pasos dentro de Yarn sí mismo esperamos habilitar nuevos usos y mejorar el rendimiento.

Consejos & Trucos

  • El campo de workspaces es una matriz que contiene los paths a cada área de trabajo. Ya que sería tedioso hacer un seguimiento de cada uno de ellos, ¡este campo también acepta patrones glob! Por ejemplo, todos sus paquetes a través de una sola referencia a Babel packages/*directiva.

  • Espacios de trabajo son lo suficientemente estables como para ser utilizado en aplicaciones a gran escala y no deberían cambiar nada a la forma en que trabaja la instalacion regular, pero si crees que están rompiendo algo, puede deshabilitar agregando la línea siguiente en el archivo Yarnrc:

      workspaces-experimental false
    

Limitaciones & Advertencias

  • El diseño del paquete será diferente entre su espacio de trabajo y lo que sus usuarios conseguirán (el espacio de trabajo dependencias se alzaron más alto en la jerarquía de filesystem). Suposiciones acerca de este diseño ya eran peligrosa ya que no está estandarizado el proceso de levantamiento, así que en teoría no hay nada nuevo aquí.

  • En el ejemplo anterior, si el workspace-b depende de una versión diferente que el referenciado en workspace-a de package.json, la dependencia será instalada desde Github en lugar de ligado de su sistema de archivos local. Esto es porque algunos paquetes de hecho necesitan utilizar las versiones anteriores con el fin de construir los nuevos (Babel es uno de ellos).

  • Be careful when publishing packages in a workspace. If you are preparing your next release and you decided to use a new dependency but forgot to declare it in the package.json file, your tests might still pass locally if another package already downloaded that dependency into the workspace root. However, it will be broken for consumers that pull it from a registry, since the dependency list is now incomplete so they have no way to download the new dependency. Currently there is no way to throw a warning in this scenario.

  • Workspaces must be children of the workspace root in terms of folder hierarchy. You cannot and must not reference a workspace that is located outside of this filesystem hierarchy.

  • Nested workspaces are not supported at this time.