Definitelytyped: META: actualización de la versión mínima de TypeScript

¿Cuándo se agregó unknown ? ¡Ve a lo grande o vete a casa! Todo el any en DT es, con mucho, la mayor fuente de errores de "mecanografiado debería haberlo detectado" en estas partes.

¿Cuándo se agregó unknown ?

3.0

usted. Entonces, ¡99.9%!

Estoy de acuerdo en que deberíamos hacer esto. ¡Hagámoslo!

Por favor, ¿podría aumentarlo lentamente con el tiempo? 2.1 un mes, 2.2 el siguiente y así sucesivamente?

Cada versión tiene algunos pequeños cambios importantes. Será más fácil entender los problemas que esto trae si vas despacio y metódicamente al principio.

Los proyectos en modo de mantenimiento a menudo no tienen el ancho de banda para superar esos cambios importantes, especialmente si son fundamentales para la infraestructura.

Sí, por favor, los tipos de node en particular se han visto afectados por la falta de funciones más nuevas y se han tenido que utilizar muchos ~trucos~.

No es probable que los proyectos de @JoshuaKGoldberg en modo de mantenimiento actualicen las versiones de las definiciones de tipos mes tras mes, ¿no?

@JoshuaKGoldberg recuerda que la actualización de DT no elimina las definiciones de tipos históricos que ya se publicaron en npm. @types las versiones históricas viven para siempre como Mumm-Ra.

Podrá depender de ellos independientemente de dónde vaya DT en cuanto a versiones.

Tiene sentido

Hola @RyanCavanaugh ,
Apoyo esa idea al 100%. TypeScript v2.0 es un bloqueador para un mejor sistema de tipos para muchos paquetes, incluido node .
Me preocupo por la transparencia y la previsibilidad para la comunidad y las empresas . Hay preguntas:

• ¿Cuándo cree que es un buen momento para cambiar la versión mínima admitida de TypeScript? ¿Durante el lanzamiento de TS 3.7?
• Corrígeme si me equivoco, pero esto parece el final de la vida útil de las versiones de TypeScript anteriores a la 2.8.
• ¿Podríamos tener un horario similar al de Node.js ? Dicho documento ayudará a los equipos de desarrollo a presionar a las empresas para que aprueben los recursos de desarrollo para su actualización.

¿Alguna razón por la que es 2.8 y no una versión diferente? (Por ejemplo, 3.0 por unknown .)

2.8 es cuando se introdujeron los tipos condicionales

Muy a favor.

Por favor, mientras lo hace, considere establecer un cronograma (semi)formal para que la comunidad pueda contar con una versión mínima que aumente previsiblemente con el tiempo. Algo como: "Todos los años, en noviembre, planeamos actualizar la versión mínima mecanografiada al lanzamiento de 18 meses antes. Planifique en consecuencia".

@donaldpipowitch
De los usuarios anteriores a 3.0, vimos un grupo de personas que todavía usaban 2.8. (Y, por supuesto, los tipos condicionales hacen que 2.8 sea un objetivo popular para los tipos de DT como señala @IllusionMH ).

Esperamos revisar este problema periódicamente porque esperamos que las personas continúen actualizándose.

@galkin
Técnicamente, las versiones antiguas de Typescript no reciben servicio en absoluto, y este cambio es la interrupción del servicio de Definitely Typed. Y, por supuesto, las versiones antiguas de Typescript pueden continuar obteniendo las versiones existentes de los paquetes DT. Simplemente no recibirán actualizaciones.

Sin embargo, eso es solo un tecnicismo. Sería una buena idea para nosotros producir un cronograma similar a LTS. Sin embargo, aún no hemos comenzado con nada de eso. En este caso, los datos eran lo suficientemente claros como para facilitar la decisión post-hoc. Todavía no estoy seguro de cómo predecir una buena fecha para futuras depreciaciones.

Re: la fecha: tengo que actualizar la infraestructura de DT para 3.7 de todos modos, por lo que sucederá el día del lanzamiento de 3.7 como parte del lanzamiento.

Sería una buena idea para nosotros producir un cronograma similar a LTS.

Solo quería repetir que creo que este tipo de horario es una idea realmente sólida.

@johnnyreilly estamos buscando precedentes en Microsoft. ¡Sin embargo, no hay nada como Definitely Typed!

@RyanCavanaugh , ¿alguna actualización?

@galkin si tiene un cronograma de desactivación propuesto, publíquelo en este hilo para que podamos discutirlo.

@sandersn , aquí están mis pensamientos sobre este tema

• ¿Necesitamos End-of-life (EOL) para la versión de TypeScript?
  Por supuesto que sí. La compatibilidad con todas las versiones de TypeScript creadas requiere recursos excedentes.
• ¿Por qué deberíamos tener un horario EOL?
  _La mejor práctica es ser sincero y claro con el estado de sus proyectos. Si ya no apoya un proyecto, o está en el proceso de cerrarlo, hágalo dolorosamente obvio para cualquiera que se tropiece con su código : (c) Jared Smith.
• ¿Qué se debe utilizar como base para el cronograma?
  ¿Analítica? Cada decisión basada en análisis es un compromiso. Cada decisión de este tipo es una respuesta a la pregunta de qué parte de la comunidad/empresa nos burlaremos. WordPress tiene un problema similar con la versión mínima de WP/PHP/MySQL que deberían admitir. Es una forma peligrosa.
  ¿Programa de herramientas dependiente? Código Visual/Microsoft Azure/Angular/etc. Demasiadas opciones y demasiado fácil iniciar una nueva guerra santa.
  ¿Proceso TC39? Buena opción, pero TC39 no introduce ni introducirá EoL para ninguna función de idioma.
  Node.js? Node.js es un controlador para la comunidad JS con programación de lanzamiento/EOL. TypeScript usa Node.js. Veo esto como la mejor base para el horario.
• ¿Cómo crear el horario?
  Opción 1. Asociar la versión de TypeScript con la versión de Node.js y anunciar un EOL similar. Por ejemplo, hace 2 años, Node.js v8 comenzó LTS y se lanzó TypeScript v2.6 , por lo que 2019.12.31 es EOL.
  La opción 2 Node.js tiene una política de 12 + 18 meses antes de EOL. Podemos utilizar el mismo enfoque, 2,5 años. Puede ser demasiado largo, pero no menos de 2 años.
  Opción 3 Haga una reunión con los tomadores de decisiones y comparta con la comunidad el resultado tal como fue

Así que mi propuesta es algo así:

versión | Lanzado | Fin de vida en 2,5 años | Fin de vida en 2 años
-- | -- | -- | --
2.1 | diciembre 2016 | junio 2019 | diciembre 2018
2.2 | febrero 2017 | agosto 2019 | febrero 2019
2.3 | abril 2017 | septiembre 2019 | abril 2019
2.4 | junio 2017 | noviembre 2019 | junio 2019
2.5 | agosto 2017 | enero 2020 | agosto 2019
2.6 | octubre 2017 | marzo de 2020 | octubre 2019
2.7 | enero 2018 | julio de 2020 | enero 2020
2.8 | marzo 2018 | agosto 2020 | febrero 2020
2.9 | Mayo 2018 | octubre 2020 | abril 2020
3 | julio 2018 | diciembre 2020 | junio 2020
3.1 | septiembre 2018 | marzo 2021 | agosto 2020
3.2 | noviembre 2018 | mayo 2021 | octubre 2020
3.3 | enero 2019 | julio 2021 | diciembre 2020
3.4 | marzo 2019 | agosto 2021 | febrero 2021
3.5 | Mayo 2019 | octubre 2021 | abril 2021
3.6 | agosto 2019 | enero 2022 | julio 2021
3.7 | noviembre 2019 | mayo 2022 | octubre 2021

¡Wow esto es increíble! Gracias por el pensamiento que pones en esto.

Un par de pequeños puntos:

1. Definitivamente Typed y Typescript son proyectos diferentes, aunque deberían tener el mismo cronograma de EOL.
2. Lo que EOL significa para DT se explica arriba, pero no está tan claro para TS. Nunca hemos creado una versión de parche más de una versión menor que yo sepa. Por otro lado, no hemos recomendado versiones más nuevas de TS a las personas, excepto como buena práctica general o para soluciones alternativas específicas.
3. Dado que TS se envía como parte de Visual Studio, un producto pago con contratos de soporte, es posible que tengamos que definir una extensión específica de VS para cualquier período de soporte de código abierto que se defina. Sin embargo, esto no debería afectar a la comunidad de código abierto.

@DanielRosenwasser , ¿te importa mirar esto cuando tengas tiempo?

2.8 es ahora el nuevo mínimo. 2.0 - 2.7 ya no se probará y las etiquetas ts2.0 - ts2.7 ya no se actualizarán en los paquetes @types/* existentes. Los usuarios de versiones anteriores a la 2.8 que instalen @types/*@latest pueden obtener tipos que no funcionen para ellos.

No voy a cerrar este tema ya que hay una discusión en curso (¿y además es un meta-problema?).

@sandersn , ¿eso significa que la verificación que generalmente verifica que una dependencia tiene una versión mayor o igual (por ejemplo, un paquete arbitrario (2.x con x> 1 que hace referencia a otro paquete con x = 1) ahora está deshabilitada?

Preguntar porque ese es un bloqueo importante para mover los tipos de nodos hacia adelante.

@SimonSchick no, no está deshabilitado; solo se aplica a los encabezados que requieren >=2.8 .

En otras palabras, no puede actualizar @types/node para requerir 3.1 porque hay muchos paquetes que especifican 2.8 o 2.4, que se trata como 2.8. Pero definitivamente puede tener @types/node que requieren 2.8 ahora. Eso significa que puede usar tipos condicionales, y puede asumir que la semántica 2.8+ se aplica donde difiere de las versiones anteriores.

De hecho, el valor predeterminado es 2.8, por lo que no tener una versión requerida en el encabezado equivale a requerir 2.8.

@sandersn , ¿podríamos hablar de una nueva actualización de la versión mínima? Creo que es un buen momento porque se lanzó 3.8.

Lo hemos estado discutiendo internamente y nos hemos inclinado por respaldar el cronograma de 30 meses estilo nodo. Pero necesito coordinarme con el equipo de integración de Typescript-VS, que desea tener un cronograma de soporte para el nuevo TS en el antiguo VS, por lo que aún no he intentado reiniciar la discusión; si terminamos con 30 meses, la próxima depreciación será en agosto, por lo que tenemos un poco de tiempo.

Actualización: hablé con el equipo de Typescript-Javascript en VS y decidieron un programa de 2 años o de 2,5 años. Van a recopilar algunos datos de uso para ayudarlos a decidir entre los dos. También obtuve su escenario al revés: es soporte para old-TS-in-new-VS.

Según nuestros datos de uso recopilados anteriormente [1], prefiero una ventana de 2 años simplemente para reducir la carga de mantenimiento. También permite que los paquetes importantes comiencen a usar nuevas funciones 6 meses antes sin esfuerzo para actualizar los dependientes. Una ventana de soporte breve no tiene las desventajas prácticas que he visto hasta ahora.

Sin embargo, el cronograma del nodo puede hacer que las personas esperen una ventana de 2,5 años. ¿Hay otras ventajas de la ventana más larga? ¿Desventajas que me estoy perdiendo?

[1]
Datos reimpresos desde arriba:

• La telemetría indica que el 99,9 % de los usuarios de VS Code son 3.0 o más nuevos
• La telemetría indica que el 97% de los usuarios de VS están en 3.0 o más reciente
• El 20% de los paquetes de DT ya optaron por 2.8 o más reciente

Estoy a favor de una ventana más corta; tanto por motivos de reducción de la carga de mantenimiento como por los datos que ha descubierto @sandersn.

¡Gracias por la actualización!

También para una ventana más corta.

Una ventana larga solo beneficiaría a aquellos que solo actualizarían parte de sus dependencias, pero nunca mecanografiadas, y eso solo debería ser un grupo muy pequeño.
La mayoría de las veces, las personas actualizan regularmente todas sus dependencias (incluido el mecanografiado) o ninguna.
O al revés: la mayoría de los desarrolladores que no se han molestado en actualizar su TypeScript en dos años probablemente no se preocupen en absoluto por los paquetes nuevos y las definiciones de tipo nuevas.
Entonces, esto probablemente dañaría a mucha menos gente de lo que sospechas, y evita que todo el ecosistema evolucione.

TL;RD; @sandersn , ¿qué piensas sobre los 18 meses?

Mis pensamientos :

escribí

La opción 2 Node.js tiene una política de 12 + 18 meses antes de EOL. Podemos utilizar el mismo enfoque, 2,5 años. Puede ser demasiado largo, pero no menos de 2 años.

pero no puedo recordar por qué pensé que 2 años es el período de tiempo correcto. No puedo fundamentar lógicamente estos 2 años. Ahora, con una mente fresca, me parece que debería haber ..., but not less 18 months .

Cada versión principal cubierta por el plan LTS se mantendrá activamente durante un período de 12 meses a partir de la fecha en que ingrese a la cobertura LTS. Luego de esos 12 meses de soporte activo, la versión principal pasará al modo de "mantenimiento" durante 18 meses adicionales. Antes de Node.js 12, el período activo era de 18 meses y el período de mantenimiento de 12 meses. (c) Plan de lanzamiento de Node.js

Motivación : cada versión de TypeScipt se lanza primero como rc/beta. Entonces, cada versión estable tiene modo de mantenimiento desde el primer día y 18 meses es suficiente.

Eso es lógico. Pero si usamos 18 meses como la ventana, dejaríamos de usar 3.1 en marzo de 2020. Dado que nuestra telemetría mostró una cantidad significativa de usuarios de VS todavía en 3.1, no creo que 3.1 deba quedar obsoleto todavía.

Sin embargo, es posible que esos números hayan cambiado desde finales de octubre. Voy a averiguar cuáles son actualmente.

Los números de uso de 3.1 no han bajado tanto en VS desde finales de octubre. Curiosamente, el 95% del uso se concentra en 3.9 - 3.4.

Creo que 3.1 todavía se usa mucho porque VS le permitirá evitar actualizar mecanografiado al descargar actualizaciones, pero no estoy seguro. Independientemente, es probable que este comportamiento continúe en futuras versiones de VS, además de otros IDE que no se actualizan con tanta frecuencia.

En resumen, para brindar soporte al 98 % de los usuarios de VS, necesitamos una ventana de 2 años. ¡Para respaldar el 95%, solo necesitamos una ventana de 1 año! Pero no tiene mucho sentido tener algo intermedio.

Todavía apoyo 2 años en base a esos datos.

Me parece que la discusión aquí ha terminado. Voy a ir con una ventana de soporte de 2 años.

2.8 lanzado el 27 de marzo de 2018 , por lo que no eliminaré el soporte de inmediato. Pero lo haré en las próximas dos semanas, y actualizaré y cerraré este problema cuando esté terminado.

Tengo un PR que agrega documentación al LÉAME en #42834.

Traduje los cambios de documentación al ruso en #42881

¿Alguien podría ayudar con los cambios de traducción en:

• LÉAME.cn.md
• LÉAME.es.md
• LÉAME.ko.md

@kingwl @armanio123 @saschanaz son los mecanógrafos más involucrados que conozco que son hablantes nativos de esos tres idiomas.

(Por supuesto, siéntase libre de ignorar esto si está demasiado ocupado).

¿La tarea está agregando traducción para cambios en #42834?

Traduje los cambios de documentación al ruso en #42818

Es el #42881 😁

Si.

¿La tarea está agregando traducción para cambios en #42834?

Traduje los cambios de documentación al ruso en #42818

Es el #42881 😁

Reparado. Lo siento, cometí el error tipográfico.

Actualización: al mismo tiempo que la versión 3.9, acabo de eliminar la compatibilidad con 2.8.

Retrasé la desaprobación por dos razones.

1 Retraso general por covid-19.

1. Estamos en medio de cambiar la infraestructura del editor de tipos a un monorepo que publica en el espacio de nombres @definitelytyped/* . La actualización de la versión ahora es parte de ese monorepo. Desafortunadamente, todavía estamos esperando que la oficina de código abierto de MS haga que el monorepo sea de código abierto, pero debería ser pronto.

Aunque el lanzamiento de 4.0 no será en mayo, eliminaré el soporte para 2.9 en mayo como estaba planeado. Debería ser un poco más fácil con la nueva configuración.