¿Utiliza alguna otra herramienta de agrupación como browserify o webpack en la salida generada? ¿O espera que esto se ejecute directamente en el nodo?

Si se pretende este comportamiento, entonces, ¿cómo se pueden usar los mapas de ruta para resolver el infierno de importación relativa junto con el nodo?

Bueno, y para agregar contexto, "paths" está diseñado para usar con cargadores que permiten la reasignación, a diferencia de Node.js require() . El comportamiento previsto es permitir que TypeScript resuelva la información de tipo para varios ID de módulo utilizados por varios cargadores, no reescribir ID de módulo. Básicamente, no hace lo que pensabas que hacía. En mi opinión, tampoco debería, solo debería tener la capacidad de reflejar las estrategias de resolución de los cargadores.

@mhegazy Esperaba que funcionara directamente con node. Es para una aplicación backend. ¿Es correcto @kitsonk al afirmar que esto funciona según lo previsto y que el mecanografiado no reescribirá las rutas de los módulos?

sí, esta era la intención: mitigar la falta de coincidencia entre el tiempo de ejecución y la experiencia del tiempo de diseño cuando el módulo (tal como está escrito por el usuario) se puede resolver en el tiempo de ejecución pero el compilador no pudo encontrarlo. En este punto, el compilador siempre asume que la identificación del módulo proporcionada por el usuario es correcta y nunca intenta cambiarla.

respuesta similar https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

Muy bien, gracias. Podría ser útil documentar esto mejor para evitar que más personas se confundan. Ahora uso https://www.npmjs.com/package/module-alias para que funcione con node.

Apreciando la posición de TS, aquí hay una solución simple para el caso de uso del 90 % para aquellos de nosotros que usamos el nodo, pero queremos la conveniencia de usar baseUrl require() sin ningún problema.

Esta solución engancha la llamada require() del nodo y resuelve las solicitudes usando el nombre de directorio de "main" para imitar baseUrl . Por lo tanto, asume que la opción del compilador baseUrl también se configuró en el mismo directorio donde se encuentra la fuente "main.ts".

Para usarlo, pegue este pequeño trozo de código en la parte superior de su "main.ts".

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

Si va a usar el paquete module-alias que mencionó mika-fischer, tenga en cuenta que las rutas que registra en el paquete no deben terminar en / , y las rutas son relativas a la ruta donde package.json es (puede ser obvio pero es bueno dejarlo claro),

Entonces, si tiene esto en su archivo tsconfig:

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

Tienes que registrar esto en tu package.json :

"_moduleAliases": {
  "foo": "dist"
}

Bueno, y para agregar contexto, "paths" está diseñado para usarse con cargadores que permiten la reasignación, a diferencia de Node.js require(). El comportamiento previsto es permitir que TypeScript resuelva la información de tipo para varios ID de módulo utilizados por varios cargadores, no reescribir ID de módulo. Básicamente, no hace lo que pensabas que hacía. En mi opinión, tampoco debería, solo debería tener la capacidad de reflejar las estrategias de resolución de los cargadores.

Llegué aquí después de perder algo de tiempo tratando de configurarlo en un gran proyecto.
Si este comportamiento no va a cambiar lo mínimo que puedes hacer es actualizar la documentación antes de cerrar este problema.
La documentación oficial https://www.typescriptlang.org/docs/handbook/module-solution.html#path -mapping%20docs no dice nada sobre tener que usar "cargadores que permitan la reasignación".

instale y ejecute "tspath" en la carpeta de su proyecto... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

También puede probar "momothepug/tsmodule-alias" para la resolución de la ruta de alias:

https://www.npmjs.com/package/@momothepug/tsmodule-alias

Solo https://www.npmjs.com/package/module-alias funcionó para mí...

Yo también logré que esto funcionara con module-alias, con la desventaja de que tengo que realizar un seguimiento de mis alias tanto en tsconfig.json como en package.json. ¿Alguien ha encontrado una solución más sencilla?

La solución señalada por @mattyclarkson también funciona, pero no pude encontrar una manera de usarla junto con ts-node. ¿Algunas ideas?

Eche un vistazo a https://github.com/momoThePug/tsmodule-alias

2018-05-31 15:04 GMT-05:00 edufschmidt [email protected] :

Yo también logré que esto funcionara con module-alias, con la desventaja
que tengo que hacer un seguimiento de mis alias tanto dentro de tsconfig.json como
paquete.json. ¿Alguien ha encontrado una solución más sencilla?

La solución señalada por @mattyclarkson
https://github.com/mattyclarkson también funciona, pero no pude encontrar la manera
de usarlo junto con ts-node. ¿Algunas ideas?

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

Gracias @DanyelMorales , esto es muy útil.

¡de nada! :)

2018-05-31 16:35 GMT-05:00 edufschmidt [email protected] :

Gracias @DanyelMorales https://github.com/DanyelMorales , esto es realmente
práctico.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

¿Alguien puede decirme cuál es el punto de esta función si los nombres de ruta emitidos son realmente incorrectos? Es decir, si el compilador de TypeScript está contento con él, pero el resultado final no se puede ejecutar, ¿cuál es el caso de uso de esta función?

¿Cómo se debe hacer un mapeo de rutas relativas para cosas que NO son módulos, es decir, no son importaciones?

En un script de nodo que lee un directorio determinado en relación con el archivo fuente que solía hacer:

const starterDir = path.resolve(__dirname, './templates/starter')

dado que TypeScript compila el script y lo escribe en otro directorio (según la configuración), __dirname ya no conducirá a la resolución de la ruta anterior. ¿Cuál sería una solución a esto?

¿Cómo se debe hacer un mapeo de rutas relativas para cosas que NO son módulos, es decir, no son importaciones?

Eso es realmente "cómo uso Node.js y la pregunta TypeScript" y mucho mejor preguntado en Gitter.im o StackOverflow.

Me encanta TypeScript, pero esto es una locura.

no lo entiendo Incluso sabiendo poco sobre el código base de TS, esto no debería ser difícil de implementar. Acabo de empezar a usar un proyecto compartido con el cliente y el servidor... ¿por qué TS presenta la funcionalidad de rutas en primer lugar y luego me hace pasar por el aro para usarla realmente? ¿Por qué TS asume que quiero usar un paquete/cargador con cada proyecto que hago? Estoy tratando de usar TS para simplificar mis proyectos, no agregar más bibliotecas de herramientas para compensar una función de TS implementada en un 90 %.

Estoy de acuerdo contigo. Creo que TS fue desarrollado para frontend, porque webpack
ya implementa bastante bien ts alias paths, y con Requirejs también es
la misma cosa. Pero para los proyectos de Nodejs es muy difícil. :(

El ju., 20 de sept. de 2018 02:50, Josh Pike [email protected]
escribió:

no lo entiendo Incluso sabiendo poco sobre el código base de TS, este
no debería ser difícil de implementar. Acabo de empezar a usar un proyecto compartido
con cliente y servidor... ¿por qué TS presenta la funcionalidad de rutas en
en primer lugar, ¿entonces me hace saltar a través de aros para usarlo realmente? Por qué
¿TS asume que quiero usar un paquete/cargador con cada proyecto que
¿hacer? Estoy tratando de usar TS para simplificar mis proyectos, no agregar más
bibliotecas de herramientas para compensar una función TS implementada en un 90 %.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1!

webpack puede ayudarme a resolver mapas de ruta (u otra herramienta como babel-plugin-module-resolver ) pero no declaraciones ( .d.ts ) .

No se resuelven todas las rutas de la declaración.

Me encontré con este problema también. Parecía lógico que el código emitido incluyera asignaciones de ruta. Recurrido a module-alias . Pero +1 para Typescript para proporcionar opcionalmente esta funcionalidad.

¿No se puede agregar esto simplemente como una opción del compilador? Claramente es una petición popular. Sin saber nada del funcionamiento del compilador, ¿no debería ser súper simple implementarlo? ¿Por qué obligarnos a saltar a través de aros en otros lugares cuando se puede resolver tan fácilmente directamente con el compilador de TypeScript, donde tiene más sentido?

+1

Puede compilar importaciones TypeScript absolutas y basadas en rutas a archivos Javascript relativos usando ts-transformer-imports y ttypescript

Creé una solución en tiempo de compilación donde puede continuar usando tsc . https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479 (comentario)

Acabo de encontrarme con este problema cuando intento que vue-cli genere archivos d.ts donde hay muchos import {foo} from "@/some/folder/foo" y los archivos d.ts generados no resuelven el alias.

De la búsqueda general y la revisión de este hilo y otros, parece que la reacción instintiva es "esto no es un problema para que TS lo resuelva", pero le pido al equipo que cambie esa postura como actualmente si usa un alias de ruta personalizado (completamente válido y enfoque recomendado para proyectos complejos) simplemente no puede usar generar archivos d.ts (sin un proceso de compilación personalizado de terceros), por lo que diría que el compilador de mecanografiado también debería resolver estos alias en el proceso del archivo de declaración.

El trabajo de los compiladores es generar archivos javascript Y d.ts válidos para sus archivos mecanografiados, y simplemente no funciona en este escenario válido (usando el alias de la ruta en los archivos tsconfig).

Estoy un poco confundido con este tema. Ha sido cerrado y etiquetado como 'Funcionando según lo previsto'. ¿Debo entender que Typescript está destinado a generar una fuente no válida? Parece extraño.

Los mendigos no pueden elegir, pero el uso de Typescript evita muchos aspectos frustrantes de Vanilla JS y considero que las importaciones relativas ('../../../../../utils/parser') son una de ellas. ¡Sería increíble si Typescript pudiera limpiar esto!

@codeitcody Parece que sí. Es tonto que genere algo que simplemente no funciona sin un paquete de terceros, pero esa es la realidad.

Bueno, no es este un buen problema para caer.

Parece muy contraproducente tener una función que esencialmente hace que su aplicación sea inutilizable sin pasar por los aros (es decir, instalar más dependencias para solucionar el problema).

Este problema ha existido durante 2 años y no hay información oficial sobre si se implementará o no.

Teniendo en cuenta que se requiere una funcionalidad básica para usar una de las mejores características de TypeScript en sus proyectos de Node.js, es bastante horrible cómo se trata.

@mhegazy ¿Puede usted u otra persona decirnos si ahora, dos años después, tal vez el equipo de TypeScript podría volver a revisar esto y reconsiderarlo?

webpack puede ayudarme a resolver mapas de ruta (u otra herramienta como babel-plugin-module-resolver ) pero no declaraciones ( .d.ts ) .

No se resuelven todas las rutas de la declaración.

¿Hay una manera de lograr esto? Tengo una biblioteca de componentes de reacción personalizada y recibí este error al intentar usar paths para un alias. Hago los 2 paquetes con rollup y los tipos con --emitDeclarationOnly

No puedo usar module-alias porque dice:

ADVERTENCIA: ¡Este módulo no debe usarse en otros módulos npm ya que modifica el comportamiento requerido predeterminado!

Ayúdenos a votar esta publicación en Reddit: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
No sé por qué necesita esta gran discusión aquí. Debería ser fácil resolver este error. Una opción en tsconfig y todos pueden decidir si quieren el comportamiento actual (por cualquier motivo) o un enfoque de trabajo.

Tuvimos el mismo problema en Dropbox y abrimos este transformador https://github.com/dropbox/ts-transform-import-path-rewrite

He tenido la misma experiencia varias veces, espero que se resuelva el alias de la ruta, pero sigo olvidando que tengo que instalar el alias del módulo, actualizar el paquete.json e importarlo en el archivo principal. Sería increíble si esto fuera manejado en el paso de compilación por Typescript.

Ay. Este es un verdadero golpe para TypeScript. ¿Dónde está el sentido en esto?

ps ¿No podemos simplemente comentar +1

Bienvenido al club @def14nt. Somos un grupo feliz de soñadores, con los ojos llenos de ilusión mientras miramos hacia un futuro mejor, esperando pacientemente el día en que TypeScript implementará la opción de compilador simple y sensata para hacernos la vida más fácil. Cuando ese día finalmente llegue, asegúrese de buscar en el cielo los cuerpos rosados ​​y corpulentos de los cerdos mientras vuelan majestuosamente hacia la puesta de sol con sus alas recién descubiertas.

Lol, solo instalaré una extensión npm para algo para lo que el equipo de TypeScript podría agregar soporte. Tal vez deberían dejar de agregar más y más mejoras y agregar funciones que son tan básicas.

@mika-fischer
¿Cómo usar https://www.npmjs.com/package/module-alias para que eslint no se detenga para advertir sobre 'Ruta no resuelta' @root/bla/bla' (en archivos JS)? ¿Y cómo habilitar el autocompletado para dichas rutas en WebStorm y VS Code?

Para mí, las importaciones de autocompletado funcionan en VSCode de forma predeterminada en proyectos de TypeScript.

@bobmoff Sí, parece que todo está bien para importar archivos TS desde archivos TS.
Pero el autocompletado y la navegación para `require('@root/bla/bla') desde archivos TS no funcionan.

Deseo traducir mi proyecto JS a TS, y pensé que podía cambiar el nombre de los archivos js a ts uno por uno.
Ahora me doy cuenta de que es muy difícil y no es compatible ni con ts ni con IDE, y debería cambiar el nombre de todos mis archivos js a ts a la vez.

Porque si cambio el nombre de un solo archivo JS a TS, todas las rutas relativas en el directorio build se rompen (probablemente debería usar "allowJs: true", pero tengo un proyecto con 2 Gigabytes de archivos JS, es tan extraño compilarlos en el directorio de compilación %)).
Ok, trato de resolver esto mediante alias de módulo, y la navegación y el autocompletado de mi IDE dejan de funcionar y eslint advierte sobre 100500 'Rutas no resueltas'. Ya odio un poco a TS, parece que la migración para grandes proyectos de JS no es tan fácil como dice la gente de marketing de TS. Parece que la migración de proyectos de back-end de JS a golang es más simple :)

Estoy usando con éxito tscpaths como solución alternativa.

Yo también. Realmente recomiendo tscpaths . Funciona como se supone que debe hacerlo.

Mi solución simple:

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

O con el proceso pm2.yml

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

Me topé con esto, a veces TypeScript puede ser un verdadero dolor de cabeza.

En serio, no entiendo por qué este hilo sigue y sigue y sigue....
Todos conocemos el "camino del infierno", y que usted (mediante el uso de alias) puede
muy limpio
¡Arregla ese lío, todos en este hilo lo saben!

Los alias son interpretados por el compilador TypeScript, compila exactamente
como debería,
definitivamente no debería hurgar en el javascript resultante, si
quieres usar
alias tendrán que resolver esto ustedes mismos!

....o iniciar hilos en Apple, Google y Microsoft
pidiéndoles que implementen la funcionalidad en sus motores de JavaScript para que
ellos pueden
interpreta tus alias ;-)

¡El compilador de TypeScript hace exactamente lo que debería hacer!

Si estás trabajando en el mundo Angular el camino está pavimentado, si quieres
ejecuta tu
código directamente en Node, necesitará una herramienta para resolver las rutas, y tengo
hecha
esa herramienta solo para ti, se ha utilizado en producción durante más de un año,
está siendo
utilizado por el periódico más grande aquí en Suecia, hice esto para que pueda
ir desnudo
hueso con Node, no estoy tratando de vender nada aquí, no gano dinero
de esto :)

Y sí, hay herramientas como "tsmodule-alias" y trucos similares, puedes
realmente hacer que funcione
si eres muy, muy cuidadoso, pero es un desastre, hay soluciones alternativas usando
nodo ts,
scripts de shell, etc., etc.

Finalmente sentí que ya es suficiente, así que me encerré e hice
TsPath
los alias de tiempo de compilación

> npm install -g tspatj

miproyecto> tsc

miproyecto> tspath

o

miproyecto> tspath --f

sin cabeza (probado muy útil en el servidor de compilación)

y luego ya está, sus archivos javascript ahora tienen el
rutas relativas correctas, ¿no es eso lo que queremos aquí?

¡Salud! :)

https://www.npmjs.com/package/tspath

Den hijo 13 ene. 2019 kl 22:20 skrev Fabio Spampinato <
[email protected]>:

Me topé con esto, a veces TypeScript puede ser un verdadero dolor en el
culo.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

@duffman

Los alias son interpretados por el compilador TypeScript, compila exactamente
como debería, definitivamente no debería hurgar en el javascript resultante, si
Si quieres usar alias, ¡tendrás que resolverlo tú mismo!

Muy en desacuerdo. A menos que estuvieras bromeando, realmente no podría decirlo.

TypeScript debería compilar código que _funciona_ sin necesidad de una herramienta de terceros para completar el trabajo que solo se implementó parcialmente en el compilador nativo.

¡El compilador de TypeScript hace exactamente lo que debería hacer!

Si este hilo estuviera lleno de personas que solicitan que tsc también minimicen o algo así, estaría de acuerdo con usted. Sin embargo no lo es. Son personas que solicitan que el compilador genere código ejecutable. Realmente no creo que sea mucho pedirle a un compilador, ¿verdad?

Y está generando código ejecutable si no usa características que es
no es compatible con los motores de JavaScript, eso debería tener mucho sentido, ¿verdad?
allí, por ejemplo: ¿culparía al compilador de C++ si su aplicación
utiliza bibliotecas de enlaces dinámicos y que el programa no se ejecutará en una máquina
que no los tiene instalados?

Esta es una función que se puede utilizar si administra las rutas relativas,
asumir la responsabilidad de ellos como lo hace Angular con WebPack o como lo hago con
todos mis proyectos TypeScript con TSPath!

No los utilice si no sabe cómo configurar un entorno de trabajo,
Realmente no creo que esto sea responsabilidad de Microsoft aquí, ellos
proporcionó una característica y así es como funciona,
puede que no funcione como usted quiere o espera que funcione, pero eso no hace que
¡está mal!

Además, tengo curiosidad, ¿en serio estás dejando que esto te impida
desarrollando usando TypeScript?

Den mån 14 ene. 2019 kl 21:34 skrev Robert Main [email protected] :

¡El compilador de TypeScript hace exactamente lo que debería hacer!

Si este hilo estuviera lleno de personas que solicitan que tsc también lo haga
minificación o algo así, estaría de acuerdo contigo. Sin embargo no lo es. Es
personas que solicitan que el compilador genere código ejecutable. Yo realmente
No creas que es mucho pedirle a un compilador, ¿verdad?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

Esta es una característica que se puede utilizar si administra las rutas relativas, asume la responsabilidad de ellas como lo hace Angular con WebPack o como lo hago con todos mis proyectos de TypeScript con TSPath.

Esta es una función que hace que el compilador genere código roto, código que podría funcionar si solo escribiera 1 línea de código para resolver correctamente esas rutas.

El hecho de que TS necesite un paquete externo solo para que el código generado pueda ejecutarse es simplemente ridículo.

Y está generando código ejecutable si no usa características que es
no compatible con los motores de JavaScript,

Siempre he entendido que se suponía que TypeScript debía compilar en JavaScript. Si me está diciendo que ciertas funciones no son compatibles con los motores de JavaScript, ¿por qué exactamente están ahí?

¿Culparía al compilador de C++ si las bibliotecas de enlace dinámico de su aplicación y el programa no se ejecutará en una máquina que no las tiene instaladas?

No, pero lo culparía si me permitiera vincular a otro código C++ que en realidad no existía sin error o advertencia del compilador.

Realmente no entiendes esto, ¿verdad? El código no está roto, si lo está.
roto es porque has configurado el compilador
para generar código que su "plataforma" no soporta, en este caso,
alias!

En tu caso, no uses alias, "tú" no los apoyas, ¡en serio!

Incluso si esto fuera una solución de 1 línea (por supuesto que ese no es el caso) es un
cuestión de lo que un compilador debe y
no debe hacer! Esta característica se ha agregado para SOPORTAR CARGADORES no
al revés, lee
en Path Mapping en la documentación oficial, así que de nuevo, lo estás usando
¡incorrecto!

Una vez más, esta función es para cargadores/resolvedores, ha entendido mal cómo funciona.
funciona, así que no, Microsoft
no debe alterar el compilador para que pueda pegar alias sin un
ambiente que lo apoya!

Den tis 15 ene. 2019 kl 04:41 skrev Fabio Spampinato <
[email protected]>:

Esta es una función que se puede utilizar si administra las rutas relativas,
asumir la responsabilidad de ellos como lo hace Angular con WebPack o como lo hago con
todos mis proyectos TypeScript con TSPath!

Esta es una característica que hace que el compilador genere código roto, código que
podría estar funcionando si solo escribieran 1 línea de código para resolver esos
caminos.

El hecho de que TS necesite un paquete externo solo para que el código de salida
puede ser ejecutado es simplemente ridículo.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

Están ahí porque los cargadores usan Path Mapping, ¡por eso es compatible!
Y ya que insistes (como yo) en usarlos sin Loader, cual es el
problema con
usando una herramienta para poder hacer uso de la función?

Den tis 15 ene. 2019 kl 05:10 skrev Robert Principal [email protected] :

Y está generando código ejecutable si no usa características que es
no compatible con los motores de JavaScript,

Siempre he entendido que se suponía que TypeScript debía compilar para
JavaScript. Si me está diciendo que ciertas funciones no son compatibles con
Los motores de JavaScript, entonces, ¿por qué exactamente están ahí?

¿culparía al compilador de C++ si el enlace dinámico de su aplicación
bibliotecas y que el programa no se ejecutará en una máquina que no tenga estas
instalado?

No, pero lo culparía si me permitiera enlazar con otro código C++ que no
realmente existen sin error o advertencia del compilador.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

Mira, veo tu punto. Hago. Pero parte del trabajo de los compiladores es verificar la cordura de las cosas por última vez. En el mejor de los casos, el código que compila pero no se ejecuta es un comportamiento inconsistente y cuando leí este problema por primera vez, la documentación parecía sugerir un comportamiento que claramente no existe.

Por favor, diríjame a esa sección de la documentación.

es el 15 de enero 2019 kl. 05:31 skrev Robert principal [email protected] :

Mira, veo tu punto. Hago. Pero parte del trabajo de los compiladores es la cordura.
comprobar las cosas por última vez. En el mejor de los casos, el código que compila pero no se ejecuta es
comportamiento incoherente y cuando leí por primera vez este problema,
la documentación parecía sugerir un comportamiento que claramente no existe

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

Esta característica se ha agregado para SOPORTAR CARGADORES no
al revés, lee
en Path Mapping en la documentación oficial, así que de nuevo, lo estás usando
¡incorrecto!

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffman ¿No ves que la gente aquí solo quiere esta función? Le estás diciendo a todo el mundo que es demasiado estúpido para entender cómo se debe usar esta "característica". Está bien, puedes verlo de esa manera, pero quién sabe, tal vez sea al revés...

Por cierto, mi opinión es la siguiente:

Como los alias están integrados en el compilador y la compilación del proyecto con ellos está bien. Puede hacer que los usuarios piensen que funciona de la manera que sugiere (y este problema es una buena prueba de que tengo razón). Incluso parece ilógico: ¿por qué algo funciona en el editor "oficial" (vscode, especialmente cuando se usa la función de "importación automática", vscode usa una ruta con alias), por qué el copilador también funciona bien, cuando el código resultante no funciona? Decir "el motor js no lo admite" me hace querer preguntar aún más: ¿no se suponía que TS era algo para mitigar algunos de los "problemas" de JS?

Esperaría una de dos soluciones de esto:
1) Anular correctamente las importaciones con alias
2) Mostrar una advertencia

Decir "es el comportamiento correcto" es, creo, incorrecto. Que no es. TS no es un lenguaje ensamblador, ni siquiera un C/C++.

El equipo de desarrollo debe agregar soporte para la resolución de alias. sugiero agregar un
clave para la resolución del compilador en tsconfig.

Seria bueno Microsoft!!!!!!

Te lo rogamos, necesitamos tu ayuda para mejorar las aplicaciones con alias.

:( todos aquí están tristes y enojados (y hambrientos) debido al retraso de
consistencia. Mecanografiado es impresionante, me encanta...

¡Lo amamos!

Saludos cordiales a un desarrollador sin hogar...

El mar., 15 de ene. de 2019 08:02, Mike S. [email protected]
escribió:

Por cierto, mi opinión es la siguiente:

Los alias están integrados en el compilador, una compilación está bien. Puede hacer que los usuarios
piensan, que debería funcionar como ellos piensan (y este problema es bastante
buena prueba de que es verdad). Parece ilógico: por qué algo funciona en
editor "oficial" (vscode, especialmente cuando se utiliza la función de "importación automática",
vscode usa una ruta con alias), por qué el copilador también funciona bien, cuando el código resultante
¿no está trabajando? Decir "js engine no es compatible" me da ganas de preguntar
aún más: ¿no se pensó que TS era algo para mitigar algunos de los "problemas" de JS?

Esperaría una de dos soluciones de esto:

1. Anulando correctamente las importaciones con alias
2. Mostrando una advertencia

Decir "es el comportamiento correcto" es, creo, incorrecto. Que no es. TS no es
lenguaje ensamblador, ni siquiera un C/C++.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS no es un lenguaje ensamblador, ni siquiera un C/C++.

Realmente no entiendo lo que está tratando de señalar al establecer que TS no es C ++, ¡la mayoría de nosotros lo sabemos muy bien, creo!

También hemos establecido que el mapeo de alias/ruta se usa en producción en todo el mundo, por lo que, naturalmente, VS Code debería admitir eso, ¡pero aún no es un argumento para que MS cree el compilador para adaptarse a su configuración!

Lo que me cuesta entender es por qué sigues así, el compilador funciona como se supone que debe funcionar, de nuevo, lee los documentos que indican claramente para qué es la función.

Quiero decir que puede configurar un entorno de desarrollo de TS en funcionamiento con alias de ruta en unos 2 minutos, si no desea usar WebPack, puede usar TSPath para resolver todas las rutas en todos los archivos js en 1 segundo, agréguelo al paquete .json como un script de ejecución y ni siquiera tiene que pensar en ello, el problema no existe, el compilador permanece de la forma en que debía funcionar y puede continuar feliz ¡hurra!

O si es tan importante para usted que el compilador real haga esto por usted, entonces le sugiero que bifurque el compilador y lo implemente usted mismo, tal vez sea un gran éxito o tal vez la gente esté contenta como está desde que se configuró. sus entornos para admitir alias.

Convocando a los cinco principales colaboradores de TypeScript: @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

¿Podría el equipo de TypeScript reconsiderar este problema? Creo que este hilo ofrece una discusión útil sobre ambos puntos de vista y, dada su reciente popularidad y la cantidad de tiempo que ha pasado, debería revisarse nuevamente.

El estado de este problema no me dejó otra opción que degradar a TS para que solo escriba el deber de verificación.
Babel ahora tiene un soporte decente para la sintaxis TS y junto con babel-plugin-module-resolver hace el trabajo de emitir código de trabajo para este caso de uso muy bien.
El único inconveniente es la duplicación de bits de configuración de tsconfig.json ya que a Babel no le importan las configuraciones de TS. Pero es un precio aceptable para trabajar rutas absolutas en proyectos de nodos y, como beneficio adicional, obtengo todo el ecosistema con cosas brillantes como macros de Babel.

Esta es la configuración mínima que obtuve como reemplazo directo del compilador tsc :

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• en package.json :
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• en tsconfig.json :

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• en .babelrc :

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

Solo quiero usar mecanografiado con ruta absoluta, pero parece que tengo que configurar webpack o babel o algo así, es demasiado difícil lograr esta característica simple, debería ser más fácil 😞

Reconozco este problema, no estoy seguro de haber sido consciente de este específico
problema debido a mi propia configuración personal, o tal vez lo era :) no es un súper
solución pesada, la solución será simplemente confiar (ciegamente) en distPath,
que en realidad es un código cada vez menos simple que la solución actual,
trata de tener una solución disponible para mañana...

Den mån 28 ene. 2019 kl 15:59 skrev 叶伟伟[email protected] :

Solo quiero usar mecanografiado con ruta absoluta, pero parece que tengo que
config webpack o babel o algo así, ¡es demasiado difícil de lograr!

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

Dejo esto aquí porque no se mencionó en este hilo un caso de uso real documentado para el comportamiento actual de paths : los paquetes @types/ no respaldan características con respecto a semver. Sin embargo, incluyen tipos actualizados para API más antiguas que puedo usar. Por ejemplo, estoy usando history@2 cuando history@3 es el último.

"paths": {
    "history": [ "history/v2" ]
}

El compilador necesitaría una opción adicional para diferenciar entre alias de tipo y alias de "código". Si cambiamos el comportamiento para emitir realmente los alias de la ruta, entonces debemos agregar la capacidad al compilador para encontrar la versión de tipos correcta.

Esto no es un argumento en contra del comportamiento propuesto. Preferiría haber emitido alias y una solución de trabajo just™ para el control de versiones de tipos. Solo quería proporcionar un contexto de por qué cambiar esto podría no ser tan trivial como la gente piensa que es.

Por segunda vez durante un taller de TS de toda la empresa, tuve que explicar este comportamiento tonto y vergonzoso...

¡Seriamente!

¿Qué tipo de compilador de lenguaje, especialmente uno cuyo argumento de venta principal es más correcto para JavaScript, produce código roto como una "característica"?!?!

Lamento haber sonado tan frustrado en mi comentario, pero las opiniones de la comunidad aquí aparentemente están siendo ignoradas y minimizadas repetidamente.

Solo mire cuántas veces se ha hecho referencia a esto... Qué pérdida de tiempo y atención para tanta gente.

Entiendo su frustración, pero mucha gente siente que un comportamiento es correcto, no significa que sea lo correcto.

La reescritura de identificadores de módulos de TypeScript es una pendiente resbaladiza. Lo que se ha expresado varias veces en este hilo es que TypeScript se puede configurar para modelar el comportamiento de otros solucionadores de módulos y otras herramientas de compilación, no para reemplazarlos ni implementarlos.

El hecho de que TypeScript se pueda configurar para resolver módulos de manera flexible no significa que TypeScript emita "código roto". Ciertos cargadores y empaquetadores que reflejan esta configuración funcionarían bien.

Si tuviéramos que ser críticos con algo, podríamos culpar al equipo por nombrar la opción algo que podría parecer que soluciona un problema que nunca tuvo la intención de solucionar, aunque la documentación de la opción deja en claro que no cambia la emisión. .

El hecho de que una herramienta en particular no resuelva un problema que usted tiene no siempre significa que sea culpa de esa herramienta. Es posible que simplemente no tenga todas las herramientas que necesita para resolver su problema.

@kitsonk todo lo que acabas de decir está fuera de lugar.

El problema es que TS funcionará de una manera durante el desarrollo/prueba, y de otra después de que se haya completado la compilación.

Si TS quiere ser un módulo de resolución, debe elegir un patrón y ceñirse a él. Si ejecuto algo con ts-node , debería funcionar exactamente como si compilara algún TS y lo ejecutara con node .

No es así, y ese es el problema.

Tal vez los mapas de módulos aliviarán la frustración en el futuro. Pero nuestra posición aquí junto con los problemas técnicos que queremos resolver son bastante explícitos: el mapeo de rutas refleja el comportamiento de un esquema de resolución externo (por ejemplo, el mapeo de rutas en AMD y System.js, alias en Webpack y otros paquetes). No implica que cambiaremos tus caminos.

No creo que ninguna discusión reciente haya sido constructiva recientemente, ni preveo ningún cambio futuro aquí, así que voy a cerrar este problema.