Auto: Use npm como fonte da versão da verdade

Oooh eu gosto disso. No entanto, isso pode ser complicado para monorepos

Já que fazemos --force-publish=* para lerna, não deve ser um problema, pois todos os pacotes devem ter uma versão vinculada.

No futuro, se removermos essa sinalização, teremos que ... idk

Além disso, apenas executamos npm version que leva apenas uma string semver. Na verdade, não definimos um número de pacote em nenhum lugar agora. Não seria muito difícil configurá-lo nós mesmos, mas monorepos novamente parece que não seriam simples

A maioria dos comandos funcionam em tags também, então se a versão não foi marcada, isso poderia causar alguns problemas.

https://github.com/azu/can-npm-publish

"Estou cada vez mais convencido de que o modo de controle de versão“ independente ”foi um erro. Tudo o que ele faz é fazer as pessoas jogarem pacotes aleatórios em um único repositório e reclamar quando precisam versioná-los ao mesmo tempo." ~ do mantenedor do lerna.

Portanto, --force-publish=* parece bom.

--force-publish e versionamento independente não são a mesma coisa.
Por padrão, lerna só publicará uma atualização para um pacote se ele tiver alterações nele, usando --force-publish=* forçamos lerna a publicar uma versão de todos os pacotes, mesmo se não houver alterações desde a última publicação.

ou seja, o pacote A tem alterações, B não. lerna publicará apenas uma nova versão de A ( B permanecerá na versão atual). O próximo lançamento A e B tem alterações, ambos serão publicados com a mesma nova versão.

Algo em que estive pensando (e não tenho certeza se isso é algo que apoiaríamos) é o potencial para lançamentos que não são master (ou o branch principal). Até este ponto, sempre assumimos que há um caminho para os lançamentos - e eles são sempre lineares (usando a versão latest no npm ou github).

O que acontece no caso de precisar corrigir uma versão anterior? (1.x tem um bug, master está em 2.x, mas você deseja corrigir 1.xw / a também) Se estivermos saindo do lerna ou pkg Versão

Se mudarmos isso para usar algo fora da árvore git, não acho que seríamos capazes de suportar esse comportamento, já que há apenas 1 latest no npm (ou de onde quer que buscamos a versão mais recente)

Parece um bom recurso. Pode levar algum trabalho para implementar.

versão:

• Calculamos version usando a versão mais recente - isso poderia mudar facilmente para a versão do pacote?
• A versão mais recente no github pode ser um problema. Não acho que você possa definir programaticamente a "versão mais recente". Portanto, ao publicar um patch para 1.x, ele se tornaria a versão mais recente.

release / changelog

• getCurrentVersion retorna lastRelease if gt (lastRelease, lastVersion) - então isso também precisa estar ciente

isso significa que já estamos usando coisas fora da árvore git, certo?

Precisamos depender de latestRelease para ter certeza de que tem uma tag git associada a ele, então a troca não é uma opção porque não podemos ter certeza de que a versão npm mais recente tem uma tag (como no que este problema descreve) .

Acho que provavelmente precisaríamos de um novo sinalizador com versões da última tag git. --from-git

Com isso, o comando de liberação provavelmente funcionaria. Teríamos que definir a aparência do changelog.

o sinalizador --from-git também pode substituir a observação do NPM para qualquer coisa. Acho que isso significa que podemos fundir # 173