Auto: El complemento npm no aumenta la versión en package.json

Esto es por diseño. Si la versión está confirmada, puede dar lugar a conflictos de fusión al fusionar con el maestro. Sin embargo, hay una etiqueta git que se crea

Este problema también me está afectando.

Esto es por diseño. Si la versión está confirmada, puede dar lugar a conflictos de fusión al fusionar con el maestro. Sin embargo, hay una etiqueta git que se crea

¿Cuál es el enfoque recomendado para garantizar que las versiones package.json permanezcan sincronizadas con las implementaciones de CI usando auto shipit ?

No estoy seguro de entender bien el caso de uso @smithki. El caso de uso de @thuringia tiene sentido, necesita la versión para actualizar otras cosas, pero soy bastante reacio a cambiar el comportamiento. ¿Puede detallar lo que está tratando de lograr?

Lo siento, puede que tenga un malentendido. Por la redacción del problema, supongo que las sucursales de next no reciben versiones package.json actualizadas, pero las sucursales de main sí las reciben (todavía están aprendiendo auto principiante total aquí) . Mi caso de uso es el mismo que en el problema original, pero para ser específico:

Necesito que me lean la versión package.json en _build_ time para una biblioteca NPM para que la versión actual package.json pueda inyectarse como variable de entorno. Esto significa que necesito versionar los archivos package.json antes de que se ejecute la compilación. Simplemente importar package.json no funciona bien con mi configuración actual de TypeScript, que depende de rootDirs en tsconfig.json (y package.json no está incluido en rootDirs , por lo tanto, un error del compilador, por lo tanto, la necesidad de una variable de entorno).

¿Podrías hacer lo que hace auto ? https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306 -L310

Veré si puedo solucionarlo, no mi intención de descarrilar el tema original de este problema.

¿Podrías hacer lo que hace el auto? https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306 -L310

Desafortunadamente no, porque el código está diseñado para ejecutarse en el lado del cliente (abriré un nuevo problema si no encuentro una solución).

Ah, otro voto para que arregle el comportamiento de prueba más temprano que tarde. Echaremos un vistazo a arreglar todo eso el próximo fin de semana. ¡Gracias por los comentarios y por usar auto !

@hipstersmoothie Gracias por la rápida respuesta :) Siempre me sorprendes

Encontré una solución bastante sólida por ahora, auto shipit --dry-run --plugins git-tag . De todos modos, eso tiene mucho sentido para verificar la próxima versión de esta manera para ver si hay prelanzamientos.
Gracias por probar las mejoras de ejecución en seco tan pronto. Si hay una construcción canary que quieras probar, avísame. Estaré feliz de ayudar.

En cualquier caso, ¡muchas gracias por auto ! Hizo mi vida mucho más fácil

@thuringia @smithki ¿Podrías probar y ver si v10 resuelve tus problemas?

@hipstersmoothie Esto funciona bien en v10 👍
Sin embargo, es notablemente más lento, o más bien lleva tanto tiempo como ejecutar shipit sin --dry-run .

¡Gracias por publicar esto tan rápido!

No estoy seguro de si eso es un error o no:
Cuando actualicé los paquetes usando yarn add -D auto@next , los cambios a package.json y yarn.lock desaparecieron después de ejecutar auto shipit --dry-run . v10 todavía estaba en mi node_modules por lo que parece que se restableció el directorio de trabajo.

Sin embargo, es notablemente más lento, o más bien lleva tanto tiempo como ejecutar shipit sin --dry-run.

Veré si puedo mejorar eso. pero como estamos llamando al complemento ahora, está haciendo mucho más trabajo para imprimir las próximas versiones reales.

los cambios en package.json y yarn.lock desaparecieron después de ejecutar auto shipit --dry-run

Ah, esto es un error. para la ejecución en seco, me salté la verificación limpia pero no me salté el reinicio de git

@thuringia ¿Qué tipo de proyecto estás lanzando?

@hipstersmoothie Estoy completamente de acuerdo con que las carreras en seco sean más lentas ahora. No es una gran diferencia. Lo dije principalmente como un comentario de que sientes un cambio, tal vez debería haber agregado un emoji allí 😄
Sin embargo, cualquier mejora en el rendimiento siempre es bienvenida.

En este caso, es un proyecto mixto que consiste principalmente en una aplicación Java con algunas lambdas alrededor. Para crear una versión tengo que:

• Ejecute gradle para construir el jar con el número de versión
• empaquetar ese jar en una imagen de Docker, etiquetarlo y publicarlo
• implementar lambdas usando un marco sin servidor que usa el número de versión para etiquetar y configurar los contenedores

No es realmente un caso de uso predeterminado para auto 😂
Por lo general, lo uso para proyectos Node o React con configuraciones más optimizadas, pero nunca necesité obtener un número de versión antes de publicar el lanzamiento como lo necesito para este proyecto en particular

: rocket: El problema se publicó en v10.0.0 : rocket: