Auto: Múltiples complementos del administrador de paquetes en 1 repositorio

Pensándolo un poco más, probablemente tendría más sentido introducir una nueva opción de configuración de nivel superior.

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

Para lograr esto, creo que podríamos usar funciones de iterador para ejecutar shipit en varias cosas y generar la misma cantidad de confirmaciones

ex para la última:

1. correr todo al mismo tiempo
2. rendimiento antes de realizar el registro de cambios
3. cometer el registro de cambios de una vez
4. rendimiento hasta que la versión chocó
5. confirmar la versión si es necesario
6. corre hasta el final

Con esta configuración, realmente podría omitir a lerna todos juntos

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

Si no hay confirmaciones que coincidan con un package , no se realizaría ninguna liberación. Esto logra una gestión monorepo independiente de una manera mucho más sencilla y sin lerna . Si desea una versión fija de monorepo, ir por la ruta clásica sería el camino.

Otra característica interesante de esto es que podría tener dos proyectos leran en su repositorio con diferentes esquemas de control de versiones ( fixed y independent )

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

Esto significa que puede usar el complemento chrome-web-store y el complemento npm en un repositorio.

Supongo que te refieres a que _no puedes_ usar ambos en el mismo proyecto.

Actualmente, cada complemento se compromete, etiqueta y envía. esto crearía mucho ruido. probablemente tendría que mover esas acciones de git al núcleo para que solo suceda una vez? aunque es posible que desee confirmaciones separadas para cada paquete.

Puede tener sentido hacer un enfoque híbrido. ¿Quizás cada complemento se confirma, pero solo presionamos una vez?

No estoy realmente seguro de cómo funcionarían las etiquetas en el mundo donde cada carpeta es su propia versión empaquetada. ¿Creas una etiqueta para cada versión que haces? ¿Haces uno al final?

Pensándolo un poco más, probablemente tendría más sentido introducir una nueva opción de configuración de nivel superior.

Me gusta la idea de poder personalizar la experiencia de lanzamiento por paquete. Definitivamente puedo ver algunos beneficios de poder administrar una implementación de s3 / gh-pages para un paquete docs comparación con los paquetes de su biblioteca.

Una cosa que hay que manejar es la inclusión de un paquete en más de una canalización de versiones. Qué sucede en el caso de:

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

¿Se publica el paquete chrome-ext tanto en npm _ como en webstore ? ¿O gana el lanzamiento de npm porque se declara primero?

No estoy realmente seguro de cómo funcionarían las etiquetas en el mundo donde cada carpeta es su propia versión empaquetada. ¿Creas una etiqueta para cada versión que haces? ¿Haces uno al final?

Creo que podemos igualar el comportamiento de Lena. solo un montón de etiquetas en una confirmación. cada etiqueta se convierte en su propia versión

¿El paquete chrome-ext se publica tanto en npm como en la tienda web? ¿O gana el lanzamiento de npm porque se declara primero?

En ese caso sí intentaría hacer ambas cosas. Pero esa es una mala configuración. Puede usar eso como una característica y decir publicar un paquete en dos registros diferentes (por ejemplo, npm y registro de paquetes github)

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

Esto suena interesante ... y complicado 😅

Por lo general, prefiero tener configuración en lugar de tratar de ser demasiado inteligente con la detección (porque eso puede fallar de maneras inesperadas y ser difícil de probar).

Supongo que mi primera pregunta es cómo se ve el estado predeterminado de esto. Si solo tiene un complemento npm , ¿necesita agregar la configuración antes de que funcione? Misma pregunta con los demás.

En cuanto a la interacción de git, me parece que las interacciones de git generalmente deberían ser solo una parte de la canalización de complementos. Si un complemento necesita realizar una confirmación, solo debería poder acceder a un gancho comprometible. Sin embargo, es probable que la inserción solo se maneje en el núcleo, ya que tiene implicaciones en cosas como cómo se ejecuta CI.

Si solo tiene un complemento npm, ¿necesita agregar la configuración antes de que funcione?

La configuración que funciona hoy debería funcionar en packages world. Entonces no se requieren cambios. La mayoría de los cambios importantes se producirían en el lado de la API del nodo y no serían visibles para los usuarios normales.

Si un complemento necesita realizar una confirmación, solo debería poder acceder a un gancho comprometible.

Me gusta esta idea. Formalizar esta interacción de git dentro de auto probablemente sea útil. Y si no usan este gancho, solo significa un poco más de ruido (por ejemplo, un compromiso adicional y un empujón adicional)

También estaba pensando en cómo usar Auto con un monorepo y se me ocurrió un enfoque ligeramente diferente que puede funcionar para sus necesidades.

Básicamente, si tiene un monorepo, puede tener varios subdirectorios, cada uno de los cuales tiene su propio archivo .autorc que puede configurar los complementos que necesitaría cada subproyecto.

Luego, puede optar por tener un prefijo diferente para cada proyecto, de modo que cada proyecto se pueda publicar en diferentes momentos si es necesario. Por ejemplo, una versión del subproyecto1 podría etiquetarse con sub-project/v1.4.5 y otro proyecto obtendría la etiqueta sub-project2/v9.9.9

Luego, Auto puede usar algo como git describe --tags --matches "sub-project1/*" para obtener y actualizar etiquetas para cada proyecto en consecuencia.

Solo un pensamiento.

En realidad, eso se acerca bastante al enfoque que he estado adoptando. He
estado trabajando en esto esta semana.

Tuve que agregar esa bandera a algunos de los comandos hasta ahora (—coincidencias) y
ha ido bastante bien.

He optado por el enfoque de campo de "paquetes" y es básicamente
matriz de "autorc" s

Para obtener el prefijo, agregué un gancho para que los complementos proporcionen un nombre. Esta
también ayudará a la señalización automática si el complemento es compatible con múltiples paquetes

El miércoles 29 de enero de 2020 a las 21:11 Alejandro Barrientos <
[email protected]> escribió:

También estaba pensando en cómo usar Auto con un monorepo y se me ocurrió
un enfoque ligeramente diferente que puede funcionar para sus necesidades.

Básicamente, si tiene un monorepo, puede tener varios subdirectorios
que cada uno tiene su propio archivo .autorc que puede configurar cualquier complemento
cada subproyecto necesitaría.

A continuación, puede optar por tener un prefijo diferente para cada proyecto para que
cada proyecto puede publicarse en diferentes momentos si es necesario. Por ejemplo un
La versión del subproyecto1 podría etiquetarse con subproyecto / v1.4.5 y
otro proyecto obtendría la etiqueta subproyecto2 / v9.9.9

Entonces, Auto puede usar algo como git describe --tags --matches
"sub-project1 / *" para obtener y actualizar las etiquetas de cada proyecto en consecuencia.

Solo un pensamiento.

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMDVNW86
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

Volviendo y leyendo esto de nuevo, ¡estoy muy emocionado! Las múltiples etiquetas prefijadas con el nombre del paquete suenan realmente bien. Además, me gusta mucho el campo packages .

@hipstersmoothie, ¿hay alguna manera fácil hoy de publicar en registros de 2 npm con shipit que hayas visto? o alguna función alterna en automático de la que no tengo una buena descripción en este momento.

@vincentbriglia, ¿funcionaría un complemento que se publica en el paquete de GitHub? prácticamente podría aprovecharse del complemento npm. Sería fácil para la liberación de next y latest , los canarios no tienen tanto sentido. ¿Pensamientos?

@hipstersmoothie tenemos un caso en el que publicamos el mismo paquete en el registro NPM y el registro GHPR. La razón aquí es que el GHPR, aunque se anuncia como tal, no envía paquetes correctamente. El problema subyacente es que tenemos el mismo alcance en npm y github.

Desarrollamos principalmente a puertas cerradas, utilizamos las compilaciones canary para tener conversaciones / aprobaciones con nuestro equipo de diseño desde feature branches > next por lo que las compilaciones canary siguen siendo útiles para nosotros en este contexto. El complemento npm actualmente proporciona esta funcionalidad, por lo que sería una pena perderlo.

Supongo que el contexto con el uso de GHPR es generalmente que es la ubicación principal para publicar en el contexto de la "organización" privada y si un componente debe hacerse público, npmjs.org es secundario. (No he visto a nadie instalar componentes públicos desde github). En el contexto de código abierto, generalmente es npmjs, no GHPR u otro registro de paquete privado.

en una nota al margen, ya que menciona un complemento GHPR específico: hemos reservado algo de tiempo para la próxima semana para crear un complemento automático que eliminaría las versiones del paquete según algunas reglas (las organizaciones están limitadas a 50 Gb de paquetes, y eso incluye docker imágenes)

• eliminar el último canario en el rango
• eliminar enésimo último próximo en el rango
• ...

También esperaría felizmente contigo creando un editor de ghpr específico hasta que comience el trabajo en la v10, las ideas presentadas aquí parecen muy emocionantes y quizás sean más "a prueba de futuro".

Podríamos vivir sin publicar públicos y privados al mismo tiempo por el momento, pero al menos para que sepan que este es mi caso de uso.

Estaba pensando más en un complemento de "registro de paquetes secundarios". Por lo tanto, el complemento npm funcionaría como lo hace, publicando en cualquier registro que esté configurado. Luego, este nuevo complemento se publicaría en un segundo registro (no importa si es npm o ghpr) liberando las versiones que estén en la confirmación HEAD.

en una nota al margen, ya que menciona un complemento GHPR específico: hemos reservado algo de tiempo para la próxima semana para crear un complemento automático que eliminaría las versiones del paquete según algunas reglas (las organizaciones están limitadas a 50 Gb de paquetes, y eso incluye docker imágenes)

Esta parece una buena característica. ¡No sabía que existían esos límites!

este nuevo complemento se publicaría en un segundo registro (no importa si es npm o ghpr) liberando las versiones que estén en la confirmación HEAD

bueno, eso definitivamente funcionaría! editar: también para nuestro escenario (s)

¡Hola! ¿Cuál es el estado actual de Auto con respecto a este hilo? ¿Es posible publicar más de una cosa de la misma versión?

ya que cada complemento del administrador de paquetes se basa en algún archivo adicional para el administrador de paquetes (todos excepto git-tag )

Creo que esta es una suposición incorrecta. ¿El plugin docker depende de algún archivo? Puede que sea innecesario, así que quizás sea un mal ejemplo. Aquí hay otro entonces: estoy interesado en usar Auto con sbt (la herramienta de compilación más común para Scala) y no tiene ninguna configuración JSON / XML legible por máquina. Una compilación de sbt está configurada con código Scala y para extraer cualquier información sobre la compilación, necesitaría comunicarse con sbt de alguna manera.

Esto logra una gestión monorepo independiente de una manera mucho más sencilla.

También parece de este hilo que el objetivo es acomodar proyectos monorepo con múltiples subproyectos que tienen diferentes necesidades de publicación. ¿Qué pasa con un solo proyecto que produce diferentes tipos de artefactos? Por ejemplo, una imagen de Docker y un archivo de configuración (para cargar en algún lugar). O una acción de GitHub que se puede publicar como una biblioteca en NPM y como una acción en las versiones de GitHub.

Actualmente, cada complemento se compromete, etiqueta y envía. esto crearía mucho ruido. probablemente tendría que mover esas acciones de git al núcleo para que solo suceda una vez? aunque es posible que desee _compromisos separados para cada package .

Creo que este es el problema principal con la implementación actual de complementos. Esto se remonta a mi confusión acerca de la afirmación de que cada comando "solo hace una cosa realmente bien". En mi opinión, el gancho publish realmente debería _sólo publicar_ para el administrador de paquetes dado, no crear confirmaciones o insertar etiquetas git. Si cada complemento de publicación puede centrarse solo en la implementación de las especificaciones de su administrador de paquetes, las partes comunes del proceso se pueden reutilizar y / o compartir. ¿Todavía es posible lograr esto con Auto o está demasiado sesgado hacia los proyectos similares a NPM?