Auto: "auto canary" en monorepo con la versión beta está fallando

Además, el campo publishConfig.directory en el package.json cada paquete no se está respetando.

¡Echaré un vistazo a esto!

1. La versión está pasando de 9.0.0-beta.33 a 9.0.1-canary.809.1.1a2be58f.0 cuando debería ser 9.0.0-canary ... en su lugar.

Abrí el # 609 para deshacerme del hash extra que hay allí. La parte .0 de la versión se debe a que tenemos la bandera --preid . Necesitamos esto para el resto de la versión, por lo que realmente no puede desaparecer.

@hipstersmoothie Oh, no me estaba quejando de eso. Simplemente no quería tomarme el tiempo para escribir el hash. 😆 Esa oración en realidad señala cómo es 9.0.1 cuando debería ser 9.0.0 todavía.

Ah, ya veo. En ese caso, ese es el comportamiento esperado. La versión canary es la versión "siguiente" simulada. Por ejemplo:

PR tiene major label => El canario con esos cambios contiene esos cambios importantes y debería ser una nueva versión principal

La razón por la que pasó a 9.0.1 es porque por defecto usamos patch cuando no se encuentra ninguna etiqueta.

Ah, OK. La etiqueta latest actualmente apunta a 8.0.27 , por lo que no esperaría que auto canary use 9.0.1 todos modos. Debe haber sido confundido por la existencia de 9.0.0-beta.33 . ¿Hay alguna forma de obligar a la versión a permanecer en 9.0.0 ?

La forma en que se comporta en este momento es que buscará en la "Versión más reciente" y su versión local y usará la superior. Entonces, en este caso, eso se resolvió en 9.0.0-beta.33 .

¿Hay alguna forma de obligar a la versión a permanecer en 9.0.0?

Localmente, si ejecuto lerna con prerelease lugar de preminor la versión no se incrementa. Para obtener prerelease en el comando canary, podríamos agregar una bandera adicional o usar una etiqueta prerelease , pero la función no sería automática.

No se puede publicar en npm, diciendo que no se puede publicar sobre las versiones publicadas anteriormente: 9.0.0-beta.33

Esto parece ser un problema en torno a los package.json s que se abren camino en la carpeta dist . El paso prepare se ejecuta antes de que lo haga cualquier cosa automáticamente, por lo que la versión es la que había al principio. En este caso "9.0.0-beta.33"

Cuando lerna se ejecuta, recoge esta versión obsoleta de package.json , que contiene una versión ya publicada, e intenta publicarla de nuevo.

Localmente, si ejecuto lerna con prerelease lugar de preminor la versión no se incrementa. Para obtener prerelease en el comando canary, podríamos agregar una bandera adicional o usar una etiqueta prerelease , pero la función no sería automática.

Eso debería ser suficientemente bueno. ¿Considera que "ejecutar auto canary localmente desde una sucursal que se basa en una versión beta / next " es un caso extremo? Si no es así, tal vez debería haber soporte automático aquí. Además, si tuviera que ejecutar auto canary desde CI, ¿seguiré encontrando este caso de borde?

Cuando lerna ejecuta, recoge esta versión obsoleta de package.json , que contiene una versión ya publicada, e intenta publicarla de nuevo.

Lerna admite publishConfig.directory (ver aquí ), pero tal vez su integración con Lerna esté evitando de alguna manera esa ruta de código.

Es esta línea la que es el problema.

Debido a que hace esto en el que copia el package.json, readme, etc.en la carpeta dist y luego simplemente lo publica, necesitamos ejecutar el script prepare en un momento muy específico:

1. lerna version - cambia package.json a la versión canary
2. prepare - paquete final colocado en la carpeta dist
3. lerna publish - publica la carpeta dist del paquete con la versión correcta

Entonces, para este flujo de trabajo, debe dejar que se ejecuten los scripts del ciclo de vida y ignoreScripts debe establecerse en falso (o simplemente no en absoluto).

¿Considera que "ejecutar auto canary localmente desde una sucursal que se basa en una versión beta / próxima" es un caso extremo? Si no es así, tal vez debería haber soporte automático aquí.

El soporte beta / next todavía no está integrado, pero volveré a este problema cuando intente abordarlo.

tal vez su integración con Lerna esté evitando de alguna manera esa ruta de código.

No estamos haciendo suposiciones sobre el uso de lerna, por lo que esto no debería ser un problema. Puede ver aquí que solo estamos llamando a lerna para hacer todo el trabajo pesado.

@aleclarson Pude publicar un canario después de eliminar ignoreScripts . Creo que he abordado todo en este número, si lo he hecho, por favor cierre.

¡Está bien, dulce! Tengo una solución alternativa en este momento, por lo que no la revisaré pronto.

Me aseguraré de volver a abrir si puedo intentarlo de nuevo. ;)