Auto: Utilice npm como fuente de la versión de la verdad

Oooh me gusta eso. Sin embargo, esto podría ser complicado para los monorepos.

Como hacemos --force-publish=* para lerna, no debería ser un problema ya que todos los paquetes deberían tener una versión vinculada.

En el futuro, si eliminamos esa bandera, tendríamos que ... idk

Además, solo ejecutamos npm version que solo toma una cadena semver. En realidad, no establecemos un número de paquete en ningún lugar en este momento. No sería difícil configurarlo nosotros mismos, pero los monorepos nuevamente parecen que no serían simples

La mayoría de los comandos también funcionan con etiquetas, por lo que si la versión no se etiquetó, podría causar algunos problemas.

https://github.com/azu/can-npm-publish

"Estoy cada vez más convencido de que el modo de control de versiones" independiente "fue un error. Todo lo que hace es hacer que la gente arroje paquetes aleatorios en un solo repositorio y luego se quejen cuando tienen que versionarlos al mismo tiempo". ~ del mantenedor de lerna.

Entonces --force-publish=* parece estar bien.

--force-publish y el control de versiones independiente no son lo mismo.
De forma predeterminada, lerna solo publicará una actualización de un paquete si tiene cambios, al usar --force-publish=* forzamos a lerna a publicar una versión de todos los paquetes incluso si no hay cambios desde la última publicación.

es decir, el paquete A tiene cambios, B no. lerna solo publicará una nueva versión de A ( B permanecerá en su versión actual). El próximo lanzamiento A y B tienen cambios, ambos se publicarán con la misma nueva versión.

Algo en lo que he estado pensando (y no estoy seguro de si esto es algo que apoyaríamos) es el potencial de lanzamientos que no son master (o la rama principal). Hasta este punto, siempre hemos asumido que hay una ruta para las versiones, y siempre son lineales (usando la versión latest en npm o github).

¿Qué sucede en el caso de necesitar parchear una versión anterior? (1.x tiene un error, master está en 2.x pero también desea parchear 1.xw / una solución) Si nos salimos del lerna o pkg versión Creo que estaríamos bien. Las búsquedas de relaciones públicas calcularían un nuevo aumento de semver y lo aplicarían a la versión en la rama actual.

Si cambiamos esto para usar algo fuera del árbol de git, no creo que podamos soportar ese comportamiento, ya que solo hay 1 latest en npm (o donde sea que obtengamos la última versión)

Parece una buena característica. La implementación puede requerir algo de trabajo.

versión:

• Calculamos version usando la última versión. ¿Podría esto cambiar fácilmente a la versión del paquete?
• La última versión de github podría ser un problema. No creo que en realidad se pueda establecer mediante programación la "Versión más reciente". Entonces, al publicar un parche en 1.x, se convertiría en la última versión.

lanzamiento / registro de cambios

• getCurrentVersion devuelve lastRelease if gt (lastRelease, lastVersion), por lo que esto también debería tener en cuenta

esto significa que ya estamos usando cosas fuera del árbol de git, ¿verdad?

Necesitamos depender de latestRelease para estar seguros de que tiene una etiqueta git asociada, por lo que cambiar no es una opción porque no podemos estar seguros de que la última versión de npm tenga una etiqueta (como en lo que describe este problema) .

Creo que probablemente necesitemos una nueva bandera que tenga versiones de la última etiqueta de git. --from-git

Con eso, el comando de liberación probablemente funcionaría. Tendríamos que resolver cómo se ve el registro de cambios.

la bandera --from-git también podría anular la búsqueda de NPM para cualquier cosa. Creo que eso significa que podemos fusionarnos # 173