Definitelytyped: ¿Por qué monorepo?

1. Puede navegar directamente a la carpeta debajo de types . Por ejemplo, para ver los tipos de jquery , vaya a https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery .
2. Puede buscar el nombre de la biblioteca. Por ejemplo, si desea buscar problemas abiertos relacionados con lodash , puede ir a https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% 3Aissue + es% 3Aopen + lodash ; o puede utilizar la barra de búsqueda, que le redirigirá a la cadena de consulta adecuada.

¿No es este monorepo un desastre total?

La forma más sencilla de hacerlo es utilizar TypeSearch . Descubrirá si los tipos están en el registro y, si lo están, el enlace en la descripción de npm apuntará exactamente a su subcarpeta.

Non-monorepo es un nonstart. Con frecuencia, los contribuyentes que modifiquen algo en un paquete @types necesitarán modificar varios paquetes posteriores para corregir roturas o habilitar nuevas funciones; este es un auténtico basurero con el flujo de trabajo de GitHub, ya que no hay una forma integrada de fusionar esos PR de una manera atómica mientras se ejecutan compilaciones de CI razonables en todas ellas. Si cree que mirar 4.000 carpetas es un problema, imagínese que intentamos mantener la configuración de GitHub sincronizada en 4.000 repositorios.

Con frecuencia, los contribuyentes que modifiquen algo en un paquete de @types deberán modificar varios paquetes

No estoy familiarizado con la escritura de paquetes @types/ , por lo que es posible que me falte algo ...

¿Pero no es para lo que sirve semver ?
¿Qué tiene de especial la implementación del paquete @types/ , frente a cualquier otro paquete en npm?

Espero que funcione igual: gráfico de dependencia donde tienes, por ejemplo. paquete @types/X y paquete descendente @types/Y que usa @types/X . Ambos mantenidos por diferentes personas. Cuando @types/X cambia, se publica con una versión diferente, por lo que no afectaría inmediatamente a @types/Y . El colaborador de @types/Y más tarde decide actualizar a la versión más nueva de @types/X y soluciona problemas debido a todos los cambios importantes.

Probablemente, además de eso, tiene DefinitelyTyped meta-repositorio, que solo mantiene una lista de enlaces a repositorios de tipos. Y luego un script publisher que recorre esa lista y publica todos los paquetes en @types/ npm-namespace.

O si es posible, simplemente permita que los implementadores publiquen directamente en el espacio @types nombres DefinitelyTyped meta-repositorio en absoluto.

https://github.com/npm/npm también problemas de 2k.
https://github.com/moby/moby aún más.

La mejor solución es que el autor mantenga la definición, que siempre se ha fomentado.

@franklinyu El número de problemas no es lo que se cuestiona. Teniendo en cuenta que este repositorio agrega más de 4 k tipificaciones, esa gran cantidad de problemas está bien.

La pregunta real es: ¿qué problema DefinitelyTyped tratando de resolver agregando todos los mecanografiados en un repositorio?

Desafortunadamente, semver no funciona bien para paquetes de mecanografía. La versión major.minor del paquete de tipos debe coincidir con major.minor del paquete javascript; de lo contrario, la gente no tendrá idea de qué versión @types usar para cualquier versión de paquete javascript determinada.

Por ejemplo, ahora mismo si instala [email protected] , también instalaría @types/[email protected] (ahora mismo está en 4.14.109 ). Sin embargo, imagina que hay un error en los tipos lodash (y créeme, esto sucede muy a menudo) y alguien lo corrige. Ahora, ¿a qué le asignamos el número de versión? Por definición, cualquier cambio en las definiciones de tipo es un cambio que rompe la interfaz (o al menos una adición de interfaz). Pero no podemos aumentar la versión a 4.15.0 porque estos tipos son para 4.14 , no 4.15 . Y ciertamente no queremos aumentar el número de versión a 5.0.0 . Entonces, en su lugar, aumentamos el número de versión a 4.14.110 , aunque hubo un cambio de interfaz, porque en realidad la interfaz anterior era inexacta.

@ aj-r Ok, major.minor versión de @type/X debería ser igual a major.minor versión de X , y si hay un error en @type/X usas la versión patch para solucionarlo. Eso suena bien.

¿Qué tiene eso que ver con la pregunta original: monorepo vs repositorios separados?

Lo siento, debería haber sido claro, estaba abordando uno de sus comentarios anteriores:

¿Pero no es para lo que sirve _semver_?

¿Qué problema DefinitelyTyped tratando de resolver agregando todos los mecanografiados en un repositorio?

¿Qué problema va a resolver dividir DT en 4000 repositorios de GitHub separados?

Todos los días, un miembro del equipo de TypeScript gestiona la acumulación de relaciones públicas, fusionando o revisando varias docenas de relaciones públicas. Un bot controla el enorme volumen de relaciones públicas que obtenemos. Ejecutamos reglas de pelusa para todo el repositorio que detectan errores comunes y activamos nuevas reglas de pelusa con regularidad a medida que pensamos en las que podrían ayudar. Encontramos y arreglamos definiciones con cosas rotas por futuras versiones del compilador.

Dividir esto en miles de subrepos hace que todo sea ​​más difícil y nada más fácil. Entonces, ¿por qué lo haríamos?

¿Qué problema va a resolver dividir DT en 4000 repositorios de GitHub separados?

1. Como usuario, llega a las fuentes más rápido. No tiene que usar alguna aplicación adicional como TypeSearch para llegar a las fuentes. En npm tiene un enlace directamente al repositorio de escritura necesario.

2. Como usuario, es más fácil ver los problemas actuales y presentar uno nuevo.

   • No tiene que buscar y filtrar en un gran repositorio con más de 2k problemas. ¿Qué pasa si el reportero se olvida de seguir las reglas de nomenclatura de los problemas (es decir, [@types/name-of-package] Issue description )? Nunca encuentras los problemas necesarios.
   • Como tal, es menos posible archivar duplicados.

3. Como colaborador, puede controlar claramente cuántos problemas tiene en su repositorio.

   • No tiene que (nuevamente) filtrar nada para obtener problemas para su escritura concreta. Es menos posible pasar por alto los problemas necesarios.
   • Tienes una motivación clara para mantener el número de problemas bajo. El número de problemas ya no es responsabilidad compartida.
   • Como tal, es menos posible haber olvidado cuestiones pendientes durante años .
     P.ej. hay 1 página de edición de 2013, 5 páginas de edición de 2014 y así sucesivamente.

4. Como miembro del equipo de TypeScript, dedicó más tiempo a mejorar el mecanografiado en sí (por ejemplo, el soporte de jsdoc), en lugar de mantener / fusionar / revisar miles de mecanografiados para muchos paquetes npm disponibles.
   En un ecosistema maduro, eso es lo que debería hacer la comunidad.

   • Ejecutamos reglas de pelusa en todo el repositorio que detectan errores comunes

     Bueno, libere el ajuste preestablecido de pelusa con todas las reglas recomendadas y aconseje a todos los colaboradores que utilicen la última versión de ese ajuste preestablecido.

   • Encontramos y arreglamos definiciones con cosas rotas por futuras versiones del compilador.

     Eso es lo que deben hacer los colaboradores de la comunidad. La versión del compilador ts esperado debe indicarse claramente en la sección peerDependency de package.json de typing-package, por lo que le advierte cuando lo usa en un entorno incorrecto.

Te estás acercando a esto desde la mentalidad de que las mecanografías en realidad son propiedad de cualquiera. La realidad es que la gran mayoría de los archivos de este repositorio fueron escritos una vez por alguien que ejecutó dts-gen y los revisó con algunas correcciones, y luego tres personas más los retocaron una vez al año. Aquí no existe un modelo de propiedad sólido, ni es necesario que lo haya.

¿Qué sucede cuando el "propietario" autoproclamado ad-hoc de uno de estos repositorios decide dejar de mantenerlo? Esto pasa todo el tiempo . ¿Cómo hacemos un seguimiento de qué repositorio es el "mejor" actual? ¿Qué sucede si comienzan a fusionar cambios que dan como resultado cosas que no podemos publicar en NPM?

Esto también empeora la vida de las personas que desean enviar correcciones. El año pasado agregamos un parámetro de tipo al archivo de definición de React que requería cambios posteriores en varios cientos de archivos. ¿Alguien quiere clonar varios cientos de repositorios (oh, y qué repositorios) para realizar un cambio generalizado y luego administrar varios cientos de solicitudes de extracción simultáneas? Ni siquiera hay herramientas para esto en ninguna parte.

Como miembro del equipo de TypeScript, dedicó más tiempo a mejorar el mecanografiado en sí (por ejemplo, el soporte de jsdoc), en lugar de mantener / fusionar / revisar miles de mecanografiados para muchos paquetes npm disponibles. En un ecosistema maduro, eso es lo que debería hacer la comunidad.

Literalmente intentamos esto y no funcionó. DT fue impulsado únicamente por la comunidad y resultó en una acumulación de solicitudes de extracción de cientos de personas. Desde entonces, el tiempo promedio para fusionar un RP ha caído de 2 semanas a 4 días (que es un mínimo intencional para que la gente tenga tiempo para evaluar los cambios), aunque el volumen de RP ha pasado de ~ 200 / mes a ~ 1000 / mes .

Ok, creo que tengo la respuesta a mi pregunta original "¿Por qué monorepo?":
Porque es más fácil para el equipo de TypeScript mantener las definiciones de tipo (considerando dependencias de tipo, actualizaciones atómicas para paquetes posteriores, CI, linting, etc.)

Sigo pensando que el modelo en el que el equipo de TypeScript asume un papel tan importante en el mantenimiento de miles de paquetes en su mayoría por sí mismo es un poco extraño. Especialmente en el mundo npm modular, impulsado por la comunidad.

Pero si este modelo te funciona. Entonces ok: smiley:

@ art-in No creo que la intención sea administrar todos los tipos de este repositorio, es administrar los tipos que no proporcionan los paquetes en sí. Si un paquete desea publicar tipos para su paquete, puede hacerlo directamente en el paquete. DefinitelyTyped es solo un lugar donde los tipos se pueden agregar sin necesidad de consentimiento del mantenedor del paquete original.