Auto: Plugin: Aplicar rótulos de PR com base em mensagens de confirmação de estilo de liberação semântica

Criado em 19 jan. 2019  ·  14Comentários  ·  Fonte: intuit/auto

Movido de https://github.com/intuit/auto-release/issues/176

@aleclarson disse:

Aqui está um plugin que eu preciso imediatamente:

Ele verifica as mensagens de confirmação de um PR em busca de prefixos de estilo semantic-release (por exemplo: fix: , feat: , BREAKING ) e aplica automaticamente o patch apropriado minor / major para o PR.
Inspirado por este tópico do Twitter.

Você consideraria isso como um plugin oficialmente suportado?

@hipstersmoothie disse:

Sim, isso soa como um bom plugin! Eu estou bem com isso sendo oficial. Embora possamos precisar adicionar um ou dois ganchos extras para esse comportamento

Um gancho com o nome parseCommit pode habilitar isso aqui

https://github.com/intuit/auto-release/blob/5220097f4ce075f4097d62492cd08b6e9551fca2/src/log-parse.ts#L141

@aleclarson disse:

Poderíamos usar parse-commit-message para extrair metadados de commits (embora sua dependência em esm o torne um pouco pesado , mas isso será removido quando o NodeJS suportar módulos ES nativamente). Enquanto isso, podemos bifurcá-lo e remover a dependência esm se isso nos incomodar o suficiente. Mesmo que não façamos um fork, ainda é ~6x menor do que semantic-release usa.

enhancement

Comentários muito úteis

@aleclarson por que o tamanho é tanto problema? Mesmo na terra do nó, nossos gerenciadores de pacotes já são inteligentes o suficiente para desduplicar.

Eu nunca mencionei dependências duplicadas como uma preocupação. Estou apenas desconfiado de ferramentas inchadas em geral. "Quanto mais leve, melhor" é minha regra, mas cada um na sua. Eu não estou realmente interessado em debater isso. :)

Aliás, para se juntar à festa. git-commits-since e detect-next-version podem ser mais úteis aqui?

Eu preferiria usar parse-commit-message já que esses pacotes parecem duplicar a lógica que já existe em auto-release , mas talvez @hipstersmoothie substitua a lógica existente por esses pacotes para reduzir a carga de manutenção.

Todos 14 comentários

É muito estranho como isso depende do ESM

Provavelmente deve estar usando esm para a compilação e não em produção

é como usar o babel-register em vez de apenas construí-lo e publicar a pasta dist

Eu pensei o mesmo no começo, mas uma olhada no código-fonte diz o contrário.

edit: Oh nvm, você está dizendo que esm pode ser usado para compilar antes de publicar. Devemos enviar um PR.

Parece um bom módulo de outra forma. Bonito e magro

Parece que esm não foi feito para compilação: https://github.com/standard-things/esm/issues/13#issuecomment -321710199

Eu digo que nós bifurcamos por enquanto e convertemos a sintaxe import e export para CommonJS.

hmm sim, eu estava apenas lendo o readme. Parece que eu entendi errado

Farei um pr para mudar para https://github.com/developit/microbundle e talvez ele o adicione.

Você deve considerar usar https://github.com/egoist/bili em vez disso. Ele tem metade do tamanho da instalação, mas pode ter outras vantagens. Não tenho certeza.

Aliás, para se juntar à festa. git-commits-since e detect-next-version podem ser mais úteis aqui?

Estou usando esm por causa de garantias e porque está por trás do sinalizador de recurso esm do Node. Eu facilmente poderia usar ascjs ou similar como rewrite-imports , mas esm suporta muito mais do que apenas a importação/exportação. E porque eu não vou _nenhuma_ etapa de compilação ou qualquer coisa, para testar eu apenas uso como um gancho para o meu runner.

O que nos leva a isso, podemos mudar para ascjs ou asbundle .

@aleclarson por que o tamanho é tanto problema? Mesmo na terra do nó, nossos gerenciadores de pacotes já são inteligentes o suficiente para desduplicar.

@aleclarson por que o tamanho é tanto problema? Mesmo na terra do nó, nossos gerenciadores de pacotes já são inteligentes o suficiente para desduplicar.

Eu nunca mencionei dependências duplicadas como uma preocupação. Estou apenas desconfiado de ferramentas inchadas em geral. "Quanto mais leve, melhor" é minha regra, mas cada um na sua. Eu não estou realmente interessado em debater isso. :)

Aliás, para se juntar à festa. git-commits-since e detect-next-version podem ser mais úteis aqui?

Eu preferiria usar parse-commit-message já que esses pacotes parecem duplicar a lógica que já existe em auto-release , mas talvez @hipstersmoothie substitua a lógica existente por esses pacotes para reduzir a carga de manutenção.


:rocket: O problema foi lançado em 10.0.0 :rocket:

Esta página foi útil?
0 / 5 - 0 avaliações