Auto: Mensaje de confirmación de golpe personalizado

Es posible que prefiera que no se confirme ningún golpe (como semantic-release hace):

{
  "skipBumpCommit": true
}

Con las confirmaciones de bump deshabilitadas, la última versión de NPM es la fuente de la verdad (¿o tal vez ya funciona de esa manera?) Y el campo "versión" en package.json se puede configurar en 0.0.0-development o similar.

¿Skip CI es diferente en travis? sin eso en sus mensajes de confirmación, puede caer fácilmente en un bucle

auto usará mirar la versión local y la versión publicada y elegir la más alta para evitar errores npm. ¿Eso es suficiente?

¿Skip CI es diferente en travis? sin eso en sus mensajes de confirmación, puede caer fácilmente en un bucle

En realidad, no estoy seguro. Si es necesario en el encabezado de confirmación, que así sea. 😆

auto usará mirar la versión local y la versión publicada y elegir la más alta para evitar errores npm. ¿Eso es suficiente?

¿Ah, de verdad? Bonito. ¿No se crea ningún compromiso de golpe en ese caso?

No, en ese caso, aumentamos la versión publicada porque puede publicar sobre una versión anterior.

Tengo problemas para visualizar cómo funcionaría skipBumpCommit o cómo se vería el resultado final. Para ejecutar shipit tienes que cambiar la versión de alguna manera, así que no veo cómo puedes salir de esa confirmación.

¿Qué piensas de shipit omitiendo la confirmación de golpe cuando la versión en package.json es algo así como 0.0.0-development ?

1. El paquete comienza en el desarrollo 0.0.0

2. ejecuta version devuelve el golpe basado en PR, devuelve cualquier cosa (parche, menor, mayor) - digamos que es un parche

3. Creación de registro de cambios - (0.0.0-desarrollo => 0.0.0). ¿Pero no quieres que eso suceda? En su lugar, agregue bajo el título del registro de cambios '0.0.0-development'?

4. publicar hooks time - sería 0.0.0-development => 0.0.0 y publicar. pero desea que se detecte development y omita el paso de publicación todos juntos

5. hacer una versión de github: en lugar de crear una nueva versión, actualice la anterior con las nuevas confirmaciones

6. El paquete permanece en desarrollo 0.0.0 hasta ??? mientras los cambios se acumulan

Dos opciones si eso es lo que quieres:

1. Simplemente no ejecute auto shipit hasta que desee comenzar a publicar y publicar. Aún agregue las etiquetas a sus RP. Cuando esté listo, agregue auto shipit a su proceso de CI e incluirá todas las etiquetas PR en su primera versión.

2. Escribe un complemento. Este comportamiento es bastante único y realmente no se ajusta a la forma en que npm hace el control de versiones. Creo que podrías crear un complemento para lograr estas cosas. Aunque probablemente tendría que agregar uno o dos ganchos para que los utilices.

Un paquete con una versión de 0.0.0-development indica lo siguiente:

• La versión NPM más alta publicada se considera la "versión actual".
• El version en package.json nunca debe cambiarse

Cuando se deba publicar una nueva versión de NPM, Auto debe incrementar la "versión actual" usando npm version $(auto version) .

El registro de cambios usa la "versión actual" de NPM (en lugar de package.json ).

Como siempre, se crea una nueva versión de Github para cada versión de NPM.

¿Estoy siendo lo suficientemente claro?

La versión en package.json nunca debe cambiarse

Para publicar nuevas versiones en NPM, debe cambiar esto. La única forma de incrementar la "versión actual" y nunca cambiar la local sería:

• cámbielo a la versión actual (NPM)
• hacer el golpe
• cámbialo de nuevo
• pero dado que la etiqueta sería la versión actual de golpe, ¿???

Estoy bastante seguro de que entiendo su caso de uso.

una. no desea publicar un montón de versiones mientras desarrolla una función en múltiples PRS
B. Una vez que se publique una nueva versión, desea que se incluyan todos los cambios.

En mi opinión, ya te damos dos formas de hacer esto:

1. use onlyPublishWithReleaseLabel . las nuevas versiones no se crean hasta que agrega esta etiqueta. Por lo tanto, podría ver cualquier PR / código sin la etiqueta como VERSION-development

2. a medida que fusiona PR para la función grande, use skip-release hasta que esté listo para una versión, luego simplemente combine un PR. La nueva versión contiene todos los RP omitidos. En este caso, puede considerar agregar la etiqueta skip-release como lo que significa que su versión es VERSION-development

¿En qué se diferencia esto del comportamiento que desea?

Me parece que se reduce a: desea agregar -development a su versión para comenzar a omitir versiones y eliminarla cuando esté listo para que todos los cambios se publiquen a la vez.

para lograr mi última oración, probablemente podría crear un complemento que use beforeShipit para verificar la presencia -development en la versión y arroje un error si está presente. Esto evitaría que shipit avance hasta que elimine -development .

El único problema que veo con esto es que también fallaría el trabajo de CI.

Interesante interpretación, pero no exactamente lo que pretendía. 😅

Básicamente estoy describiendo cómo funciona semantic-release .

_Debería_ haber dicho "La versión en package.json solo se cambia temporalmente para que npm publish tenga éxito" (en lugar de "La versión en package.json nunca debería cambiarse"). Todo lo que realmente estoy tratando de hacer es evitar el compromiso de golpe por completo. :)

Ok, entonces el estado en el que terminarías es:

repositorio: solo tiene la versión 0.0.0-dev

npm: tiene la versión real todo el tiempo (esto es lo que se usa para cualquier cosa)

¿correcto?

Más o menos como

        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'
        ]);
      }

¡Sí, se ve bien!

auto v4.0.0 aquí vamos jajaja. Parece que tendré que dividir el gancho publish . Este será otro complemento

Si lo desea, puede hornear esta función en Auto por ahora y esperar a dividir el gancho publish hasta que otro complemento lo necesite también. 😛

Esto debería ser posible a través del complemento ahora con # 247 (la capacidad de semver). El mensaje de confirmación requiere algunos cambios de configuración y realmente no te da mucho. ¡Cerrado pero abierto a relaciones públicas!