By: adminPosted on

Una herramienta para gestionar proyectos JavaScript con múltiples paquetes.

  • Acerca De
  • Introducción
  • Cómo Funciona
  • Solución De Problemas
  • Comandos
  • Misc
  • Lerna.json
  • Flags

Acerca de

Dividir grandes bases de código en paquetes versionados de forma independiente es extremadamente útil para compartir código. Sin embargo, hacer cambios en muchos repositorios es complicado y difícil de rastrear, y las pruebas en los repositorios se complican muy rápido.

Para resolver estos (y muchos otros) problemas, algunos proyectos organizarán sus bases de código en repositorios de paquetes múltiples (a veces llamados monorepos). Proyectos como Babel, React, Angular, Ember, Meteor, Jest y muchos otros desarrollan todos sus paquetes dentro de un único repositorio.

Lerna es una herramienta que optimiza el flujo de trabajo en torno a la gestión de repositorios de paquetes múltiples con git y npm.

Lerna también puede reducir los requisitos de tiempo y espacio para numerosas copias de paquetes en entornos de desarrollo y construcción, normalmente un inconveniente de dividir un proyecto en muchos paquetes NPM separados. Consulte la documentación del polipasto para obtener más detalles.

¿Qué aspecto tiene un repositorio Lerna?

En realidad es muy poco. Tiene un sistema de archivos que se parece a este:

my-lerna-repo/ package.json packages/ package-1/ package.json package-2/ package.json

¿Qué puede hacer Lerna?

Los dos comandos principales en Lerna son lerna bootstrap y lerna publish.

bootstrap enlazará dependencias en el repositorio. publish ayudará a publicar cualquier paquete actualizado.

Primeros pasos

Las siguientes instrucciones son para Lerna 2.x. Recomendamos usarlo en lugar de 1.x para un nuevo proyecto Lerna. Revisa el wiki si necesitas ver el 1.x LÉAME.

Comencemos instalando Lerna globalmente con npm.

$ npm install --global lerna

A continuación crearemos un nuevo repositorio git:

$ git init lerna-repo$ cd lerna-repo

Y ahora vamos a convertirlo en un repositorio de Lerna:

$ lerna init

Tu repositorio ahora debería tener este aspecto:

lerna-repo/ packages/ package.json lerna.json

Esto creará un archivo de configuración lerna.json, así como una carpeta packages.

Cómo funciona

Lerna le permite administrar su proyecto utilizando uno de dos modos: Fijo o Independiente.

Modo fijo / bloqueado (predeterminado)

Los proyectos Lerna de modo fijo funcionan en una sola línea de versión. La versión se mantiene en el archivo lerna.json en la raíz de su proyecto bajo la clave version. Cuando ejecuta lerna publish, si un módulo se ha actualizado desde la última vez que se realizó una versión, se actualizará a la nueva versión que está lanzando. Esto significa que solo publica una nueva versión de un paquete cuando lo necesita.

Este es el modo que Babel está utilizando actualmente. Use esto si desea vincular automáticamente todas las versiones de paquetes. Un problema con este enfoque es que un cambio importante en cualquier paquete dará lugar a que todos los paquetes tengan una nueva versión principal.

Modo independiente (independent independiente)

Modo independiente Los proyectos Lerna permiten a los mantenedores incrementar las versiones de paquetes de forma independiente entre sí. Cada vez que publique, recibirá un mensaje para cada paquete que haya cambiado para especificar si se trata de un cambio de parche, menor, mayor o personalizado.El modo independiente

le permite actualizar versiones más específicas para cada paquete y tiene sentido para un grupo de componentes. Combinar este modo con algo como liberación semántica lo haría menos doloroso. (Ya hay trabajo sobre esto en atlassian / lerna-semantic-release).

La tecla version en lerna.json se ignora en modo independiente.

Solución de problemas

Si tiene algún problema mientras usa Lerna, consulte nuestro documento de solución de problemas donde puede encontrar la respuesta a su problema.

Preguntas frecuentes

Ver FAQ.md.

Comandos

init

$ lerna init

Crear un nuevo repositorio de Lerna o actualizar un repositorio existente a la versión actual de Lerna.

Lerna asume que el repositorio ya se ha inicializado con git init.

Cuando se ejecuta, este comando:

  1. Agregue lerna como devDependency en package.json si aún no existe.
  2. Cree un archivo de configuración lerna.json para almacenar el número version.

Salida de ejemplo en un nuevo repositorio de git:

$ lerna initlerna info version v2.0.0lerna info Updating package.jsonlerna info Creating lerna.jsonlerna success Initialized Lerna files

–independiente, – i

$ lerna init --independent

Este indicador indica a Lerna que utilice el modo de control de versiones independiente.

exact exacto

$ lerna init --exact

De forma predeterminada, lerna init utilizará un intervalo de corchetes al agregar o actualizar la versión local de lerna, al igual que npm install --save-dev lerna.

Para conservar lerna 1.x comportamiento de comparación «exacta», pase esta bandera. Configurará lerna.json para hacer cumplir la coincidencia exacta para todas las ejecuciones posteriores.

{ "lerna": "2.0.0", "command": { "init": { "exact": true } }, "version": "0.0.0"}

bootstrap

$ lerna bootstrap

Bootstrap los paquetes en el repositorio Lerna actual. Instala todas sus dependencias y vincula cualquier dependencia cruzada.

Cuando se ejecuta este comando:

  1. npm install todas las dependencias externas de cada paquete.
  2. Enlazar simbólicamente todos los Lerna packages que son dependencias entre sí.
  3. npm prepublish todos los paquetes bootstrap.

lerna bootstrap respeta las banderas --ignore, --scope y --include-filtered-dependencies(consulte Banderas).

Pase argumentos adicionales al cliente npm colocándolos después --:

$ lerna bootstrap -- --production --no-optional

También se puede configurar en lerna.json:

{ ... "npmClient": "yarn", "npmClientArgs": }

Cómo funciona bootstrap

Usemos babel como ejemplo.

  • babel-generator y source-map (entre otros) son dependencias de babel-core.
  • babel-core‘s package.json enumera ambos paquetes como claves en dependencies, como se muestra a continuación.
// babel-core package.json{ "name": "babel-core", ... "dependencies": { ... "babel-generator": "^6.9.0", ... "source-map": "^0.5.0" }}
  • Lerna comprueba si cada dependencia también forma parte del repositorio de Lerna.
    • En este ejemplo, babel-generator puede ser una dependencia interna, mientras que source-map siempre es una dependencia externa.
    • La versión de babel-generator en el package.json de babel-core se satisface con packages/babel-generator, pasando por una dependencia interna.
    • source-map es npm install ed (o yarn ed) como de costumbre.
  • packages/babel-core/node_modules/babel-generator enlaces simbólicos a packages/babel-generator
  • Esto permite importar directorios anidados

Notas:

  • Cuando una versión de dependencia en un paquete no es satisfecha por un paquete del mismo nombre en el repositorio, será npm install ed (o yarn ed) como de costumbre.
  • Las etiquetas Dist, como latest, no satisfacen los rangos semver.
  • Las dependencias circulares dan como resultado enlaces simbólicos circulares que pueden afectar a su editor / IDE.

Webstorm se bloquea cuando hay enlaces simbólicos circulares presentes. Para evitar esto, agregue node_modules a la lista de archivos y carpetas ignorados en Preferences | Editor | File Types | Ignored files and folders.

publicar 

$ lerna publish

Publicar paquetes en el proyecto Lerna actual. Cuando se ejecuta, este comando hace lo siguiente:

Crea una nueva versión de los paquetes que se han actualizado. Solicita una nueva versión. Crea una nueva confirmación/etiqueta de git en el proceso de publicación en npm.

Más específicamente, este comando:

  1. Ejecute el equivalente a lerna updated para determinar qué paquetes deben publicarse.
  2. Si es necesario, aumente la tecla version en lerna.json.
  3. Actualice el package.json de todos los paquetes actualizados a sus nuevas versiones.
  4. Actualice todas las dependencias de los paquetes actualizados con las nuevas versiones, especificadas con un signo de mayúsculas (^).
  5. Crea una nueva confirmación y etiqueta de git para la nueva versión.
  6. Publicar paquetes actualizados en npm.

Lerna no publicará paquetes que estén marcados como privados ("private": true en package.json).

–exacto

$ lerna publish --exact

Cuando se ejecuta con este indicador, publish especificará dependencias actualizadas en paquetes actualizados exactamente (sin puntuación), en lugar de como compatible con semver (con ^).

Para obtener más información, consulte el paquete.documentación de dependencias json.

tag npm-tag 

$ lerna publish --npm-tag=next

Cuando se ejecuta con este indicador, publish se publicará en npm con la etiqueta de dist npm dada (el valor predeterminado es latest).

Esta opción se puede usar para publicar una versión prerelease o beta.

Nota: la etiqueta latest es la que se usa cuando un usuario ejecuta npm install my-package. Para instalar una etiqueta diferente, un usuario puede ejecutar npm install [email protected].

–canary, – c

$ lerna publish --canary$ lerna publish --canary=beta

Cuando se ejecuta con este indicador, publish publica paquetes de una manera más detallada (por confirmación). Antes de publicar en npm, crea la nueva etiqueta version tomando la etiqueta version actual, colocándola en la siguiente versión menor, agregando el sufijo meta proporcionado (por defecto alpha) y añadiendo la etiqueta git sha actual (por ejemplo, 1.0.0 se convierte en 1.1.0-alpha.81e3b443).

El caso de uso previsto para este indicador es una versión por nivel de confirmación o una versión nocturna.

–confirmaciones convencionales

$ lerna publish --conventional-commits

Cuando se ejecuta con este indicador, publish utilizará la Especificación de confirmaciones convencionales para determinar el salto de versión y generar el REGISTRO de cambios

git git-remote 

$ lerna publish --git-remote upstream

Cuando se ejecuta con este indicador, publish empujará los cambios de git al control remoto especificado en lugar de origin.

skip skip-git

$ lerna publish --skip-git

Cuando se ejecuta con este indicador, publish se publicará en npm sin ejecutar ninguno de los comandos de git.

Solo publicar en npm; omita confirmar, etiquetar y empujar cambios de git (esto solo afecta a publicar).

–skip-npm

$ lerna publish --skip-npm

Cuando se ejecuta con este indicador, publish actualizará todas las versiones de paquetes package.json y las versiones de dependencias, pero en realidad no publicará los paquetes en npm.

Esto fue útil como solución para un problema de npm que ya se ha solucionado. Al publicar con cambios LÉAME, use --skip-npm y haga el final npm publish a mano para cada paquete.

Este indicador se puede combinar con --skip-git para simplemente actualizar versiones y dependencias, sin confirmar, etiquetar, empujar o publicar.

Solo actualice versiones y dependencias; no publique realmente (esto solo afecta a publicar).

–forzar la publicación 

$ lerna publish --force-publish=package-2,package-4# force publish all packages$ lerna publish --force-publish=*

Cuando se ejecuta con este indicador, publish forzará la publicación de los paquetes especificados (separados por comas) o de todos los paquetes que usen *.

Esto saltará la comprobación lerna updated de paquetes modificados y obligará a actualizar un paquete que no tenía un cambio git diff.

–sí

$ lerna publish --canary --yes# skips `Are you sure you want to publish the above changes?`

Cuando se ejecuta con este indicador, publish omitirá todas las solicitudes de confirmación. Útil en integración continua (CI) para responder automáticamente al mensaje de confirmación de publicación.

version cd-version

Cuando se ejecuta con este indicador, publish omitirá el mensaje de selección de versión (en modo independiente) y utilizará la siguiente versión semántica especificada. Aún debe usar la bandera --yes para evitar todas las indicaciones. Esto es útil cuando los sistemas de compilación necesitan publicar sin instrucciones de comandos. Funciona en modos normal e independiente.

id pre-id

version repo-version

$ lerna publish --repo-version 1.0.1# applies version and skips `Select a new version for...` prompt

Cuando se ejecuta con este indicador, publish omitirá el mensaje de selección de versión y usará la versión especificada. Útil para omitir el mensaje de entrada del usuario si ya sabe qué versión publicar.

message message, – m

Cuando se ejecuta con este indicador, publish utilizará el mensaje proporcionado al confirmar las actualizaciones de la versión para su publicación. Útil para integrar lerna en proyectos que esperan que los mensajes de confirmación se adhieran a ciertas pautas, como proyectos que usan commititizen y/o liberación semántica.

Si el mensaje contiene %s, se reemplazará con el nuevo número de versión de la versión global con el prefijo «v». Tenga en cuenta que esto solo se aplica cuando se usa el modo de control de versiones «fijo» predeterminado, ya que no hay una versión «global» cuando se usa --independent.

actualizado

$ lerna updated

Comprueba qué packages ha cambiado desde la última versión (la última etiqueta de git).

Lerna determina la última etiqueta git creada y ejecuta git diff --name-only v6.8.1 para cambiar todos los archivos desde esa etiqueta. Luego devuelve una matriz de paquetes que tienen un archivo actualizado.

Tenga en cuenta que la configuración del comando publish también afecta al comando updated. Por ejemplo config.publish.ignore

–json

$ lerna updated --json

Cuando se ejecuta con este indicador, updated devolverá una matriz de objetos en el siguiente formato:

limpiar

$ lerna clean

Eliminar el directorio node_modules de todos los paquetes.

lerna clean respeta las banderas --ignore, --scope y --yes (consulte Banderas).

diff

$ lerna diff $ lerna diff# diff a specific package$ lerna diff package-name

Diff todos los paquetes o un solo paquete desde la última versión.

Similar a lerna updated. Este comando ejecuta git diff.

ls

$ lerna ls

Lista todos los paquetes públicos en el repositorio Lerna actual.

lerna ls respeta las banderas --ignore y --scope(consulte Banderas).

j json

$ lerna ls --json

Cuando se ejecuta con este indicador, ls devolverá una matriz de objetos en el siguiente formato:

ejecutar

Ejecutar un script npm en cada paquete que contenga ese script. Se necesita un doble guión (--) para pasar argumentos discontinuos a la ejecución del script.

lerna run respeta el --concurrency, --scope, --ignore, --stream, y banderas --parallel (consulte Banderas).

$ lerna run --scope my-component test

Nota: Se recomienda restringir el alcance de este comando (y lerna exec, a continuación) cuando se usa la bandera --parallel, ya que generar docenas de subprocesos puede ser perjudicial para la ecuanimidad de su shell (o el límite máximo de descriptores de archivo, por ejemplo). YMMV

exec

$ lerna exec -- <command> # runs the command in all packages$ lerna exec -- rm -rf ./node_modules$ lerna exec -- protractor conf.js

Ejecuta un comando arbitrario en cada paquete. Un doble guión (--) es necesario para pasar banderas discontinuas al comando generado, pero no es necesario cuando todos los argumentos son posicionales.

lerna exec respeta el --concurrency, --scope, --ignore, y banderas --parallel (consulte Banderas).

$ lerna exec --scope my-component -- ls -la

Para generar procesos de larga duración, pase la bandera --parallel :

# transpile all modules as they change in every package$ lerna exec --parallel -- babel src -d lib -w

También puede obtener el nombre del paquete actual a través de la variable de entornoLERNA_PACKAGE_NAME:

$ lerna exec -- npm view $LERNA_PACKAGE_NAME

También puede ejecutar un script ubicado en el directorio raíz, en una estructura de directorio complicada a través de la variable de entornoLERNA_ROOT_PATH:

$ lerna exec -- node $LERNA_ROOT_PATH/scripts/some-script.js

Sugerencia: Los comandos se generan en paralelo, utilizando la concurrencia dada (excepto con --parallel). La salida se canaliza, por lo que no es determinista. Si desea ejecutar el comando en un paquete tras otro, utilícelo de la siguiente manera:

$ lerna exec --concurrency 1 -- ls -la

–bail

$ lerna exec --bail=<boolean> <command>

Esta bandera indica si el comando exec debe detener la ejecución al encontrar un error lanzado por uno de los subprocesos generados. Su valor predeterminado es true.

importar

$ lerna import <path-to-external-repository>

Importar el paquete en <path-to-external-repository>, con historial de confirmaciones, en packages/<directory-name>. Se conservan los autores, las fechas y los mensajes originales de la confirmación. Las confirmaciones se aplican a la rama actual.

Esto es útil para reunir paquetes independientes preexistentes en un repositorio Lerna. Cada confirmación se modifica para hacer cambios relativos al directorio del paquete. Así, por ejemplo, el commit que agregó package.json agregará packages/<directory-name>/package.json.

Misc

Lerna se registrará en un archivo lerna-debug.log (igual que npm-debug.log) cuando encuentre un error al ejecutar un comando.

Lerna también tiene soporte para paquetes con alcance.

Ejecutar lerna sin argumentos mostrará todos los comandos / opciones.

lerna.json

{ "lerna": "2.0.0", "version": "1.1.3", "commands": { "publish": { "ignore": }, "bootstrap": { "ignore": "component-*" } }, "packages": }
  • lerna: la versión actual de Lerna que se utiliza.
  • version: la versión actual del repositorio.
  • commands.publish.ignore: una matriz de globs que no se incluirán en lerna updated/publish. Use esto para evitar publicar una nueva versión innecesariamente para cambios, como corregir un error tipográfico README.md.
  • commands.bootstrap.ignore: una matriz de globs que no se arrancarán al ejecutar el comando lerna bootstrap.
  • commands.bootstrap.scope: un array de globs que restringe qué paquetes serán arrancados al ejecutar el comando lerna bootstrap.
  • packages: Matriz de globs para usar como ubicaciones de paquetes.

Dependencias de desarrollo comunes

La mayoría de devDependencies se pueden arrastrar hasta la raíz de un repositorio Lerna.

Esto tiene algunos beneficios:

  • Todos los paquetes utilizan la misma versión de una dependencia dada
  • Puede mantener actualizadas las dependencias en la raíz con una herramienta automatizada como GreenKeeper
  • Se reduce el tiempo de instalación de dependencias
  • Se necesita menos almacenamiento

Tenga en cuenta que devDependencies proporciona ejecutables «binarios» que los scripts npm todavía deben instalarse directamente en cada paquete donde se usan.

Por ejemplo, la dependencia nsp es necesaria en este caso para que lerna run nsp(y npm run nsp dentro del directorio del paquete) funcione correctamente:

{ "scripts": { "nsp": "nsp" }, "devDependencies": { "nsp": "^2.3.3" }}

Banderas

Las opciones de Lerna pueden provenir de la configuración (lerna.json) o de la línea de comandos. Además, las opciones de config pueden estar en el nivel superior o aplicarse a comandos específicos.

Ejemplo:

{ "lerna": "x.x.x", "version": "1.2.0", "exampleOption": "foo", "command": { "init": { "exampleOption": "bar", } },}

En este caso exampleOption será «foo» para todos los comandos excepto init, donde será «bar». En todos los casos se puede reemplazar a «baz»en la línea de comandos con --example-option=baz.

concurr concurrency

Cuántos hilos usar cuando Lerna paraleliza las tareas (por defecto es 4)

$ lerna publish --concurrency 1

–scope

Scopes una orden para un subconjunto de paquetes.

$ lerna exec --scope my-component -- ls -la
$ lerna run --scope toolbar-* test

–desde

Al ejecutar un script o comando, amplíe la operación a paquetes que se hayan actualizado desde el refespecificado. Si no se especifica ref, el valor predeterminado es la última etiqueta.

Enumere el contenido de los paquetes que han cambiado desde la última etiqueta:

$ lerna exec --since -- ls -la

Ejecute las pruebas para todos los paquetes que han cambiado desde master:

$ lerna run test --since master

Lista todos los paquetes que han cambiado desde entonces some-branch:

$ lerna ls --since some-branch

Esto puede ser particularmente útil cuando se usa en CI, si puede obtener la rama de destino en la que entrará un PR, porque puede usarlo como la opción ref a --since. Esto funciona bien para PRs que van a las ramas master y feature.

ignore ignore

Excluye un subconjunto de paquetes cuando se ejecuta una orden.

$ lerna bootstrap --ignore component-*

La bandera ignore, cuando se usa con el comando bootstrap, también se puede configurar en lerna.json bajo la tecla commands.bootstrap. El indicador de línea de comandos tendrá precedencia sobre esta opción.

Ejemplo

{ "lerna": "2.0.0", "version": "0.0.0", "commands": { "bootstrap": { "ignore": "component-*" } }}

Sugerencia: El glob se compara con el nombre de paquete definido en package.json, no con el nombre de directorio en el que vive el paquete.

–include-filtered-dependencies

Nota: Esto anulará las banderas --scope y --ignore.

es decir, Un paquete que coincida con la bandera --ignore seguirá siendo arrancado si depende de otro paquete que esté siendo arrancado.

Esto es útil para situaciones en las que desea «configurar» un solo paquete que depende de otros paquetes que se están configurando.

$ lerna bootstrap --scope my-component --include-filtered-dependencies# my-component and all of its dependencies will be bootstrapped

–nivel de registro

Qué nivel de registros informar. En caso de fallo, todos los registros se escriben en lerna-debug.inicie sesión en el directorio de trabajo actual.

Se muestran todos los registros de un nivel superior al de la configuración. El valor predeterminado es «info».

max max-buffer

Establezca una longitud máxima de búfer para cada llamada de proceso subyacente. Útil, por ejemplo, cuando alguien quiere importar un repositorio con una mayor cantidad de confirmaciones mientras ejecuta lerna import. En ese caso, la longitud del búfer incorporado podría no ser suficiente.

no no-sort

De forma predeterminada, todas las tareas se ejecutan en paquetes en orden topológico para respetar las relaciones de dependencia de los paquetes en cuestión. Los ciclos se rompen en base al mejor esfuerzo de una manera que no se garantiza que sea consistente en todas las invocaciones de Lerna.

La ordenación topológica puede causar cuellos de botella de concurrencia si hay un pequeño número de paquetes con muchos dependientes o si algunos paquetes tardan desproporcionadamente en ejecutarse. La opción --no-sort deshabilita la ordenación, en lugar de ejecutar tareas en un orden arbitrario con máxima concurrencia.

Esta opción también puede ayudar si ejecuta varios comandos «watch». Dado que lerna run ejecutará comandos en orden topológico, puede terminar esperando un comando antes de continuar. Esto bloqueará la ejecución cuando ejecute comandos «watch», ya que normalmente nunca terminan. Un ejemplo de un comando «watch» está ejecutando babel con el indicador CLI --watch.

ho hoist

Instale dependencias externas que coincidan con glob en la raíz del repositorio para que estén disponibles para todos los paquetes. Todos los binarios de estas dependencias se vincularán a los directorios de paquetes dependientes node_modules/.bin/ para que estén disponibles para scripts npm. Si la opción está presente pero no se da glob, el valor predeterminado es ** (ho todo). Esta opción solo afecta al comando bootstrap.

$ lerna bootstrap --hoist

Para obtener información de fondo sobre --hoist, consulte la documentación del polipasto.

Nota: Si los paquetes dependen de diferentes versiones de una dependencia externa, se izará la versión más utilizada y se emitirá una advertencia.

no nohoist

No instale dependencias externas que coincidan con glob en la raíz del repositorio. Esto se puede usar para optar por no izarse para ciertas dependencias.

$ lerna bootstrap --hoist --nohoist=babel-*

–npm-client

Instala dependencias externas usando install. Debe ser un ejecutable que sepa instalar dependencias npm.

$ lerna bootstrap --npm-client=yarn

También se puede configurar en lerna.json:

{ ... "npmClient": "yarn"}

–use-workspaces

Permite la integración con Yarn Workspaces (disponible desde [email protected]+).
Los valores de la matriz son los comandos en los que Lerna delegará la operación a Yarn (actualmente solo bootstrapping).
Si --use-workspaces es true, packages se anulará con el valor de package.json/workspaces.
También se puede configurar en lerna.json:

{ ... "npmClient": "yarn", "useWorkspaces": true}

–stream

Salida de flujo de procesos secundarios inmediatamente, con el prefijo del nombre del paquete de origen. Esto permite que la salida de diferentes paquetes se intercale.

$ lerna run watch --stream

–paralelo

Similar a --stream, pero sin tener en cuenta la concurrencia y la ordenación topológica, ejecutando un comando o script dado inmediatamente en todos los paquetes coincidentes con salida de streaming prefijada. Esta es la bandera preferida para procesos de larga duración, como babel src -d lib -w que se ejecutan en muchos paquetes.

$ lerna exec --parallel -- babel src -d lib -w

–registry

Cuando se ejecuta con este indicador, los comandos npm reenviados utilizarán el registro especificado para sus paquetes.

Esto es útil si no desea configurar explícitamente la configuración del registro en todo el paquete.archivos json individualmente cuando, por ejemplo, se utilizan registros privados.

temp etiqueta temporal

Cuando se pasa, este indicador alterará el proceso de publicación predeterminado publicando primero todos los paquetes modificados a una etiqueta temporal dist (lerna-temp) y luego moviendo la(s) nueva (s) a la etiqueta dist predeterminada (latest).

Esto generalmente no es necesario, ya que Lerna publicará paquetes en orden topológico (todas las dependencias antes que los dependientes) por defecto.

Asistente

Si prefiere alguna guía para la interfaz de línea de comandos (en caso de que esté a punto de comenzar a usar lerna o presentarlo a un nuevo equipo), es posible que desee lerna-wizard. Te guiará a través de una serie de pasos bien definidos:

Etiquetas actuales

Deja una respuesta

Tu dirección de correo electrónico no será publicada.