lerna guía de inicio

1. Colocación

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

Herramienta de gestión de varios módulos para ayudar a mantener monorepo

PSLerna es la herramienta diaria y de código abierto de Babel, consulte ¿Por qué Babel es un monorepo?

2. Monorepo
Monorepo (repositorio monolítico), a diferencia de multirepo, es un repositorio de código único y un repositorio de código múltiple (un repositorio por módulo)

Multirepo es el enfoque tradicional. Se divide en múltiples bases de código por módulos. Se han encontrado algunos problemas en la práctica:

La gestión de problemas es caótica y los problemas de los módulos a menudo se plantean en el repositorio principal, y debe cerrar esto y realizar un seguimiento de aquello.

El registro de cambios es difícil de integrar y es necesario clasificar manualmente todos los almacenes modificados e integrarlos

La actualización de la versión del repositorio central es problemática, debe sincronizar todos los módulos para actualizar sus versiones del repositorio central dependientes

Monorepo coloca todos los módulos relacionados en un repositorio. Cada módulo se publica de forma independiente, pero utiliza el mismo número de versión (como Babel y React) con el repositorio. Los problemas y los PR se concentran en el repositorio, y el registro de cambios se puede copiar simplemente de una copia. La lista de compromiso está ordenada (incluso si la etiqueta de problema está asociada con la especificación de compromiso, se puede generar automáticamente un registro de cambios estandarizado)

Monorepo también tiene algunos problemas, pero no tan fuertes como los puntos de dolor mencionados anteriormente:

El tamaño del repositorio es grande, lo que puede causar problemas de control de versiones (Git no es adecuado para administrar repositorios grandes)

Herramientas de construcción unificadas, proponen requisitos más altos para las herramientas de construcción, para poder construir varios módulos relacionados

Desde la perspectiva de la gestión del código fuente, multirepo y monorepo son dos conceptos diferentes. El primero permite un desarrollo diversificado y cada módulo puede tener su propia jugabilidad (compilación, administración de dependencias, pruebas unitarias, etc.), mientras que el segundo espera centralizar la administración y reducir la jugabilidad. Costos de comunicación causados ​​por diferencias

La característica distintiva de monorepo es la estructura de directorios, como React:

react-16.2.0/
  packages/
    react/
    react-art/
    react-.../

Cada módulo tiene sus propias dependencias (package.json), que se pueden lanzar como un paquete npm independiente, pero el código fuente se mantiene junto

Caso típico:

resumen: multirrepo

babel: monorepo

Si tiene problemas con el resumen antes de usar PS, primero vaya al repositorio principal para verificar los problemas relacionados, luego busque el repositorio de complementos correspondiente de acuerdo con las pistas y luego verifique los problemas relacionados. Siempre me he sentido muy problemático y no puedo decir qué pasa, resultó ser el problema causado por la organización del código fuente.

Tres.lerna jugar

// 安装
npm install lerna -g
git init hoho-lerna && cd hoho-lerna
// 初始化目录结构
lerna init

Obtenga la siguiente estructura:

hoho-lerna/
  packages/
  lerna.json
  package.json

Crea un módulo:

mkdir packages/hoho-lerna-core && cd packages/hoho-lerna-core
npm init

Esto terminará con un montón de paquetes:

packages/
  hoho-lerna-core/
    package.json
  hoho-lerna-module-a/
    package.json
  hoho-lerna-module-b/
    package.json
  module.../

Lo que realmente hacemos es dividir en paquetes por módulo y declarar las dependencias entre paquetes (a través de package.json a nivel de módulo)

Procesamiento de dependencias
Si moduleA depende del núcleo, después de procesar la dependencia mediante el comando lerna bootstrap, se creará un enlace suave en node_modules de moduleA para apuntar al directorio del núcleo. Hay un ejemplo vivo

Nota: npm no instalará automáticamente peerDependencies, ni lerna proporciona este servicio

Lerna bootstrap asocia los paquetes estableciendo enlaces suaves de acuerdo con las dependencias declaradas previamente

Dado que todos los paquetes publicados se colocan en paquetes, es fácil de administrar de manera uniforme, por lo que admite la liberación con un clic de todos los paquetes a npm

PS debe tener una cuenta npm (autoregistro) y agregar npm adduser a la configuración local

Después de prepararme, no puedo esperar para comenzar con una flecha:

Si lerna publish
no es inesperado, obtendrá un resultado similar:

lerna info version 2.7.0
lerna info current version 0.0.0
lerna info Checking for updated packages...
lerna info Comparing with initial commit.
lerna info Checking for prereleased packages...
? Select a new version (currently 0.0.0) Major (1.0.0)

Changes:
 - hoho-lerna-core: 1.0.0 => 1.0.0
 - hoho-lerna-module-a: 1.0.0 => 1.0.0
 - hoho-lerna-module-b: 1.0.0 => 1.0.0

? Are you sure you want to publish the above changes? Yes
lerna info publish Publishing packages to npm...
lerna info published hoho-lerna-module-b
lerna info published hoho-lerna-core
lerna info published hoho-lerna-module-a
lerna info git Pushing tags...
Successfully published:
 - [email protected]
 - [email protected]
 - [email protected]
lerna success publish finished

Luego, hay 3 paquetes basura en el registro npm ...

El proceso general de publicación es:

Etiquetar localmente (por ejemplo, git tag v1.0.0)

Ejemplo de actualización automática del número de versión de dependencia

Luego publique cada paquete en npm

Finalmente, presione la etiqueta y el compromiso correspondiente

Nota: Si el paso de publicación en npm falla (por ejemplo, la cuenta npm no está configurada), la próxima publicación directa de lerna no se puede publicar directamente, parece que la etiqueta local ya es v1.0.0 y la última publicación fue exitosa. No es posible implementar esta etiqueta manualmente. Es posible que algunos estados de publicación se registren en .git. Después de la implementación, aparece un error de coincidencia de hash de confirmación, que no es muy amigable aquí.

PD Para obtener más comandos, consulte Lerna

Para generar automáticamente el registro de
cambios, primero instale la herramienta de registro de cambios:

npm install lerna-changelog -g

Luego agregue los elementos de configuración correspondientes en lerna.json:

"changelog": {
  "repo": "ayqy/hoho-lerna",
  "labels": {
    "enhancement": ":rocket: Enhancement",
    "bug": ":bug: Bug Fix",
    "doc": "Refine Doc",
    "feat": "New Feature"
  },
  "cacheDir": ".changelog"
}

Nota especial: se requiere un repositorio, se dice que se infiere automáticamente, pero de hecho no es muy confiable, consulte El campo 'Repo' se infiere automáticamente, pero no se produjo ningún error.

En PSlabels, la clave es la etiqueta que se configurará en Github, utilizada para clasificar Issue / PR, el valor en: bug: solo un emoji travieso, se usará como título de este tipo de cambio en el registro de cambios

Aún no ha terminado, pero también necesita permisos de repositorio de Github (para poder verificar Issue, PR) y exponer el token como una variable de entorno (puede agregarlo a ~ / .bash_profile si es de uso común):

export GITHUB_AUTH="..."

La configuración está completa. Para lograr "automático", la premisa es que el desarrollo y el mantenimiento diarios cumplan con las especificaciones acordadas, de lo contrario la herramienta definitivamente no podrá adivinar el registro de cambios al final. La especificación se refiere a:

(Recomendación) Problema correspondiente asociado con el mensaje de confirmación

(Obligatorio) Elija nuestra etiqueta predefinida al crear relaciones públicas

Debido a que la herramienta solo clasifica el PR con la etiqueta especificada en github, y usa el mensaje de confirmación como elemento del registro de cambios, se recomienda asociar el problema en el mensaje de confirmación, y el registro de cambios generado se puede asociar con el problema correspondiente:

Uses github PR/Issue names categorized by labels with configurable headings.

P.ej:

git cm -m "feat: changelog, Close #1"

Luego envíe un PR y pegue la etiqueta: hazaña, después de la fusión, tire del tirón local para probar lerna-changelog:

## Unreleased (2018-01-13)

#### New Feature
* [#2](https://github.com/ayqy/hoho-lerna/pull/2) feat: changelog, Closes [#1](https://github.com/ayqy/hoho-lerna/issues/1). ([@ayqy](https://github.com/ayqy))

#### Committers: 1
- 黯羽轻扬 ([ayqy](https://github.com/ayqy))
相当漂亮：https://github.com/ayqy/hoho-lerna/releases/tag/v1.1.0

PS debe ignorar el archivo temporal de registro de cambios generado localmente en .gitignore, solo el registro de cambios local de lerna cuando se lanza una nueva versión, y publicar el registro de cambios generado en la nota de la versión. No publicar notas de la versión automáticamente puede deberse a restricciones de API o por consideraciones prudentes. Después de todo, las notas de la versión son aún más importantes

Además, la clasificación automática del registro de cambios de esta manera se basa en las restricciones en el desarrollo (especificación de la etiqueta del PR, mensaje de confirmación como la especificación del elemento del registro de cambios), que no tiene nada que ver con lerna, siempre que sea un monorepo (Edición / PR) Júntelos, puede obtener información sobre problemas / relaciones públicas de acuerdo con esta idea y resolver el registro de cambios

Es equivalente a distribuir la enorme carga de trabajo de ordenar el registro de cambios para el desarrollo y el mantenimiento diarios. El cambio debe ser de relaciones públicas y debe haber un registro de problemas. Si no está acostumbrado, sigue siendo muy problemático (hay una llamada para que el mensaje de confirmación traiga su propia etiqueta en lugar de PR , Debería ser compatible en el futuro)

4. Escenarios aplicables
¿Qué escenarios pueden utilizar monorepo (y utilizar la gestión de lerna?)?

Pero si es un proyecto enorme, si tiene un código fuente 100G integrado, considérelo nuevamente.

Para proyectos de varios módulos / complementos, es muy adecuado utilizar complementos mantenidos oficialmente como paquetes

Además, también necesitas:

Infraestructura

Confianza del equipo

La infraestructura se refiere a una poderosa herramienta de construcción que puede satisfacer las necesidades de construcción de todos los módulos (para un proyecto de front-end puro, la presión de construcción no es grande)

En el entorno de monorepo, es posible y se anima a cambiar el código de otras personas. Por un lado, se requiere un mecanismo de integración continua (como React-CircleCI) para confirmar el impacto de la modificación. Por otro lado, los diferentes equipos deben confiar entre sí, de lo contrario, a menudo aparecerá un equipo. El cambio afecta la situación de otro equipo y necesita revertir los cambios de otras personas, lo que afectará la eficiencia

PSLerna ha estado fuera durante mucho tiempo (aproximadamente la misma edad que Babel), y muchos proyectos están en uso

Referencia
Lerna: documento oficial muy conciso

monorepo new wave | presenta a lerna: senior helloworld no está mal

Batalla de estilo REPO: MONO VS MULTI

Comparación de herramientas de repositorio mono: Comparación de herramientas de Monorepo

Modularidad de nueva ola con organizaciones Lerna, monorepos y npm