Definitelytyped: Por que monorepo?

1. Você pode navegar diretamente para a pasta em types . Por exemplo, para ver os tipos de jquery , navegue para https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery .
2. Você pode pesquisar o nome da biblioteca. Por exemplo, se você deseja pesquisar problemas em aberto relacionados a lodash , você pode ir para https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% 3Aissue + é% 3Aopen + lodash ; ou você pode usar a barra de pesquisa, que o redirecionará para a string de consulta apropriada.

Este monorepo não é uma bagunça total?

A maneira mais fácil de fazer isso é usar o TypeSearch . Você descobrirá se os tipos estão no registro e, se estiverem, o link na descrição do npm apontará exatamente para sua subpasta.

Non-monorepo é um non starter. Freqüentemente, contribuidores que modificam algo em um pacote @types precisarão modificar vários pacotes downstream para consertar quebras ou habilitar novas funcionalidades; este é um fogo de dumpster absoluto com o fluxo de trabalho do GitHub, pois não há uma maneira integrada de mesclar esses PRs de forma atômica enquanto ainda executa construções de CI sensatas em todos eles. Se você acha que olhar para 4.000 pastas é um problema, imagine- nos tentando manter as configurações do GitHub sincronizadas em 4.000 repositórios.

Freqüentemente, contribuidores que modificam algo em um pacote @types precisarão modificar vários pacotes downstream para consertar quebras ou habilitar novas funcionalidades

Não estou familiarizado com a escrita de @types/ pacotes, então pode estar faltando alguma coisa ...

Mas não é para isso que serve o
O que há de tão especial na implementação do pacote @types/ comparação com qualquer outro pacote no npm?

Espero que funcione da mesma forma: gráfico de dependência onde você tem, por exemplo. pacote @types/X e pacote downstream @types/Y que usa @types/X . Ambos mantidos por pessoas diferentes. Quando @types/X mudou, ele é publicado com uma versão diferente, então não afetaria imediatamente @types/Y . O colaborador de @types/Y posteriormente decide atualizar para a versão mais recente de @types/X e corrige problemas devido a todas as alterações importantes.

Provavelmente além disso você tem DefinitelyTyped meta-repositório, que mantém apenas uma lista de links para repositórios de tipos. E então algum script publisher que vai pela lista e publica todos os pacotes sob @types/ npm-namespace.

Ou, se for possível, apenas permita que os implementadores publiquem diretamente no namespace @types . Portanto, não precisamos de DefinitelyTyped meta-repo.

https://github.com/npm/npm também questões 2k.
https://github.com/moby/moby ainda mais.

A melhor solução é o autor manter a definição, o que sempre foi incentivado.

@franklinyu O número de problemas não é o que está em questão. Levando em consideração que esse repo agrega mais de 4k tipificações, esse grande número de problemas está ok.

A verdadeira questão é: que problema DefinitelyTyped tentando resolver agregando todas as digitações em um repo?

Infelizmente, o semver não funciona bem para pacotes de digitação. A versão major.minor do pacote types precisa corresponder ao major.minor do pacote javascript, caso contrário as pessoas não terão ideia de qual @types versão usar para qualquer versão de pacote javascript.

Por exemplo, neste momento, se você instalar [email protected] , também deverá instalar @types/[email protected] (agora está em 4.14.109 ). No entanto, imagine que há um bug nos tipos lodash (e, acredite, isso acontece com frequência) e alguém o corrige. Agora, para onde aumentamos o número da versão? Por definição, qualquer mudança nas definições de tipo é uma mudança de quebra de interface (ou pelo menos uma adição de interface). Mas não podemos aumentar a versão para 4.15.0 porque esses tipos são para 4.14 , não 4.15 . E certamente não queremos aumentar o número da versão para 5.0.0 . Então, em vez disso, aumentamos o número da versão para 4.14.110 , embora tenha havido uma mudança na interface, porque na verdade a interface antiga era apenas imprecisa.

@ aj-r Ok, major.minor versão de @type/X deve ser igual a major.minor versão de X , e se houver um bug em @type/X você usa a versão patch para consertá-lo. Isso parece certo.

O que isso tem a ver com a pergunta original: monorepo vs. repositórios separados?

Desculpe, eu deveria ter sido claro - eu estava falando sobre um de seus comentários anteriores:

Mas não é para isso que _semver_ serve?

qual problema DefinitelyTyped tentando resolver agregando todas as digitações em um repo?

O problema é dividir DT em 4000 repos GitHub separados vai resolver?

Todos os dias, um membro da equipe do TypeScript gerencia o backlog de RP, mesclando ou revisando várias dezenas de RPs. Um bot controla o grande volume de PRs que recebemos. Executamos regras de lint em todo o repositório que detectam erros comuns e ativamos novas regras de lint regularmente quando pensamos em outras que podem ajudar. Encontramos e corrigimos definições com coisas quebradas por versões futuras do compilador.

Dividir isso em milhares de sub-repos torna tudo mais difícil e nada mais fácil. Então, por que faríamos isso?

Qual é o problema de dividir o DT em 4.000 repositórios GitHub separados?

1. Como usuário, você acessa as fontes com mais rapidez. Você não precisa usar nenhum aplicativo adicional como o TypeSearch para acessar as fontes. No npm, você tem um link direto para o repositório de digitação necessário.

2. Como usuário, é mais fácil ver os problemas atuais e apresentar um novo.

   • Você não precisa pesquisar e filtrar em um repositório enorme com mais de 2k de problemas. E se o repórter se esquecer de seguir as regras de nomenclatura de problemas (ou seja, [@types/name-of-package] Issue description )? Você nunca encontra os problemas necessários.
   • Como tal, é menos possível arquivar duplicatas.

3. Como contribuidor, você pode monitorar claramente quantos problemas você tem em seu repositório.

   • Você não precisa (novamente) filtrar nada para obter problemas para sua digitação concreta. Menos possível perder questões necessárias.
   • Você tem uma motivação clara para manter o número de questões baixo. O número dos problemas não é mais responsabilidade compartilhada.
   • Como tal, é menos possível ter esquecido questões penduradas lá por anos .
     Por exemplo. há 1 página de edição de 2013, 5 páginas de edição de 2014 e assim por diante.

4. Como membro da equipe TypeScript, você gastou mais tempo aprimorando a própria digitação (por exemplo, suporte a jsdoc), em vez de manter / fundir / revisar milhares de tipificações para muitos pacotes npm por aí.
   Em um ecossistema maduro, isso é o que a comunidade deve fazer.

   • Executamos regras de lint em todo o repositório que detectam erros comuns

     Vamos lançar a predefinição do lint com todas as regras recomendadas e aconselhar todos os contribuidores a usar a versão mais recente dessa predefinição.

   • Encontramos e corrigimos definições com coisas quebradas por versões futuras do compilador.

     Isso é o que os colaboradores da comunidade devem fazer. A versão do ts-compiler esperado deve ser claramente indicada na seção peerDependency de package.json do pacote de digitação, de forma que ele avisa quando você o usa em um ambiente errado.

Você está abordando isso com a mentalidade de que as tipificações são, na verdade, propriedade de qualquer pessoa. A realidade é que a grande maioria dos arquivos neste repositório foi escrita uma vez por alguém que administrava o dts-gen e o verificou com alguns ajustes, depois foi retocado uma vez por ano por três outras pessoas. Não há um modelo de propriedade forte aqui, nem precisa haver.

O que acontece quando o "proprietário" autodeclarado ad-hoc de um desses repositórios decide parar de mantê-lo? Isso acontece o tempo todo . Como rastreamos qual repo é o "melhor" atual? O que acontecerá se eles começarem a mesclar alterações que resultam em coisas que não podemos publicar no NPM?

Isso também piora a vida das pessoas que desejam enviar correções. No ano passado, adicionamos um parâmetro de tipo ao arquivo de definição do React que exigia alterações posteriores em várias centenas de arquivos. Alguém deseja clonar várias centenas de repositórios (oh, e quais repositórios?) Para fazer uma mudança ampla e, em seguida, gerenciar várias centenas de solicitações de pull simultâneas? Não há ferramentas para isso em lugar nenhum.

Como membro da equipe TypeScript, você gastou mais tempo aprimorando a própria digitação (por exemplo, suporte a jsdoc), em vez de manter / fundir / revisar milhares de tipificações para muitos pacotes npm por aí. Em um ecossistema maduro, isso é o que a comunidade deve fazer.

Nós literalmente tentamos isso e não funcionou. O DT era exclusivamente direcionado à comunidade e resultou em uma lista de pendências de centenas de solicitações de pull. Desde então, o tempo médio para fundir um PR caiu de 2 semanas para 4 dias (o que é um mínimo intencional para que as pessoas tenham tempo para avaliar as mudanças), embora o volume de PR tenha ido de ~ 200 / mês para ~ 1.000 / mês .

Ok, acho que tenho a resposta para minha pergunta original "Por que monorepo?":
Porque é apenas mais fácil para a equipe do TypeScript manter as definições de tipo (considerando dependências de tipo, atualizações atômicas para pacotes downstream, CI, linting etc.)

Ainda acho que o modelo em que a equipe do TypeScript desempenha um papel importante na manutenção de milhares de pacotes, principalmente por conta própria, é um pouco estranho. Especialmente no mundo npm modular e voltado para a comunidade.

Mas se este modelo funcionar para você. Então ok: smiley:

@ art-in Não acredito que a intenção seja gerenciar todos os tipos deste repositório, é gerenciar tipos que não são fornecidos pelos próprios pacotes. Se um pacote deseja publicar tipos para seu pacote, isso pode ser feito diretamente no pacote. DefinitelyTyped é apenas um lugar onde os tipos podem ser agregados sem a necessidade de consentimento do mantenedor do pacote original.