Definitelytyped: META - Atualizando a versão mínima do TypeScript

Quando foi adicionado unknown ? Vá grande ou vá para casa! Todo o any no DT é de longe a maior fonte de bugs "typescript shoulda catch it" nestas partes.

Quando foi adicionado unknown ?

3,0

tu. Então, 99,9%!

Concordo que devemos fazer isso. Vamos fazer isso!

Por favor, você poderia aumentá-lo lentamente ao longo do tempo? 2,1 um mês, 2,2 no próximo e assim por diante?

Cada versão tem algumas pequenas mudanças de quebra. Será mais fácil entender os problemas que isso traz indo devagar e metodicamente no início.

Os projetos no modo de manutenção geralmente não têm largura de banda para superar essas mudanças importantes, especialmente se forem essenciais para a infraestrutura.

Sim, por favor, os tipos node em particular sofreram com a falta de recursos mais novos e muitas soluções ~hacks~ tiveram que ser usadas.

Projetos @JoshuaKGoldberg no modo de manutenção provavelmente não atualizarão versões de definições de tipo mês após mês, certo?

@JoshuaKGoldberg lembre-se de que atualizar o DT não remove as definições de tipo histórico que já foram publicadas no npm. As versões históricas de @types vivem para sempre como Mumm-Ra.

Você poderá depender deles, independentemente de onde o DT vá em termos de versão.

Faz sentido

Olá @RyanCavanaugh ,
Eu apoio essa ideia 100%. O TypeScript v2.0 é um bloqueador para um melhor sistema de tipos para muitos pacotes, incluindo node .
Preocupo-me com transparência e previsibilidade para a comunidade e negócios . Há perguntas:

• Quando você acha que é uma boa hora mudar a versão mínima do TypeScript com suporte? Durante a versão TS 3.7?
• Corrija-me se estiver errado, mas isso parece o fim da vida útil das versões do TypeScript anteriores à 2.8?
• Poderíamos ter um cronograma semelhante ao Node.js ? Esse documento ajudará as equipes de desenvolvimento a pressionar as empresas a aprovar os recursos de desenvolvimento para atualização.

Alguma razão pela qual é 2.8 e não uma versão diferente? (Por exemplo, 3,0 por unknown .)

2.8 é quando os tipos condicionais foram introduzidos

Muito a favor.

Por favor, enquanto você está nisso, considere configurar um cronograma (semi-)formal para que a comunidade possa contar com o aumento previsível da versão mínima ao longo do tempo. Algo como: "Todos os anos, em novembro, planejamos atualizar a versão datilografada mínima para o lançamento de 18 meses antes. Planeje de acordo."

@donaldpipowitch
Dos usuários pré-3.0, vimos um grupo de pessoas ainda no 2.8. (E, é claro, os tipos condicionais tornam 2,8 um alvo popular para os tipos DT, como aponta @IllusionMH .)

Esperamos revisitar esse problema periodicamente porque esperamos que as pessoas continuem atualizando.

@galkin
Tecnicamente, as versões antigas do Typescript não são atendidas, e essa alteração é a interrupção do serviço do Definitivamente Typed. E, claro, as versões antigas do Typescript podem continuar a obter as versões existentes dos pacotes DT. Eles simplesmente não receberão atualizações.

No entanto, isso é apenas um detalhe técnico. Seria uma boa ideia produzirmos um cronograma semelhante ao LTS. Ainda não começamos nada assim. Nesse caso, os dados eram claros o suficiente para facilitar a decisão post-hoc. Ainda não tenho certeza de como prever uma boa data para descontinuações futuras.

Re: a data: Eu tenho que atualizar a infraestrutura do DT para o 3.7 de qualquer maneira, então isso acontecerá no dia do lançamento do 3.7 como parte do lançamento.

Seria uma boa ideia produzirmos um cronograma semelhante ao LTS.

Só queria dizer que acho que esse tipo de cronograma é uma ideia realmente sólida.

@johnnyreilly , estamos procurando precedentes na Microsoft. Mas não há nada como Definitivamente Digitado!

@RyanCavanaugh , alguma atualização?

@galkin se você tiver um cronograma de suspensão de uso proposto, poste-o neste tópico para que possamos discutir.

@sandersn , aqui estão meus pensamentos sobre esse problema

• Precisamos do Fim da vida útil (EOL) para a versão TypeScript?
  Claro que sim. O suporte a todas as versões do TypeScript criadas requer recursos excedentes.
• Por que devemos ter cronograma EOL?
  _A melhor prática é ser direto e claro com o estado de seus projetos. Se você não está mais dando suporte a um projeto, ou está no processo de finalizá-lo, torne isso dolorosamente óbvio para qualquer um que tropeçar em seu código_ (c) Jared Smith.
• O que deve ser usado como base para o cronograma?
  Análise? Toda decisão baseada em análises é um compromisso. Cada uma dessas decisões é uma resposta à pergunta sobre qual parte da comunidade/negócio vamos provocar. O WordPress tem um problema semelhante sobre qual versão mínima do WP/PHP/MySQL eles devem suportar. É uma maneira perigosa.
  Cronograma de ferramentas dependentes? Código Visual/Microsoft Azure/Angular/etc. Muitas opções e muito fácil iniciar uma nova guerra santa.
  Processo TC39? Boa opção, mas o TC39 não introduz e não introduzirá EoL para nenhum recurso de idioma.
  Node.js? Node.js é um driver para a comunidade JS com agendamento de lançamento/EOL. O TypeScript usa Node.js. Eu vejo isso como a melhor base para o cronograma.
• Como criar o cronograma?
  Opção 1. Associe a versão do TypeScript à versão do Node.js e anuncie EOL semelhante. Por exemplo, há 2 anos, o Node.js v8 iniciou o LTS e o TypeScript v2.6 foi lançado , então 2019.12.31 é EOL.
  A opção 2 Node.js tem uma política de 12 + 18 meses antes da EOL. Podemos usar a mesma abordagem, 2,5 anos. Pode ser muito longo, mas não menos de 2 anos.
  Opção 3 Faça uma reunião com os tomadores de decisão e compartilhe com a comunidade o resultado como foi

Então minha proposta é mais ou menos assim:

versão | Lançado | Fim da Vida em 2,5 anos | Fim da vida em 2 anos
-- | -- | -- | --
2.1 | Dezembro 2016 | Junho de 2019 | Dezembro de 2018
2.2 | Fevereiro 2017 | agosto de 2019 | fevereiro de 2019
2.3 | abril de 2017 | Setembro 2019 | abril de 2019
2.4 | Junho de 2017 | novembro de 2019 | Junho de 2019
2.5 | agosto de 2017 | Janeiro 2020 | agosto de 2019
2.6 | Outubro 2017 | março de 2020 | outubro de 2019
2.7 | Janeiro de 2018 | Julho 2020 | Janeiro de 2020
2.8 | março de 2018 | agosto 2020 | fevereiro de 2020
2.9 | Maio de 2018 | Outubro 2020 | abril de 2020
3 | julho de 2018 | Dezembro 2020 | Junho de 2020
3.1 | Setembro 2018 | março de 2021 | agosto de 2020
3.2 | Novembro de 2018 | Maio 2021 | Outubro de 2020
3.3 | Janeiro de 2019 | Julho 2021 | Dezembro de 2020
3.4 | março de 2019 | agosto de 2021 | fevereiro de 2021
3.5 | Maio de 2019 | Outubro 2021 | abril de 2021
3.6 | agosto de 2019 | Janeiro 2022 | julho de 2021
3.7 | novembro de 2019 | Maio 2022 | Outubro de 2021

Nossa isso é incrível! Obrigado pelo pensamento que você colocou nisso.

Alguns pequenos pontos:

1. Definitivamente Typed e Typescript são projetos diferentes, embora devam ter o mesmo cronograma EOL.
2. O que EOL significa para DT está descrito acima, mas não é tão claro para TS. Nós nunca criamos uma versão de patch com mais de uma versão secundária de volta ao meu conhecimento. Por outro lado, não recomendamos versões mais recentes do TS para as pessoas, exceto como boa prática geral ou para soluções alternativas específicas.
3. Como o TS é fornecido como parte do Visual Studio, um produto pago com contratos de suporte, talvez seja necessário definir uma extensão específica do VS para qualquer período de suporte de código aberto definido. No entanto, isso não deve afetar a comunidade de código aberto.

@DanielRosenwasser você se importa de olhar isso quando tiver tempo?

2.8 é agora o novo mínimo. 2.0 - 2.7 não serão mais testados e as tags ts2.0 - ts2.7 não serão mais atualizadas em pacotes @types/* existentes. Usuários pré-2.8 que instalam @types/*@latest podem obter tipos que não funcionam para eles.

Não vou encerrar este assunto, pois há uma discussão em andamento (e é um meta-problema além disso?).

@sandersn isso significa que a verificação que geralmente verifica se uma dependência tem uma versão maior ou igual (por exemplo, um pacote arbitrário (2.x com x > 1 referenciando outro pacote com x = 1) agora está desabilitado?

Perguntando porque isso é um grande bloqueio para mover as tipagens de nós para frente.

@SimonSchick não, não está desabilitado; aplica-se apenas a cabeçalhos que requerem >=2.8 .

Em outras palavras, você não pode atualizar @types/node para exigir 3.1 porque há muitos pacotes que especificam 2.8 ou 2.4 -- que é tratado como 2.8. Mas você pode definitivamente ter @types/node exigir 2,8 agora. Isso significa que você pode usar tipos condicionais e pode assumir que a semântica 2.8+ se aplica onde elas diferem das versões antigas.

Na verdade, o padrão é 2.8, portanto, não ter uma versão obrigatória no cabeçalho é equivalente a exigir 2.8.

@sandersn , podemos falar sobre nova atualização da versão mínima? Eu acho que é um bom momento porque o 3.8 foi lançado.

Estamos discutindo isso internamente e nos inclinando para apoiar o cronograma de 30 meses no estilo do nó. Mas preciso coordenar com a equipe de integração do Typescript-VS, que deseja ter um cronograma de suporte para o novo-TS-no-antigo-VS, então ainda não tentei reiniciar a discussão; se terminarmos com 30 meses, a próxima descontinuação será em agosto, então temos um pouco de tempo.

Atualização: conversei com a equipe Typescript-Javascript no VS e eles decidiram um cronograma de 2 ou 2,5 anos. Eles vão coletar alguns dados de uso para ajudá-los a decidir entre os dois. Eu também recuperei o cenário deles - é suporte para old-TS-in-new-VS.

Com base em nossos dados de uso coletados anteriormente [1], prefiro uma janela de 2 anos simplesmente para reduzir a carga de manutenção. Ele também permite que pacotes importantes comecem a usar novos recursos 6 meses antes, sem nenhum esforço para atualizar os dependentes. Uma janela de suporte curta não tem desvantagens práticas que eu vi até agora.

No entanto, a programação do nó pode fazer com que as pessoas esperem uma janela de 2,5 anos. Existem outras vantagens da janela mais longa? Desvantagens que estou perdendo?

[1]
Dados reimpressos de cima:

• A telemetria indica que 99,9% dos usuários do VS Code são 3.0 ou mais recentes
• A telemetria indica que 97% dos usuários do VS estão na versão 3.0 ou mais recente
• 20% dos pacotes DT já optaram pelo 2.8 ou mais recente

Eu sou a favor de uma janela mais curta; tanto por razões de redução da carga de manutenção quanto pelos dados que você descobriu @sandersn.

Obrigado pela atualização!

Também para uma janela mais curta.

Uma janela longa só beneficiaria aqueles que atualizariam apenas parte de suas dependências, mas nunca o datilografado, e isso deveria ser apenas um grupo muito pequeno.
Na maioria das vezes, as pessoas atualizam regularmente todas as suas dependências (incluindo o texto datilografado) ou nenhuma.
Ou o contrário: a maioria dos desenvolvedores que não se preocuparam em atualizar seu TypeScript em dois anos provavelmente não se importam com novos pacotes e novas definições de tipo.
Portanto, isso provavelmente prejudicaria muito menos pessoas do que você pode suspeitar - e impede que todo o ecossistema evolua.

TL;DR; @sandersn , o que você acha dos 18 meses?

Meus pensamentos :

escrevi

A opção 2 Node.js tem uma política de 12 + 18 meses antes da EOL. Podemos usar a mesma abordagem, 2,5 anos. Pode ser muito longo, mas não menos de 2 anos.

mas não consigo lembrar por que pensei que 2 anos é o período certo de tempo. Eu não posso fundamentar logicamente isso 2 anos. Agora, com a mente fresca, parece-me que deveria ter havido ..., but not less 18 months .

Cada versão principal coberta pelo plano LTS será mantida ativamente por um período de 12 meses a partir da data em que entrar na cobertura LTS. Após esses 12 meses de suporte ativo, a versão principal fará a transição para o modo de "manutenção" por mais 18 meses. Antes do Node.js 12, o período ativo era de 18 meses e o período de manutenção de 12 meses. (c) Plano de lançamento do Node.js

Motivação : todas as versões do TypeScipt são lançadas como rc/beta primeiro. Portanto, toda versão estável tem modo de manutenção desde o primeiro dia e 18 meses é suficiente.

Isso é lógico. Mas se usarmos 18 meses como janela, descontinuaremos o 3.1 em março de 2020. Dado que nossa telemetria mostrou um número significativo de usuários do VS ainda no 3.1, não acho que o 3.1 deva ser preterido ainda.

No entanto, é possível que esses números tenham mudado desde o final de outubro. Vou descobrir o que eles são atualmente.

Os números de uso do 3.1 não caíram tanto no VS desde o final de outubro. Curiosamente, 95% do uso está concentrado em 3,9 - 3,4.

Acho que o 3.1 ainda é muito usado porque o VS permitirá que você evite atualizar o texto datilografado ao baixar atualizações, mas não tenho certeza. Independentemente disso, esse comportamento provavelmente continuará em versões futuras do VS, além de outros IDEs que não são atualizados com tanta frequência.

Em resumo, para oferecer suporte a 98% dos usuários do VS, precisamos de uma janela de 2 anos. Para suportar 95%, precisamos apenas de uma janela de 1 ano! Mas não há muito sentido em ter qualquer coisa no meio.

Eu ainda apoio 2 anos com base nesses dados.

Parece-me que a discussão aqui acabou. Eu vou com uma janela de suporte de 2 anos.

2.8 lançado em 27 de março de 2018 , então não vou remover o suporte imediatamente. Mas farei isso nas próximas semanas e atualizarei e fecharei este problema quando estiver concluído.

Eu tenho um PR que adiciona documentação ao README em #42834.

Traduzi as alterações da documentação para o russo em #42881

Alguém poderia ajudar com mudanças de tradução para:

• README.cn.md
• README.es.md
• README.ko.md

@kingwl @armanio123 @saschanaz são os datilógrafos mais envolvidos que conheço que são falantes nativos desses três idiomas.

(Claro, sinta-se à vontade para ignorar isso se estiver muito ocupado.)

A tarefa está adicionando tradução para alterações em #42834?

Traduzi as alterações da documentação para o russo em #42818

É #42881 😁

sim.

A tarefa está adicionando tradução para alterações em #42834?

Traduzi as alterações da documentação para o russo em #42818

É #42881 😁

Fixo. Desculpe, eu fiz o erro de digitação.

Atualização: Ao mesmo tempo que a versão 3.9, acabei de remover o suporte para 2.8.

Eu adiei a depreciação por dois motivos.

1 Atraso geral do covid-19.

1. Estamos no meio da mudança da infraestrutura do editor de tipos para um monorepo que publica no namespace @definitelytyped/* . A atualização da versão agora faz parte desse monorepo. Infelizmente, ainda estamos esperando que o escritório de código aberto da MS torne o monorepo de código aberto, mas deve ser em breve.

Mesmo que a versão 4.0 não seja em maio, ainda removerei o suporte para 2.9 em maio, conforme planejado. Deve ser um pouco mais fácil com a nova configuração.