Typescript: ¿Suprimir el error "La ruta de importación no puede terminar con una extensión '.ts'"?

Suponga que tiene dos archivos:
a.ts : import * as b from "./b.ts";
b.ts : export const b: number = 0;

Cuando compilamos a.ts , no cambiamos los especificadores de importación . Entonces, la salida a.js contendrá el mismo especificador de importación "./b.ts", aunque posiblemente se traduzca a require("./b.ts") .
Luego, cuando intente ejecutar a.js , fallará, porque no habrá b.ts para importar, solo b.js . (O sin --outDir donde b.js está al lado de b.ts , resolverá la importación en b.ts , luego fallará el análisis en : number . )

En su lugar, debe omitir la extensión de archivo de sus importaciones o usar la extensión .js .

no, utilizo deno exec el archivo。 sin compilar。

@ hooper-hc
Creo que podemos establecer tsconfig como una solución temporal como esta:

{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

También estoy usando deno. Descubrí que al comentar // @ts-ignore cada línea de una importación funciona.

// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

¿Hay alguna forma de cerrar este requisito globalmente en ts-config?

También probé la solución de @zhmushan y no solucionó el problema :(

@reggi eliminar ./
Espero que en el futuro podamos usar una configuración similar a module:deno para simplificar la operación.

¿El equipo de TypeScript estaría dispuesto a agregar "module": "deno" al tsconfig? De esa manera podemos admitir el uso de la extensión .ts forma nativa, sin necesidad de recurrir a algo como kitsonk / deno_ls_plugin como solución. También podría intentar hacerlo cumplir, así que si lo intentas

import module from 'module';

mostraría un error como Cannot have an extensionless import with module:deno (las únicas importaciones que están permitidas son las URL completas y las importaciones relativas que comienzan con ./ o ../ ). Una configuración como esa también podría admitir la búsqueda nativa de tipos en la carpeta $DENO_DIR/deps , ya que actualmente necesitamos usar una configuración de ruta para solucionar eso. Además de esto, las importaciones automáticas también podrían funcionar correctamente, ya que actualmente siempre realizan la importación sin extensión (lo que significa que debe editarlo manualmente de todos modos).

Esto parece un duplicado de # 11901 que desafortunadamente fue cerrado y silenciado. Esto es importante para Deno como se dijo antes y espero que TypeScript haga que esta extensión sea configurable o incluso mejor que la elimine por completo.

En la mayor parte del ecosistema de herramientas de Javascript, puede hacer cosas como import picture from 'image.png' , que obviamente no es Javascript. El supuesto es que alguna herramienta sabrá cómo transpilar el archivo referenciado a Javascript para que esto funcione correctamente. Todos los tipos de activos y sintaxis alternativas, como JSX, funcionan de esta manera.

Typecript, por otro lado, espera que use una extensión en blanco o la extensión .js , que es diferente de cómo funciona el resto del ecosistema. Esto causa fricción para herramientas como Deno o rollup.js que esperan la extensión de archivo original.

Si tsc quisiera trabajar más como el resto del mundo, podría permitir .ts como una extensión, y luego transformar eso en .js como parte de los tipos de eliminación en tiempo de compilación. Obviamente, esto es un gran cambio en la forma en que funciona el compilador tsc. Por otro lado, hay una ola de herramientas alternativas basadas en Babel y Sucrase que comienzan a ingresar al ecosistema, por lo que quizás haya un beneficio a largo plazo al alinearse con la forma de hacer las cosas de esas herramientas.

Agregando mi voto aquí para apoyar a Deno. El comportamiento actual da como resultado que TypeScript resuelva todos los tipos importados de esta manera a any , lo que dificulta el desarrollo de software para Deno.

Deno es una gran idea, pero tratar de convencer al equipo de TS para que permita explícitamente que Deno resuelva los módulos de esa manera para mí es una batalla perdida. Es mucho más fácil para Deno manejarlo porque (a) es mucho más rápido hacerlo, se necesita menos esfuerzo y (b) convencer al equipo de TS de volver a cablear sus componentes internos es una batalla muy cuesta arriba.

Si tsc quisiera trabajar más como el resto del mundo

TS se está volviendo cada vez más dominante, es una buena estrategia ser lo más compatible posible con las convenciones de TS, incluidas sus herramientas. De lo contrario, proyectos como Deno nunca obtendrán tracción debido a la divergencia en algo tan fundamental como la resolución del módulo.

@ jpike88 No estoy de acuerdo. No me di cuenta de que existía este problema. Hubo un par de otros problemas semi relacionados que estábamos rastreando. Este tema no dice nada sobre la intención del equipo. Todavía está etiquetado como una pregunta y se podría argumentar que realmente es un duplicado de # 16577 o # 18442.

Sin embargo, el

Todavía creo (y pensé que dije esto en un problema antes) es que podría haber tiempo para "moduleResolution": "literal" que haría lo que dice en la lata y permitiría que TypeScript asuma que cualquier host de tiempo de ejecución lo resolvería out / change los especificadores del módulo.

Bien pero:

https://github.com/microsoft/TypeScript/issues/18442
De hecho, lo comenté hace dos años y, después de todo este tiempo, sigue siendo una propuesta de etapa 1.

https://github.com/microsoft/TypeScript/issues/16577
También más de dos años, todavía en la etapa de 'discusión'. También al ritmo que va, no sucederá pronto.

Simplemente me estoy saliendo de la escala de tiempo para la que han estado sucediendo las cosas aquí, y basando su probabilidad de que alguna vez sucedan en un plazo de mediano o incluso largo plazo.

Este problema se ha marcado como "Pregunta" y no ha tenido actividad reciente. Se ha cerrado automáticamente por motivos de limpieza. Si todavía está esperando una respuesta, las preguntas suelen ser más adecuadas para stackoverflow .

Se produce un problema similar si desea importar directamente un archivo .mjs
por ejemplo, import { forEach } from https://unpkg.com/[email protected]/index.mjs

Esto está cerrado, pero no arreglado.

Si alguien aquí estaba buscando una manera de poder ejecutar su TypeScript tanto dentro del contexto de Node.js como de Deno, sepa que Webpack + ts-loader le permitirá mantener ".ts" en sus importaciones.

¿Tengo este problema cada vez que importo un archivo desde deno? ¿Alguna solución para arreglar esto excepto agregar // @ts-ignore ?

¿Está esto arreglado? Importar sin extensión no es parte de JS de todos modos, el uso de extensiones no debería mostrar un error.

Estoy de acuerdo con los comentarios anteriores. Es una lástima que el problema aún no se haya resuelto.
Encontré extensiones para vscode que deberían ayudar, pero desafortunadamente no funciona correctamente.
De todos modos, dejaré los enlaces aquí:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

Siguiendo a @ TicTak21 :
Los enlaces que mencionó están obsoletos ahora a favor del complemento oficial deno:
https://github.com/denoland/vscode_deno
Esta extensión corrige las importaciones de .ts y URL (para que no haya más errores) correctamente,

@danbulant Sigo viendo el error al usar el complemento vscode_deno.

También uso Deno, pero creo que el problema aquí no se trata de .ts vs no .ts . Se trata más de la capacidad de permitir que tsc ignore cualquier número de error. Por ejemplo, algo como tsc --ignore TS2691 .

La extensión Deno para el código vs es buena, pero no resuelve el problema, simplemente suprime el error en el editor. Tengo una biblioteca que quiero construir para deno y el navegador, pero no puedo porque tsc arrojará.

@samuelgozi
Estoy 100% de acuerdo. Esta es la razón principal por la que todavía no considero a Deno como un reemplazo para node.js en el servidor. Ya está disponible un buen framework web para Deno, y solo TYPESCRIPT se interpone en el camino de este hermoso sueño

Para cualquiera que tenga problemas recientes con esto, diré que el deno_ls_plugin a pesar de estar archivado logró exactamente el resultado que necesito. Este problema que hace referencia al complemento es cómo lo descubrí .

Mi caso de uso específico es que estoy trabajando en un entorno con código mecanografiado compartido entre el cliente y el servidor mediante enlaces simbólicos. El servidor se escribe con deno en mente, y el cliente se escribe con mecanografiado y phaser3 regulares. El paquete que estoy usando, parcel , puede manejar la importación de archivos mecanografiados .ts (al menos con parcel-bundler ^1.12.4 ). Eso deja que el intellisense se arregle.

deno_ls_plugin funciona muy bien para mí, porque literalmente solo parchea la resolución del módulo .ts . ¡Perfecto! Eso significa que puedo importar el código compartido y hacer que el código compartido se escriba con deno al frente y ante todo en la mente, y parchear el intellisense para el lado del cliente mecanografiado de las cosas.

Para empezar, ejecuté el comando yarn add typescript deno_ls_plugin --dev para instalarlo. Después de ver que el intellisense no se corrigió, noté un pequeño texto en la parte inferior del archivo Léame de deno_ls_plugin , para usar la versión de espacio de trabajo de mecanografiado .

Para cualquier otra persona un poco confundida acerca de cómo hacer eso, esto es lo que hice:
Primero, instalé deno_ls_plugin y typescript como dependencias de desarrollo, y actualicé tsconfig.json para incluir deno_ls_plugin como complemento

{
  "compilerOptions": {
    "plugins": [{ "name": "deno_ls_plugin" }]
  }
}

Luego, hice clic en un archivo mecanografiado y en la versión en la esquina inferior derecha.

Luego, elegí seleccionar la versión mecanografiada

y eligió la versión del espacio de trabajo.

En mi caso específico, también configuré typescript.tsdk en .vscode/settings.json pero no sé si lo necesitaba.

Si alguien más también está tratando de compartir el código deno con el código mecanografiado, utilicé enlaces simbólicos para vincular al código central tanto en el servidor como en el cliente, y el código dentro del enlace simbólico hacía referencia a un archivo deps.ts fuera de él para dependencias (ya que import_map es un poco meh atm) para que la versión mecanografiada pueda importar el paquete npm y la versión deno pueda importar las URL.

Con suerte, este pequeño mensaje podría ayudar a cualquiera que tenga problemas similares al intentar compartir el código deno entre un proyecto de mecanografiado clásico y un proyecto deno.

Creé un problema de sugerencia aquí que resolvería el problema anterior. Con suerte, podemos tomar algo de impulso para implementar eso o algo similar en un futuro muy cercano.

Este problema debe reabrirse.

Los desarrolladores de Deno no están recibiendo el respeto que se merecen aquí. Hicieron un tiempo de ejecución asombroso basado en TypeScript, pero los desarrolladores de TypeScript no agregarán una marca para permitir que funcione correctamente. ¡¿Cómo puede durar tanto tiempo esta lamentable situación ?!

No poder usar la extensión .ts en las importaciones está causando un gran dolor y problemas a los usuarios de Deno, ¡ayúdenos!

en realidad no es específico de Deno

sin la posibilidad de definir explícitamente la extensión, muchos desarrolladores de JS tendrán problemas

por ejemplo, en nuestro proyecto vue siempre especificamos extensiones, o de lo contrario tendremos problemas en situaciones como

./component.vue
./component.ts

import component from './component';

¿Por qué está cerrado? Ciertamente no es específico de Deno, especialmente con el auge de mjs

Este hilo NO es una pregunta, es una solicitud de función. ¿Alguien puede corregir la etiqueta y volver a abrirla? Agregar manualmente // @ts-ignore a cada importación no es una solución aceptable.

@zraineri

He leído varios hilos relacionados con este problema. Para resumir, los desarrolladores principales simplemente no quieren hacer esto. Dicen que puede romper otras cosas y que el algoritmo de importación ya es bastante complejo y así sucesivamente.

Considérame loco, pero me parece que hubo algo de solidaridad empresarial aquí. La empresa ha gastado mucho dinero en el nodo (npm). Y no quiere que un advenedizo les robe sus ganancias con sus propias manos. Así que no creo que se pueda esperar mucha simpatía hacia deno de vscode o mecanografiado

Afortunadamente, puede usar un complemento que ya hace más de lo que pide y solo mejorará.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

Pero el problema es, no solo Deno, sino también js regulares
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

@Hulkmaster

Parece que necesitamos un texto mecanografiado nuevo y brillante. Este está atascado con sus problemas heredados y no puede (o no quiere) implementar importaciones con extensiones. El equipo de deno parece estar planeando escribir su propio texto mecanografiado (en óxido, supongo :)

Soy parte del equipo central de Deno. Estoy de acuerdo en que el compilador de TypeScript no debería involucrarse en la reescritura de especificadores de módulo. Los componentes internos de Deno suprimen este mensaje de diagnóstico y el complemento vscode para Deno también suprime este mensaje. Esto no es una barrera para Deno.

Créame, no hay una cábala oculta de Microsoft / Node.js que reprima a Deno. El equipo central de TypeScript, miembro de la comunidad Node.js y el equipo central de Deno conversan y colaboran regularmente.

@kitsonk

Esto no es una barrera para Deno.

pero esta es una barrera para la unificación de dos mundos: Node y Deno. ¿Cómo puedo escribir un texto mecanografiado que funcione en ambas plataformas al mismo tiempo si tienen desacuerdos religiosos sobre la importación de archivos locales con o sin extensiones? Tendré que elegir un lado

¿Cómo puedo escribir un texto mecanografiado que funcione en ambas plataformas al mismo tiempo si tienen desacuerdos religiosos sobre la importación de archivos locales con o sin extensiones?

Eso realmente no es un problema con TypeScript / tsc . Node.js va por el camino de los módulos explícitos de todos modos, y sospecho que cómo lo abordan tendrá un impacto en las capacidades de resolución del módulo de tsc . Creo que hay conversaciones continuas allí para poder brindar un mejor soporte a ESM en Node.js.

Hacer lo que sugiere este problema no ayudaría realmente a nadie. En # 33437 se propuso una mejor solución al problema.