<p>Plan de iteración de TypeScript 4.0</p>

¿Consideraría incluir https://github.com/microsoft/TypeScript/pull/29818 en 4.0 quizás detrás de la bandera experimental?

Eso se complica por el cambio en la definición de la función de fábrica en sí misma.

Sin embargo, podría ser interesante introducir una definición de tipo virtual de fábrica _separada_; digamos, JSX.Factory , o React.JSX.Factory , que TypeScript podría usar para la inferencia. No estoy muy seguro de que solo traducir la gramática JSX a llamadas de función sea suficiente o eficiente, pero, dado que es un tipo virtual, no tiene que corresponder a ninguna entidad concreta de JavaScript. El riesgo, por supuesto, es entrar en la misma situación que tenemos ahora, con un montón de tipos virtuales que terminaron limitando la seguridad de tipos, no solo de los niños, sino de varias funciones introducidas después de React 15.

¿Consideraría incluir también https://github.com/microsoft/TypeScript/pull/24738 en 4.0 también?

Me entristece un poco no ver ninguna mención de #33038 [👍 140 y un PR real de su propio @weswigham] o #202 [👍 390] mientras que boletos como #15230 [👍 27] se consideran "de alta demanda". Me doy cuenta de que realmente no se puede comparar o priorizar en función de los "me gusta", pero sería genial si hubiera alguna actualización de la hoja de ruta sobre estos, especialmente porque 4.0 parece una buena oportunidad para introducir una característica como esta. 🙏

~ Problema de hace 3,5 años en espera de comentarios con casi 200 comentarios # 13778 con tipeos inexactos proporcionados para cosas como la desestructuración de matrices. Pwetty pwease podemos implementar arreglo 🙏

Aprecio que las personas de vez en cuando impulsen problemas que creen que necesitan atención en las hojas de ruta y los planes de iteración, pero creo que debo ser claro aquí: la sección "investigar correcciones de errores de alta demanda" se determinó analizando los problemas que claramente causaban mucho recortes de papel pero que parecían razonables en su alcance. Definitivamente todavía estamos conscientes de los problemas mencionados, pero algunos de ellos no tienen el mismo alcance ni tienen un resultado ideal claro.

Ejemplos:

• Las marcas nominales estarían bien, pero ¿compensarían eso con la futura dirección del lenguaje en torno a la nominalidad? Incluso tengo esta preocupación con los tipos de marcador de posición como la persona que lo propuso.
• undefined en las firmas de índice es un ejemplo de algo que es interesante, pero no queremos agregar un comportamiento que dificulte las cosas para el 90 % de las personas que ya operan bajo los supuestos actuales. Encontrar un enfoque que componga y permita a los usuarios adoptar gradualmente esos controles no es algo que sea obvio para nosotros. Incluso si es técnicamente posible con un montón de tipos condicionales y verificaciones especiales del compilador, esas soluciones tienden a ser claramente pirateadas y se descomponen rápidamente.

Las marcas nominales estarían bien, pero ¿compensarían eso con la futura dirección del lenguaje en torno a la nominalidad?

@DanielRosenwasser, ¿cuál es la dirección futura del lenguaje en su visión?

Supongo que daré algo de contexto sobre dónde está mi mente con la nominalidad. Hay muchas ideas diferentes que la gente tiene en mente cuando pregunta sobre tipos nominales, incluyendo

• Nominalidad basada en declaraciones "tradicionales" (por ejemplo, lo que ve en la mayoría de los idiomas OO)
• Tipos opacos (tipos cuyo contenido es totalmente desconocido en el exterior)
• Alias ​​distintos ( struct de miembro único en C/C++/C#, newtype en Haskell, clases en línea en Kotlin)
• Unidades de medida (una forma de codificar el análisis dimensional en el lenguaje)

Hay matices entre algunos de estos (por ejemplo , declaraciones de tipo de marcador de posición, una especie de variante de tipos opacos que recurren a un tipo de implementación), y luego hay diferentes direcciones que combinan cada uno de estos.

@RyanCavanaugh tuvo una gran analogía sobre esto en la que 3 niños les piden a sus padres una mascota. Uno quiere un perro, uno quiere un gato, uno quiere un pez. Les preguntan a sus padres "¿¡cuándo vamos a tener una mascota!?" Claramente, todos están de acuerdo en que quieren una mascota, ¡pero cada uno quiere una mascota diferente!

¿Me gustan los tipos de marca? ¡Hago! Los tipos de marca logran algo así como alias distintos y se ajustan a lo que la mayoría de los usuarios están buscando. Pero no creo que esa sea la forma correcta de pensar en ello. Hay más espacio de diseño para desarrollar con muchas compensaciones conocidas, y nada me da la sensación de que debemos apresurarnos a encontrar una solución lo antes posible.

Me gustaría si pudiéramos obtener https://github.com/microsoft/TSJS-lib-generator/pull/858 en TypeScript 4.0 .

@DanielRosenwasser en primer lugar, gracias por escribir 🙇

¿Puede elaborar un poco sobre qué casos de uso los tipos nominales realmente abordan para TypeScript?

Primero: siéntete libre de enviarme a un muro gigante de texto o un repositorio y lo leeré :]

No me refiero a tipos opacos como los tipos de marcador de posición, me refiero a lo que usted llama tipos nominales "tradicionales".

Siempre sentí que los tipos nominales eran la antítesis de JavaScript y es por eso que los intentos anteriores no funcionaron tan bien. Hay formas de hacer que funcione bastante bien (los protocolos en swift y las clases de tipos en haskell me vienen a la mente como "Nominal pero extensible desde el exterior") y estoy seguro de que está familiarizado con la mayoría de las formas "bien establecidas" (I suponga que "unidades de medida" es un guiño de F#).

He encontrado mucha gente preguntando por tipos nominales (como en "tradicionales") pero no muchos escritos sobre _por qué_.

Con el tiempo, hemos visto que cada vez menos personas solicitan tipos nominales "tradicionales", tal vez porque colectivamente la comunidad ha construido un modo mental para los tipos estructurales. Hay algunos lugares donde los tipos realmente actúan nominalmente (cuando instanceof está involucrado o cuando hay privados). Parte de eso se captura con un mejor análisis de flujo de control y comprobaciones de compatibilidad, pero no es perfecto.

Algunos de los casos de uso "tradicionales" son los mismos que los de un tipo de contenedor nominal de cero gastos generales (por ejemplo newtype ), y muchas veces la intención es garantizar un manejo especial para cosas como el archivo rutas, cadenas no confiables, etc.

Siento que Typescript ya es lo suficientemente expresivo. Lo que personalmente me gustaría ver es una mejor integración de herramientas.

• soporte para ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• Complementos del compilador https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• hilo pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

Debido a lo anterior, es común ver soluciones torpes y pirateadas. La mayoría de los proyectos de reacción tienen babel incluido para react-hot-loader (complementos del compilador), algunos sistemas CSS también requieren babel para las transformaciones de tiempo de compilación. El uso de módulos pnp, esm o incluso CSS requiere más herramientas y soluciones alternativas para las limitaciones de tsc.

También es frustrante que, para algunos de estos problemas, la comunidad haya presentado soluciones concretas en forma de RP o propuestas, pero estas fueron rechazadas o estancadas durante años. Como profesional, cada vez es más difícil usar TS en el contexto de un ecosistema más amplio.

De todos modos, solo soy una persona aleatoria de Internet.

@DanielRosenwasser, ¿ tal vez https://github.com/microsoft/TypeScript/pull/29374 podría revisarse a tiempo para 4.0? Creo que cubre muchos (¿la mayoría?) de los this -antes- de los super casos sobre los que la gente tiende a preguntar.

Considere incluir soporte para hacer referencia a módulos ES con una ruta de archivo que incluya la extensión del archivo. Dará un gran impulso para nivelar el campo de juego del código multientorno.

https://github.com/microsoft/TypeScript/issues/16577

¡Gracias por su enfoque en las herramientas en torno a mecanografiado! Esperaba que pudiera considerar proporcionar una integración más estrecha con https://github.com/microsoft/tsdoc. Muchos otros lenguajes modernos como go y rust brindan herramientas de documentación listas para usar y alientan a los desarrolladores a escribir comentarios estándar, pero falta mecanografiado en este sentido.

¡Sería genial si el #31445 pudiera ser recogido, esto ha sido un factor decisivo para nosotros y creo que mucha gente (según la cantidad de referencias que tiene ese número)!

¿Se puede incluir https://github.com/microsoft/TypeScript/pull/38967 en TypeScript 4.0 y quizás también https://github.com/microsoft/TypeScript/pull/35608 ?

Descubrí que la gente solicita que todo se incluya en la versión 4.0 😆

¿Sientes que TS está perdiendo impulso? ¿Asignaciones nulas de unión y cortocircuito para la próxima versión 4.0.0, _principal_? ¿Ya no tienes grandes objetivos ni ideas ambiciosas?

Para la próxima especialización, esperaría:

• Mecanografía de tipo superior
• ¿Tipo dependiente? ¿Funciones de nivel de tipo? (Ok, este puede ser para 5.0.0)
• Tipificación nominal
• macrosis
• Soporte para transformadores en tsconfig.json
• Compilación a WASM (de algún subconjunto de idiomas)

@canonic-epicure De acuerdo, actualmente se siente más como un 3.10 para la próxima versión

¿Sientes que TS está perdiendo impulso? ¿Asignaciones nulas de unión y cortocircuito para la próxima versión principal 4.0.0? ¿Ya no tienes grandes objetivos ni ideas ambiciosas?

TypeScript no sigue el servidor. No hay v0.10, v1.10, v2.10 o v3.10. Así que este es en realidad un hito normal. Es un poco extraño que la gente espere tantos cambios en 4.0 pero no diga nada en 3.9 o en el plan de iteración anterior. 🙈

Funciones de nivel de tipo

type X<T> = T puede hacerlo en algún nivel. (no admite funciones de orden superior).

macrosis

En mi opinión, no satisface el objetivo de Typescript.

Soporte para transformadores en tsconfig.json

Pruébelo: https://github.com/cevek/ttypescript

Compilación a WASM (de algún subconjunto de idiomas)

¿Está buscando https://www.assemblyscript.org/

Ok, entonces 4.0.0 es solo una próxima versión menor, es bueno saberlo.

Con respecto a "las macros no satisfacen el objetivo de TS" y "usar ttypescript para transformadores" ( ts-patch funciona mejor por cierto), esto se parece al movimiento jedi, "esta no es la función que necesita". No, macroses y transformadores listos para usar, por favor. Ha sido solicitado hace años.

También quiero marco en TypeScript, pero realmente hay muchas razones en contra de esto.

1. si Marco puede generar un código JavaScript diferente, está creando una nueva sintaxis de nivel sin tipo, por lo tanto, es una extensión de la especificación ES. enum , import x = require(...) , module es la excepción a esta regla, pero provienen de los primeros tiempos de TypeScript.

2. si desea usar Marco para cruzar diferentes archivos para generar diferentes archivos JS, entonces es imposible eliminar tontamente toda la sintaxis de tipo para obtener el archivo JavaScript.

3. Marcos puede aumentar el tiempo de análisis y compilación, y es probable que se abuse de él.

4. Si Marco puede emitir diferentes archivos JS en función de la información de tipo, será imposible que Babel maneje esta sintaxis. Entonces, este comportamiento viola la regla isolatedModules (excepción: const enum y module )

5. Si Marco solo puede hacer un "Marco de nivel de tipo" y Babel puede borrarlo de manera segura, se vuelve mucho más inútil pero sigue siendo útil para tipos programáticos / de orden superior. Por lo tanto, no está violando ningún objetivo, pero dudo que el equipo de TypeScript se interese en la idea. (Hice una demostración en https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts).

@ Jack-Works No entiendo tus puntos. ¿Quizás quiere decir que las macros extenderán el analizador y crearán una nueva sintaxis?

Para mí, las macros son solo la función AST -> AST, que ejecuta el verificador de tipos anterior de alguna manera, por lo tanto, puede crear nuevos nodos AST que se verificarán con regularidad. Sin embargo, no crea una nueva sintaxis: la entrada es AST normal, la salida también. Crea nuevos nodos en AST.

La discusión estará fuera de tema para este hilo, ¿tal vez continúe en el canal #compiler en discord?

¿Se puede incluir #38597 en TypeScript 4.0?

@DanielRosenwasser

undefined en las firmas de índice es un ejemplo de algo que es interesante, pero no queremos agregar un comportamiento que haga que sea más difícil para el 90% de las personas que ya operan bajo los supuestos actuales.

Solo por curiosidad, ¿cómo sabes que es el 90% de las personas?

@wongjiahau, el número se inventó casualmente por el bien de la explicación. No estoy seguro si ese es el punto específico sobre el que estás preguntando.

Solo como un aviso: nuestro equipo no trabajará el 19 de junio, por lo que retrasaremos un poco el cronograma. La versión beta ahora está programada para enviarse el próximo jueves 25 de junio.

@DanielRosenwasser Estoy tratando de señalar que está utilizando algunos números arbitrarios inventados para negar la importancia de la característica (# 13778) que claramente se alinea con el primer objetivo de Typescript, que es identificar estáticamente las construcciones que probablemente ser errores .

Por favor, no me malinterpreten, agradezco el arduo trabajo que el equipo central ha puesto en este proyecto, pero creo que podríamos haberlo mejorado si pudiéramos estar realmente alineados con los objetivos de este proyecto. de permitir declaraciones no probadas para obstaculizar su avance.

@wongjiahau no fuimos a una reunión y dijimos "Daniel dijo que el número es del 90 %, eso está por encima de nuestro umbral del 85 %, nunca hagamos esta función". Todavía lo estamos investigando y somos muy conscientes de la demanda de los desarrolladores, pero también hemos probado cómo se ve esta función en la práctica y puedo decirles que no es agradable.

Si va a sobreanalizar declaraciones como esta de nosotros de esta manera, simplemente obtendrá menos declaraciones de nosotros, porque tenemos mejores cosas que hacer que malinterpretarnos activamente en Internet.

4.0 es definitivamente un hito en lugar de "la próxima versión de 3.9".

@typescript-bot crear versión-4.0

Hola @DanielRosenwasser , comencé a crear la rama release-4.0 para ti. Aquí está el enlace a mi mejor conjetura en el registro .

@Kingwl si esto es un hito, ¿cuáles son esas cosas importantes o al menos cuál es la función de héroe? No veo nada tan bueno en la lista de funciones de idioma en la parte superior de este número. Nada inusual en comparación con la mayoría de las versiones 3.x.
Por supuesto, podría decir que es solo un cambio importante que requiere el lanzamiento de una versión principal, pero es difícil llamarlo "hito".

@wgebczyk En mi opinión, las tuplas variadicas con elementos de tupla etiquetados son el hito.

@wgebczyk No importa. Pero en realidad Variadic Tuples lo es.

@xiaoxiangmoe @Kingwl hito ? pulgada de piedra.

Está ahí: https://devblogs.microsoft.com/typescript/annunciando-typescript-4-0-beta/#variadic -tuple-types
¿Cuándo llegará a la versión estable? No puedo esperar para aplicar esto en la codificación diaria en VS Code.

@mk0y según el mensaje de apertura sobre el 18 de agosto.

@wgebczyk nuestros lanzamientos se basan en el tiempo; cada lanzamiento contiene aproximadamente tres meses de trabajo del equipo. Nuestra política de versiones de hitos (n = n + 0.1) ha sido consistente durante los últimos 20 lanzamientos, así que esperamos que esto deje de ser una sorpresa para la gente en algún momento 😅

¿Consideraría permitir el tipo symbol para la indexación en las próximas versiones menores? ¿Podría actualizar y fusionar la solicitud de extracción 26797 ?

Hola @DanielRosenwasser , comencé a actualizar el número de versión en release-4.0 a 4.0.1-rc para ti. Aquí está el enlace a mi mejor conjetura en el registro .

@typescript-bot sincronización versión-4.0

Hola @DanielRosenwasser , comencé a sincronizar release-4.0 con el maestro para ti. Aquí está el enlace a mi mejor conjetura en el registro .

@typescript-bot sincronización versión-4.0

Hola @DanielRosenwasser , comencé a sincronizar release-4.0 con el maestro para ti. Aquí está el enlace a mi mejor conjetura en el registro .

@weswighammmmmmmmmmmmmmmmmmmmm , el bot me odia ): ): ): ):

Absolutamente sin prisas, pero lo hice manualmente y archivé esto: https://github.com/microsoft/TypeScript/issues/39869

¿Ya existe una hoja de ruta para después de 4.0 en alguna parte? Me gustaría potenciar el #37582 ya que hay una demanda cada vez más creciente (#39965, #38149, #27481, #39965, #38546). A mí me parece un problema de alcance razonable.

Solo como una actualización, tuvimos que movernos sobre el RC por 2 días para el lanzamiento del sitio web y para otros cambios sentimos que necesitábamos aterrizar en el RC. No anticipamos nada que nos haga retroceder mucho más, pero para estar seguros, nos daremos otros 2 días para recibir comentarios sobre el RC, y apuntaremos al día 20 en su lugar.

@typescript-bot bump release-4.0

Hola @DanielRosenwasser , comencé a actualizar el número de versión en release-4.0 a 4.0.2 para ti. Aquí está el enlace a mi mejor conjetura en el registro .

es el 20 de agosto :)

Je, todavía es 19 de agosto aquí, e incluso dentro de 20 minutos, creo que tendrás que esperar un poco más. ¡Tenemos lanzamientos nocturnos en npm si no puedes tomar un minuto más! 😄

Esperando el lanzamiento, ya disponible en npm :)

@typescript-bot bump release-4.0

Hola @DanielRosenwasser , comencé a actualizar el número de versión en release-4.0 a 4.0.3 para ti. Aquí está el enlace a mi mejor conjetura en el registro .

@typescript-bot bump release-4.1

Hola @DanielRosenwasser , comencé a actualizar el número de versión en release-4.1 a 4.1.1-rc para ti. Aquí está el enlace a mi mejor conjetura en el registro .

Oh no

@typescript-bot bump release-4.0

Hola @DanielRosenwasser , comencé a actualizar el número de versión en release-4.0 a 4.0.4 para ti. Aquí está el enlace a mi mejor conjetura en el registro .

@typescript-bot bump release-4.0

Hola @DanielRosenwasser , comencé a actualizar el número de versión en release-4.0 a 4.0.5 para ti. Aquí está el enlace a mi mejor conjetura en el registro .