Auto: Mensagem de confirmação de aumento personalizada

Eu posso preferir nenhum commit de bump (como semantic-release faz isso):

{
  "skipBumpCommit": true
}

Com os bump commits desabilitados, a última versão do NPM é a fonte da verdade (ou talvez já funcione dessa forma?) E o campo "versão" em package.json pode ser definido como 0.0.0-development ou similar.

O salto CI é diferente em travis? sem isso em suas mensagens de commit, você pode facilmente cair em um loop

auto usará olhar para a versão local e a versão publicada e escolher a versão superior para evitar erros de npm. Isso é suficiente?

O salto CI é diferente em travis? sem isso em suas mensagens de commit, você pode facilmente cair em um loop

Não tenho certeza. Se for necessário no cabeçalho do commit, então que seja. 😆

auto usará olhar para a versão local e a versão publicada e escolher a versão superior para evitar erros de npm. Isso é suficiente?

Oh sério? Agradável. Nenhum bump commit foi criado nesse caso?

Não, nesse caso, alteramos a versão publicada porque você pode publicar sobre uma versão antiga.

Estou tendo problemas para visualizar como skipBumpCommit funcionaria ou como seria o resultado final. Para executar shipit você tem que mudar a versão de alguma forma, então eu não consigo ver como você poderia sair desse commit.

O que você acha de shipit pular o bump commit quando a versão em package.json é algo como 0.0.0-development ?

1. O pacote começa em 0.0.0-development

2. você executa version ele retorna o bump baseado em PRs, ele retorna qualquer coisa (patch, minor, major) - digamos que é patch

3. Criação do log de alterações - (0.0.0-development => 0.0.0). Mas você não quer que isso aconteça? Em vez disso, adicione sob o título de changelog '0.0.0-development'?

4. tempo de ganchos de publicação - seria 0.0.0-development => 0.0.0 e publicar. mas você deseja que development seja detectado e pule a etapa de publicação todos juntos

5. fazer uma versão do github - em vez de criar uma nova versão, atualize a antiga com os novos commits

6. O pacote permanece em 0.0.0-development até ??? enquanto as mudanças se acumulam

Duas opções se você quiser:

1. Simplesmente não execute auto shipit até que você queira começar a lançar e publicar. Ainda adicione os rótulos aos seus PRs. Quando estiver pronto, adicione auto shipit ao seu processo de CI e ele incluirá todos os rótulos PRs em sua primeira versão.

2. Escreva um plugin. Esse comportamento é bastante único e não está de acordo com a maneira como o npm faz o controle de versão. Acho que você poderia fazer um plugin para fazer isso. Embora eu provavelmente tenha que adicionar um ou dois anzóis para você utilizar.

Um pacote com uma versão de 0.0.0-development indica o seguinte:

• A maior versão publicada do NPM é considerada a "versão atual"
• O version em package.json nunca deve ser alterado

Quando uma nova versão do NPM deve ser publicada, o Auto deve incrementar a "versão atual" usando npm version $(auto version) .

O changelog usa a "versão atual" do NPM (ao invés de package.json ).

Como sempre, uma nova versão do Github é criada para cada versão do NPM.

Estou sendo claro o suficiente?

A versão em package.json nunca deve ser alterada

Para publicar novas versões no NPM, você deve alterar isso. A única maneira de incrementar a "versão atual" e nunca alterar a local seria:

• altere para a versão atual (NPM)
• faça a colisão
• mudar de volta
• mas desde que a tag seria a versão atual de colisão fazer ???

Tenho certeza de que entendo seu caso de uso.

uma. você não deseja publicar um monte de versões enquanto está desenvolvendo um recurso em vários PRS
b. assim que uma nova versão for publicada, você deseja que todas as alterações sejam incluídas

A meu ver, já oferecemos duas maneiras de fazer isso:

1. use onlyPublishWithReleaseLabel . novas versões não são criadas até que você adicione este rótulo. Assim, você pode olhar para qualquer PR / código sem o rótulo como VERSION-development

2. como você está mesclando PRs para o grande recurso, use skip-release até que você esteja pronto para uma versão, então apenas mescle um PR. O novo lançamento contém todos os PRs ignorados. Neste caso, você pode considerar a adição do rótulo skip-release significando que sua versão é VERSION-development

Como isso difere do comportamento que você deseja?

Parece-me resumir-se a: você deseja adicionar -development à sua versão para começar a pular lançamentos e removê-lo quando estiver pronto para que todas as alterações sejam lançadas de uma vez.

para cumprir minha última frase, você provavelmente poderia fazer um plugin que usa beforeShipit para verificar a presença -development na versão e lança um erro se estiver presente. Isso impediria shipit de avançar até que você remova -development .

O único problema que vejo com isso é que também falharia o trabalho de CI.

Interpretação interessante, mas não exatamente o que eu pretendia. 😅

Estou basicamente descrevendo como funciona semantic-release .

Eu _deve_ ter dito "A versão em package.json só é alterada temporariamente para que npm publish seja bem-sucedido" (em vez de "A versão em package.json nunca deve ser alterada"). Tudo o que estou tentando fazer é evitar o bump commit por completo. :)

Ok, então o estado em que você acabaria é:

repo: sempre tem a versão 0.0.0-dev

npm: tem a versão real o tempo todo (é o que é usado para qualquer coisa)

correto?

Tipo isso

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

Sim, parece bom!

auto v4.0.0 aqui vamos nós lol. Parece que vou ter que dividir o gancho publish . Este será outro plugin

Se quiser, você pode preparar este recurso em Auto por enquanto e esperar para dividir o gancho publish até que outro plug-in também precise dele. 😛

Isso deve ser possível através do plugin agora com # 247 (a habilidade semver). A coisa da mensagem de commit requer um pouco de mudanças de configuração e realmente não leva muito a você. Fechando, mas aberto aos PRs!