guia de primeiros passos da lerna

1. Posicionamento

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

Ferramenta de gerenciamento de vários módulos para ajudar a manter o monorepo

PSLerna é a ferramenta diária e de código aberto do próprio Babel, consulte Por que o Babel é um monorepo?

2. Monorepo
Monorepo (repositório monolítico), ao contrário de multirepo, é um repositório de código único e um repositório de vários códigos (um repositório por módulo)

Multirepo é a abordagem tradicional. É dividido em várias bases de código por módulos. Alguns problemas foram encontrados na prática:

O gerenciamento de problemas é caótico e os problemas de módulo são frequentemente levantados no repositório principal, e você precisa fechar isso e rastrear aquilo

O changelog é difícil de integrar e é necessário separar manualmente todos os armazéns alterados e integrá-los

A atualização da versão principal do repo é problemática, você precisa sincronizar todos os módulos para atualizar suas versões principais do repo dependentes

O Monorepo coloca todos os módulos relacionados em um repo. Cada módulo é lançado de forma independente, mas usa o mesmo número de versão (como Babel e React) com o repo. Problemas e PRs são concentrados no repo, e o changelog pode ser simplesmente copiado de uma cópia. A lista de confirmação é classificada (mesmo se a tag de problema estiver associada à especificação de confirmação, um changelog padronizado pode ser gerado automaticamente)

Monorepo também tem alguns problemas, mas não tão fortes quanto os pontos problemáticos mencionados acima:

O tamanho do repo é grande, o que pode causar problemas de controle de versão (o Git não é adequado para gerenciar repo grande)

Ferramentas de construção unificadas, apresentam requisitos mais elevados para ferramentas de construção, para ser capaz de construir vários módulos relacionados

Do ponto de vista do gerenciamento de código-fonte, multirepo e monorepo são dois conceitos diferentes. O primeiro permite um desenvolvimento diversificado e cada módulo pode ter sua própria jogabilidade (construção, gerenciamento de dependências, teste de unidade etc.), enquanto o último espera centralizar o gerenciamento e reduzir a jogabilidade. Custos de comunicação causados ​​por diferenças

A característica marcante do monorepo é a estrutura de diretórios, como React:

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

Cada módulo tem suas próprias dependências (package.json), que podem ser lançadas como um pacote npm independente, mas o código-fonte é mantido junto

Caso Típico:

rollup ： multirepo

babel ： monorepo

Se você encontrar problemas com o rollup antes, primeiro vá para o repositório principal para verificar os problemas relacionados, em seguida, encontre o repositório de plug-ins correspondente com base nas pistas e, em seguida, verifique os problemas relacionados. Sempre me senti muito incômodo e não consigo saber o que há de errado. Acabou sendo o problema causado pela organização do código-fonte

Jogo Three.lerna

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

Obtenha a seguinte estrutura:

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

Crie um módulo:

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

Isso vai acabar com um monte de pacotes:

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

O que realmente fazemos é dividir em pacotes por módulo e declarar as dependências entre os pacotes (por meio de package.json de nível de módulo)

Processamento de dependência
Se o móduloA depender do núcleo, depois de processar a dependência por meio do comando lerna bootstrap, um link virtual será criado em node_modules do módulo A para apontar para o diretório do núcleo. Há um exemplo vivo

Observação: o npm não instalará automaticamente peerDependencies, nem lerna fornece este serviço

O Lerna bootstrap realmente associa os pacotes estabelecendo links virtuais de acordo com as dependências previamente declaradas

Uma vez que os pacotes lançados são todos colocados em pacotes, é fácil de gerenciar uniformemente, por isso suporta o lançamento com um clique de todos os pacotes para npm

PS deve ter uma conta npm (autorregistro) e adicionar npm adduser à configuração local

Depois de me preparar, mal posso esperar para começar com uma seta:

Se lerna publish
não for inesperado, você obterá um resultado semelhante:

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

Então, há 3 pacotes de lixo no registro npm ...

O processo geral de publicação é:

Marque localmente (por exemplo, git tag v1.0.0)

Exemplo de atualização automática do número da versão da dependência

Em seguida, publique cada pacote no npm

Finalmente, empurre a tag e o commit correspondente

Nota: Se a etapa de publicação no npm falhar (por exemplo, a conta npm não está configurada), a próxima publicação direta da lerna não pode ser publicada diretamente, parece que a tag local já é v1.0.0 e a última publicação foi bem-sucedida. Não é possível lançar manualmente esta tag. Alguns status de lançamento podem ser registrados em .git. Após a rolagem, um erro de correspondência de hash de commit aparece, o que não é muito amigável aqui.

PS Para mais comandos, por favor, verifique Lerna

Para gerar automaticamente o changelog
, instale a ferramenta changelog primeiro:

npm install lerna-changelog -g

Em seguida, adicione os itens de configuração correspondentes em lerna.json:

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

Observação especial: o repo é necessário, diz-se que é inferido automaticamente, mas não é muito confiável, consulte o campo The'repo 'inferido automaticamente falhou, mas nenhum erro ocorreu

Em PSlabels, key é o rótulo a ser configurado no Github, usado para classificar Issue / PR, o valor em: bug: apenas um emoji travesso, ele será usado como o título deste tipo de alteração no changelog

Ainda não acabou, mas você também precisa de permissões de repositório Github (para poder verificar Issue, PR) e expor o token como uma variável de ambiente (você pode adicioná-lo a ~ / .bash_profile se for usado com frequência):

export GITHUB_AUTH="..."

A configuração está completa. Para alcançar o "automático", a premissa é que o desenvolvimento e a manutenção diários estejam de acordo com as especificações acordadas, caso contrário, a ferramenta definitivamente não será capaz de adivinhar o changelog no final. A especificação se refere a:

(Recomendação) Problema correspondente associado à mensagem de confirmação

(Obrigatório) Escolha nosso rótulo predefinido ao criar PR

Como a ferramenta apenas classifica o PR com o rótulo especificado no github e usa a mensagem de confirmação como o item do changelog, é recomendado associar o problema à mensagem de confirmação, e o changelog gerado pode ser associado ao problema correspondente:

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

Por exemplo:

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

Em seguida, envie um PR e cole o rótulo: feat, após a mesclagem, puxe o pull local para tentar 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

O PS deve ignorar o arquivo temporário do changelog gerado localmente em .gitignore, apenas o lerna-changelog local quando uma nova versão for lançada, e postar o changelog gerado na nota de lançamento. O não lançamento automático das notas de versão pode ser devido a restrições de API ou a considerações prudentes. Afinal, as notas de versão são ainda mais importantes

Além disso, a classificação automática do changelog desta forma realmente depende das restrições no desenvolvimento (especificação do rótulo do PR, mensagem de confirmação como a especificação do item do changelog), que não tem nada a ver com lerna, contanto que seja um monorepo (Problema / PR) Coloque-os juntos, você pode obter informações de problema / RP de acordo com essa ideia e classificar o changelog

É equivalente a distribuir a enorme carga de trabalho de classificar o changelog para o desenvolvimento e manutenção diários. A mudança deve ser PR e deve haver um registro de problema. Se você não está acostumado, ainda é muito problemático (há uma chamada para mensagem de confirmação para trazer seu próprio rótulo em vez de PR , Deve ser suportado no futuro)

4. Cenários aplicáveis
Quais cenários podem usar monorepo (e usar gerenciamento de lerna?)?

Mas se for um projeto enorme, se você tiver o código-fonte 100G integrado, considere-o novamente.

Para projetos de múltiplos módulos / plug-ins, é muito adequado usar plug-ins mantidos oficialmente como pacotes

Além disso, você também precisa de:

A infraestrutura

Confiança da equipe

Infraestrutura refere-se a uma ferramenta de construção poderosa que pode atender às necessidades de construção de todos os módulos (para um projeto de front-end puro, a pressão de construção não é grande)

No ambiente monorepo, é possível e incentivado alterar o código de outras pessoas. Por um lado, um mecanismo de integração contínua (como React-CircleCI) é necessário para confirmar o impacto da modificação. Por outro lado, equipes diferentes precisam confiar umas nas outras, caso contrário, uma equipe frequentemente aparecerá. A mudança afeta a situação de outra equipe e precisa reverter as mudanças de outras pessoas, o que afetará a eficiência

PSLerna já está no mercado há muito tempo (quase a mesma idade de Babel), e muitos projetos estão em uso

Referência
Lerna: documento oficial muito conciso

monorepo new wave | apresentar lerna: senior helloworld não é ruim

Batalha de estilo REPO: MONO VS MULTI

Comparação da ferramenta Mono Repository: comparação da ferramenta Monorepo

Modularidade da nova onda com organizações Lerna, monorepos e npm